Re: [PATCH] drm/msm: fix the `CRASHDUMP_READ` target of `a6xx_get_shader_block()`

2024-04-04 Thread Dave Airlie 
On Sat, 30 Mar 2024 at 04:39, Abhinav Kumar  wrote:
>
>
>
> On 3/26/2024 2:23 PM, Miguel Ojeda wrote:
> > Clang 14 in an (essentially) defconfig arm64 build for next-20240326
> > reports [1]:
> >
> >  drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error:
> >  variable 'out' set but not used [-Werror,-Wunused-but-set-variable]
> >
> > The variable `out` in these functions is meant to compute the `target` of
> > `CRASHDUMP_READ()`, but in this case only the initial value (`dumper->iova
> > + A6XX_CD_DATA_OFFSET`) was being passed.
> >
> > Thus use `out` as it was intended by Connor [2].
> >
> > There was an alternative patch at [3] that removed the variable
> > altogether, but that would only use the initial value.
> >
> > Fixes: 64d6255650d4 ("drm/msm: More fully implement devcoredump for a7xx")
> > Closes: 
> > https://lore.kernel.org/lkml/caniq72mjc5t4n25sqvysroehxxpxypz4ppznesjhenc3qap...@mail.gmail.com/
> >  [1]
> > Link: 
> > https://lore.kernel.org/lkml/cacu1e7hhckmjd6fixzspinaz6ekoznkmthtclfvmbz-9vol...@mail.gmail.com/
> >  [2]
> > Link: 
> > https://lore.kernel.org/lkml/20240307093727.1978126-1-colin.i.k...@gmail.com/
> >  [3]
> > Signed-off-by: Miguel Ojeda 
> > ---
>
>
> LGTM,
>
> Reviewed-by: Abhinav Kumar 

I'm seeing this on my drm-next tree, where is this fix landing?

Dave.

Re: [Freedreno] [PATCH] drm/sched: Convert the GPU scheduler to variable number of run-queues

2023-10-31 Thread Dave Airlie 
On Wed, 1 Nov 2023 at 11:46, Luben Tuikov  wrote:
>
> On 2023-10-31 09:33, Danilo Krummrich wrote:
> >
> > On 10/26/23 19:25, Luben Tuikov wrote:
> >> On 2023-10-26 12:39, Danilo Krummrich wrote:
> >>> On 10/23/23 05:22, Luben Tuikov wrote:
>  The GPU scheduler has now a variable number of run-queues, which are set 
>  up at
>  drm_sched_init() time. This way, each driver announces how many 
>  run-queues it
>  requires (supports) per each GPU scheduler it creates. Note, that 
>  run-queues
>  correspond to scheduler "priorities", thus if the number of run-queues 
>  is set
>  to 1 at drm_sched_init(), then that scheduler supports a single 
>  run-queue,
>  i.e. single "priority". If a driver further sets a single entity per
>  run-queue, then this creates a 1-to-1 correspondence between a scheduler 
>  and
>  a scheduled entity.
> >>>
> >>> Generally, I'm fine with this patch and how it replaces / generalizes the 
> >>> single
> >>> entity approach.
> >>
> >> Great!
> >>
> >>> However, I'm not quite sure how to properly use this. What is a driver 
> >>> supposed to
> >>> do, which previously took advantage of DRM_SCHED_POLICY_SINGLE_ENTITY?
> >>>
> >>> Is it supposed to call drm_sched_init() with num_rqs=1? If so, what's the 
> >>> correct way
> >>
> >> Yes, you call drm_sched_init() with num_rqs set to 1.
> >>
> >>> to initialize the drm_sched_entity then? Calling drm_sched_entity_init() 
> >>> with priority=0?
> >>
> >> Yes, with priority set to 0.
> >>
> >> One unfortunate fact I noticed when doing this patch is that the numerical 
> >> values
> >> assigned to enum drm_sched_priority is that the names to values are upside 
> >> down.
> >> Instead of min being 0, normal:1, high:2, kernel:3, it should've been 
> >> kernel:0 (highest),
> >> high:1, normal:2, low:4, and so on.
> >>
> >> The reason for this is absolutely clear: if you had a single priority, it 
> >> would be
> >> 0, the kernel, one, highest one. This is similar to how lanes in a highway 
> >> are counted:
> >> you always have lane 1. Similarly to nice(1) and kernel priorities...
> >>
> >>> Any other priority consequently faults in drm_sched_job_arm().
> >>
> >> drm_sched_job_arm() faults on !ENTITY, but the "priority" is just
> >> assigned to s_priority:
> >>  job->s_priority = entity->priority;
> >>
> >>
> >>> While I might sound like a broken record (sorry for that), I really think 
> >>> everything
> >>> related to Matt's series needs documentation, as in:
> >>
> >> Yes, I agree.
> >
> > Great! Do you plan to send a subsequent patch adding some documentation for 
> > this one? I
> > think it'd be good to get all the above documented.
>
> A lot of this would be the magic sauce of drivers and hardware--as we've seen 
> with Xe,
> and it would be presumptuous of me to write down to the detail of what and 
> how this
> and that should be used.

Nope it wouldn't be. Please feel free to persume how drivers might
work in the form of documentation.

At some point the scheduler needs to be documented and so far two
maintainers have avoided doing so, and it's causing no end of
problems.

Write documentation, this goes for Xe scheduler patches, Danilo's work.

When someone asks you for docs, consider it a blocker on getting stuff
merged, because this stuff isn't obvious.

Dave.

Re: [Freedreno] [PATCH v4 0/9] drm: fdinfo memory stats

2023-05-22 Thread Dave Airlie 
On Sun, 21 May 2023 at 10:03, Dmitry Baryshkov
 wrote:
>
> On 15/05/2023 17:30, Rob Clark wrote:
> > From: Rob Clark 
> >
> > Similar motivation to other similar recent attempt[1].  But with an
> > attempt to have some shared code for this.  As well as documentation.
> >
> > It is probably a bit UMA-centric, I guess devices with VRAM might want
> > some placement stats as well.  But this seems like a reasonable start.
> >
> > Basic gputop support: https://patchwork.freedesktop.org/series/116236/
> > And already nvtop support: https://github.com/Syllo/nvtop/pull/204
> >
> > I've combined the separate series to add comm/cmdline override onto
> > the end of this, simply out of convenience (they would otherwise
> > conflict in a bunch of places).
> >
> > v2: Extend things to allow for multiple regions other than just system
> >  "memory", make drm_show_memory_stats() a helper so that, drivers
> >  can use it or not based on their needs (but in either case, re-
> >  use drm_print_memory_stats()
> > v3: Docs fixes
> > v4: use u64 for drm_memory_stats, small docs update and collected
> >  Tvrtko's a-b
> >
> > [1] https://patchwork.freedesktop.org/series/112397/
> >
> > Rob Clark (9):
> >drm/docs: Fix usage stats typos
> >drm: Add common fdinfo helper
> >drm/msm: Switch to fdinfo helper
> >drm/amdgpu: Switch to fdinfo helper
> >drm: Add fdinfo memory stats
> >drm/msm: Add memory stats to fdinfo
> >drm/doc: Relax fdinfo string constraints
> >drm/fdinfo: Add comm/cmdline override fields
> >drm/msm: Wire up comm/cmdline override for fdinfo
> >
> >   Documentation/gpu/drm-usage-stats.rst  | 101 ++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   3 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  16 +--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h |   2 +-
> >   drivers/gpu/drm/drm_file.c | 147 +
> >   drivers/gpu/drm/msm/adreno/adreno_gpu.c|  24 +++-
> >   drivers/gpu/drm/msm/msm_drv.c  |  15 ++-
> >   drivers/gpu/drm/msm/msm_gem.c  |  15 +++
> >   drivers/gpu/drm/msm/msm_gpu.c  |   2 -
> >   drivers/gpu/drm/msm/msm_gpu.h  |  10 ++
> >   include/drm/drm_drv.h  |   7 +
> >   include/drm/drm_file.h |  51 +++
> >   include/drm/drm_gem.h  |  32 +
> >   13 files changed, 378 insertions(+), 47 deletions(-)
>
> What is the expected merge plan for this series? msm-next? drm-misc?

I'm fine with this going via drm-misc,

Acked-by: Dave Airlie  if that is the plan.

Dave.

Re: [Freedreno] [pull] drm/msm: drm-msm-display-for-6.2

2022-11-29 Thread Dave Airlie 
On Sat, 26 Nov 2022 at 20:21, Dmitry Baryshkov
 wrote:
>
> Hi Dave,
>
> As agreed with Rob Clark, a pull request for the non-GPU part of the drm/msm 
> driver. Summary below.
>
> The following changes since commit 7f7a942c0a338c4a2a7b359bdb2b68e9896122ec:
>
>   Merge tag 'drm-next-20221025' of git://linuxtv.org/pinchartl/media into 
> drm-next (2022-10-27 14:44:15 +1000)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/lumag/msm.git tags/drm-msm-display-for-6.2
>
> for you to fetch changes up to 8d1d17d47eaebe4466459846d07e4ba8953fa585:
>
>   Merge branches 'msm-next-lumag-core', 'msm-next-lumag-dpu', 
> 'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-hdmi' and 
> 'msm-next-lumag-mdp5' into msm-next-lumag (2022-11-26 12:06:29 +0200)
>
> 
> drm/msm updates for 6.2
>
> Core:
> - MSM_INFO_GET_FLAGS support
> - Cleaned up MSM IOMMU wrapper code
>
> DPU:
> - Added support for XR30 and P010 image formats
> - Reworked MDSS/DPU schema, added SM8250 MDSS bindings
> - Added Qualcomm SM6115 support
>
> DP:
> - Dropped unsane sanity checks
>
> DSI:
> - Fix calculation of DSC pps payload
>
> DSI PHY:
> - DSI PHY support for QCM2290
>
> HDMI:
> - Reworked dev init path
>
> 
> Adam Skladowski (2):
>   dt-bindings: display/msm: add support for SM6115
>   drm/msm/disp/dpu1: add support for display on SM6115
>
> Bryan O'Donoghue (1):
>   dt-bindings: msm: dsi-controller-main: Drop redundant phy-names
>
> Dan Carpenter (1):
>   drm/msm/hdmi: remove unnecessary NULL check
>
> Dmitry Baryshkov (25):
>   Merge remote-tracking branch 'msm/msm-fixes' into HEAD

This commit has no justification or signed off by line, I'll let it
slide this once, but no backmerges without justification and please
sign off merges.

Dave.

[Freedreno] Adding CI results to the kernel tree was Re: [RFC v2] drm/msm: Add initial ci/ subdirectory

2022-05-10 Thread Dave Airlie 
> And use it to store expectations about what the drm/msm driver is
> supposed to pass in the IGT test suite.

I wanted to loop in Linus/Greg to see if there are any issues raised
by adding CI results file to the tree in their minds, or if any other
subsystem has done this already, and it's all fine.

I think this is a good thing after our Mesa experience, but Mesa has a
lot tighter integration here, so I want to get some more opinions
outside the group.

Dave.

>
> Also include a configuration file that points to the out-of-tree CI
> scripts.
>
> By storing the test expectations along the code we can make sure both
> stay in sync with each other, and so we can know when a code change
> breaks those expectations.
>
> This will allow all contributors to drm/msm to reuse the infrastructure
> already in gitlab.freedesktop.org to test the driver on several
> generations of the hardware.
>
> v2:
>   - Fix names of result expectation files to match SoC
>   - Don't execute tests that are going to skip on all boards
>
> Signed-off-by: Tomeu Vizoso 
> ---
>  Documentation/gpu/msm_automated_testing.rst   |  70 +
>  drivers/gpu/drm/msm/ci/gitlab-ci.yml  |  11 ++
>  drivers/gpu/drm/msm/ci/msm.testlist   | 148 ++
>  .../gpu/drm/msm/ci/msm_apq8016_results.txt| 140 +
>  .../gpu/drm/msm/ci/msm_apq8096_results.txt| 140 +
>  drivers/gpu/drm/msm/ci/msm_sc7180_results.txt | 141 +
>  drivers/gpu/drm/msm/ci/msm_sdm845_results.txt | 141 +
>  7 files changed, 791 insertions(+)
>  create mode 100644 Documentation/gpu/msm_automated_testing.rst
>  create mode 100644 drivers/gpu/drm/msm/ci/gitlab-ci.yml
>  create mode 100644 drivers/gpu/drm/msm/ci/msm.testlist
>  create mode 100644 drivers/gpu/drm/msm/ci/msm_apq8016_results.txt
>  create mode 100644 drivers/gpu/drm/msm/ci/msm_apq8096_results.txt
>  create mode 100644 drivers/gpu/drm/msm/ci/msm_sc7180_results.txt
>  create mode 100644 drivers/gpu/drm/msm/ci/msm_sdm845_results.txt
>
> diff --git a/Documentation/gpu/msm_automated_testing.rst 
> b/Documentation/gpu/msm_automated_testing.rst
> new file mode 100644
> index ..fe59474569c2
> --- /dev/null
> +++ b/Documentation/gpu/msm_automated_testing.rst
> @@ -0,0 +1,70 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +=
> +Automated testing of MSM DRM driver
> +=
> +
> +
> +Introduction
> +
> +
> +Making sure that changes to a driver don't introduce regressions can be very 
> time consuming when lots of different hardware configurations need to be 
> tested. Moreover, it isn't practical for each person interested in this 
> testing to have to acquire and maintain what can be a considerable amount of 
> hardware.
> +
> +Also, it is desirable for developers to check for regressions in their code 
> by themselves, instead of relying on the maintainer finding them and then 
> reporting back.
> +
> +There are facilities in gitlab.freedesktop.org to automatically test Mesa 
> that can be used as well for testing DRM drivers such as drm/msm. This 
> document explains how people interested in testing the drm/msm driver can use 
> this shared infrastructure to save quite some time and effort.
> +
> +
> +Relevant files
> +==
> +
> +drivers/gpu/drm/msm/ci/gitlab-ci.yml
> +
> +
> +Specifies the specific version of the scripts to be used. GitLab CI will use 
> the values defined in this file to fetch the right scripts.
> +
> +
> +drivers/gpu/drm/msm/ci/msm.testlist
> +---
> +
> +Specifies the tests that the current code is expected to be able to reliably 
> run. These tests are expected to not hang the DUT (device under testing) when 
> running on the revision they belong to, and to give consistent results.
> +
> +
> +drivers/gpu/drm/msm/ci/msm_*_results.txt
> +
> +
> +Specifies the expected results of running this specific kernel revision on a 
> given hardware configuration.
> +
> +
> +How to enable automated testing on your tree
> +
> +
> +1. Create a Linux tree in https://gitlab.freedesktop.org/ if you don't have 
> one yet
> +
> +2. In your kernel repo's configuration (eg. 
> https://gitlab.freedesktop.org/tomeu/linux/-/settings/ci_cd), change the 
> CI/CD configuration file from .gitlab-ci.yml to 
> drivers/gpu/drm/msm/ci/gitlab-ci.yml.
> +
> +3. Next time you push to this repository, you will see a CI pipeline being 
> created (eg. https://gitlab.freedesktop.org/tomeu/linux/-/pipelines)
> +
> +4. The various jobs will be run and when the pipeline is finished, all jobs 
> should be green unless a regression has been found.
> +
> +
> +How to update test expectations
> +===
> +
> +If your changes to the code fix any tests, you will have to update

Re: [Freedreno] [pull] drm/msm: msm-next for 5.10

2020-09-28 Thread Dave Airlie 
Assuming I merged it right,

32-bit builds adds warning
In file included from
/home/airlied/devel/kernel/dim/src/include/linux/bitops.h:5,
 from
/home/airlied/devel/kernel/dim/src/include/linux/kernel.h:12,
 from
/home/airlied/devel/kernel/dim/src/include/linux/ascii85.h:11,
 from
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/msm/adreno/adreno_gpu.c:9:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/msm/adreno/adreno_gpu.c:
In function ‘adreno_iommu_create_address_space’:
/home/airlied/devel/kernel/dim/src/include/linux/bits.h:36:11:
warning: right shift count is negative [-Wshift-count-negative]
   (~UL(0) >> (BITS_PER_LONG - 1 - (h
   ^~
/home/airlied/devel/kernel/dim/src/include/linux/bits.h:38:31: note:
in expansion of macro ‘__GENMASK’
  (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
   ^
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/msm/adreno/adreno_gpu.c:212:11:
note: in expansion of macro ‘GENMASK’
   start & GENMASK(48, 0), size);
   ^~~

  CC [M]  drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.o
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c:
In function ‘msm_dsi_pll_7nm_init’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c:882:19:
warning: conversion from ‘long long unsigned int’ to ‘long unsigned
int’ changes value from ‘50’ to ‘705032704’ [-Woverflow]
   pll->max_rate = 50UL;
   ^~~~
  LD [M]  drivers/gpu/drm/msm/msm.o

Dave.

On Mon, 28 Sep 2020 at 03:14, Rob Clark  wrote:
>
> Hi Dave,
>
> A bit bigger this time around, with the addition of DP support
> which has been baking for a while now.  Overall:
>
> * DSI support for sm8150/sm8250
> * Support for per-process GPU pagetables (finally!) for a6xx.
>   There are still some iommu/arm-smmu changes required to
>   enable, without which it will fallback to the current single
>   pgtable state.  The first part (ie. what doesn't depend on
>   drm side patches) is queued up for v5.10[1].
> * DisplayPort support.  Userspace DP compliance tool support
>   is already merged in IGT[2]
> * The usual assortment of smaller fixes/cleanups
>
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/updates
> [2] 
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/222051026b978ebbc0dc58db62d7a1f29728f95f
>
> The following changes since commit f6828e0c4045f03f9cf2df6c2a768102641183f4:
>
>   drm/msm: Disable the RPTR shadow (2020-09-04 12:14:15 -0700)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-next-2020-09-27
>
> for you to fetch changes up to d1ea914925856d397b0b3241428f20b945e31434:
>
>   drm/msm/dp: fix incorrect function prototype of dp_debug_get()
> (2020-09-25 20:31:06 -0700)
>
> 
> Abhinav Kumar (10):
>   drm/msm/dp: store dp_display in the driver data
>   drm/msm/dp: add audio support for Display Port on MSM
>   drm/msm/dp: add hook_plugged_cb hdmi-codec op for MSM DP driver
>   drm/msm/dp: signal the hotplug disconnect in the event handler
>   drm/msm/dp: wait for audio notification before disabling clocks
>   drm/msm/dp: add debugfs support to DP driver
>   drm/msm/dp: move debugfs node to /sys/kernel/debug/dri/*/
>   drm/msm/dp: add debugfs nodes for video pattern tests
>   drm/msm/dp: remove mode hard-coding in case of DP CTS
>   drm/msm/dp: fix incorrect function prototype of dp_debug_get()
>
> Akhil P Oommen (2):
>   drm/msm: Fix premature purging of BO
>   drm/msm: Leave inuse count intact on map failure
>
> Bernard Zhao (1):
>   drm/msm/adreno: remove return value of function XX_print
>
> Chandan Uddaraju (3):
>   drm: add constant N value in helper file
>   drm/msm/dp: add displayPort driver support
>   drm/msm/dp: add support for DP PLL driver
>
> Georgi Djakov (1):
>   drm/msm: Remove depends on interconnect
>
> Jeykumar Sankaran (1):
>   drm/msm/dpu: add display port support in DPU
>
> Jonathan Marek (3):
>   drm/msm/dsi: remove unused clk_pre/clk_post in msm_dsi_dphy_timing
>   drm/msm/dsi: add DSI config for sm8150 and sm8250
>   drm/msm/dsi: add support for 7nm DSI PHY/PLL
>
> Jordan Crouse (10):
>   drm/msm: Add a context pointer to the submitqueue
>   drm/msm: Drop context arg to gpu->submit()
>   drm/msm: Set the global virtual address range from the IOMMU domain
>   drm/msm: Add support to create a local pagetable
>   drm/msm: Add support for private address space instances
>   drm/msm/a6xx: Add support for per-instance pagetables
>   drm/msm: Allow a5xx to mark the RPTR shadow as privileged
>   drm/msm: a6xx: Use WHERE_AM_I for eligible targets
>   drm/msm: Get rid of the REG_ADRENO offsets
>   drm/msm: Fix the a650 hw_apriv

Re: [Freedreno] [PATCH v11 1/2] drm/panel: add support for rm69299 visionox panel driver

2020-05-13 Thread Dave Airlie 
On Thu, 7 May 2020 at 04:57, Sam Ravnborg  wrote:
>
> Hi Harigovindan
>
> On Wed, Apr 29, 2020 at 11:15:14AM +0530, Harigovindan P wrote:
> > Add support for Visionox panel driver.
> >
> > Signed-off-by: Harigovindan P 
> > Reviewed-by: Matthias Kaehlcke 
>
> Thanks for your persistence on this.
> Patch applied.
>
> I fixed a few lingering --strict releated checkpatch warnings
> when I applied.
>
> Sam

I'm seeing

WARNING: modpost: missing MODULE_LICENSE() in
drivers/gpu/drm/panel/panel-visionox-rm69299.o

Can we fix that up?

Dave.

>
> > ---
> >
> > Changes in v2:
> >   - Dropping redundant space in Kconfig(Sam Ravnborg).
> >   - Changing structure for include files(Sam Ravnborg).
> >   - Removing backlight related code and functions(Sam Ravnborg).
> >   - Removing repeated printing of error message(Sam Ravnborg).
> >   - Adding drm_connector as an argument for get_modes function.
> > Changes in v3:
> >   - Adding arguments for drm_panel_init to support against mainline.
> > Changes in v4:
> >   - Removing error messages from regulator_set_load.
> >   - Removing dev struct entry.
> >   - Removing checks.
> >   - Dropping empty comment lines.
> > Changes in v5:
> >   - Removing unused struct member variables.
> >   - Removing blank lines.
> >   - Fixed indentation.
> >   - Invoking dsi_detach and panel_remove while early exiting from probe.
> > Changes in v6:
> >   - Changed "35597" to "rm69299" for power_on function.
> >   - Removing rm69299_config since it supports single type of panel for 
> > now.
> >   - Fixed alignment.
> >   - Using goto statements when regulator_set_load fails.
> > Changes in v7:
> >   - Added new goto statement when regulator_set_load fails.
> > Changes in v8,v9,v10:
> >   - Had changes in first patch, did not make any change in panel driver.
> > Changes in v11:
> >   - Fixing checkpatch script errors.
> >   - Updated assignment of panel.dev property in  probe.
> >
> >  drivers/gpu/drm/panel/Kconfig |   8 +
> >  drivers/gpu/drm/panel/Makefile|   1 +
> >  .../gpu/drm/panel/panel-visionox-rm69299.c| 304 ++
> >  3 files changed, 313 insertions(+)
> >  create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index d56258b9fcaf..4b6131f5893d 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -444,6 +444,14 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
> > Say Y here if you want to enable support for Truly NT35597 WQXGA 
> > Dual DSI
> > Video Mode panel
> >
> > +config DRM_PANEL_VISIONOX_RM69299
> > + tristate "Visionox RM69299"
> > + depends on OF
> > + depends on DRM_MIPI_DSI
> > + help
> > +   Say Y here if you want to enable support for Visionox
> > +   RM69299  DSI Video Mode panel.
> > +
> >  config DRM_PANEL_XINPENG_XPP055C272
> >   tristate "Xinpeng XPP055C272 panel driver"
> >   depends on OF
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index 2335a1e32ae0..8eac3e6fa82c 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -47,4 +47,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += 
> > panel-tpo-td028ttec1.o
> >  obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
> >  obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
> >  obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> > +obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
> >  obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
> > diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c 
> > b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> > new file mode 100644
> > index ..3ef4cc80044a
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> > @@ -0,0 +1,304 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct visionox_rm69299 {
> > + struct drm_panel panel;
> > + struct regulator_bulk_data supplies[2];
> > + struct gpio_desc *reset_gpio;
> > + struct mipi_dsi_device *dsi;
> > + bool prepared;
> > + bool enabled;
> > +};
> > +
> > +static inline struct visionox_rm69299 *panel_to_ctx(struct drm_panel 
> > *panel)
> > +{
> > + return container_of(panel, struct visionox_rm69299, panel);
> > +}
> > +
> > +static int visionox_rm69299_power_on(struct visionox_rm69299 *ctx)
> > +{
> > + int ret;
> > +
> > + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> > + if (ret < 0)
> > +

Re: [Freedreno] [pull] drm/msm: msm-next for 5.3

2019-06-26 Thread Dave Airlie 
On Wed, 26 Jun 2019 at 08:34, Rob Clark  wrote:
>
> Hi Dave,
>

Naughty naughty rebase.

dim: f47bee2ba447 ("drm/msm/a3xx: remove TPL1 regs from snapshot"):
Subject in fixes line doesn't match referenced commit:
dim: 7198e6b03155 drm/msm: add a3xx gpu support
dim: fc19cbb785d7 ("drm/msm/mdp5: Fix mdp5_cfg_init error return"):
Subject in fixes line doesn't match referenced commit:
dim: 2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg module)

Please fix or squash those and resend.

Dave.
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

2019-04-25 Thread Dave Airlie 
Daniel, drm-misc-next-fixes?

Dave.

On Fri, 26 Apr 2019 at 12:25,  wrote:
>
> Hi Dave,
>
> > -Original Message-
> > From: Dave Airlie [mailto:airl...@gmail.com]
> > Sent: Friday, April 26, 2019 11:19 AM
> > To: Yamada, Masahiro/山田 真弘 
> > Cc: David Airlie ; Daniel Vetter ;
> > dri-devel ; nouveau
> > ; Sam Ravnborg ; David
> > (ChunMing) Zhou ; amd-gfx mailing list
> > ; James (Qian) Wang
> > ; Ben Skeggs ;
> > linux-arm-msm ; Intel Graphics
> > Development ;
> > intel-gvt-...@lists.freedesktop.org; Linux Kernel Mailing List
> > ; Christian König
> > ; Alex Deucher ;
> > freedreno@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with
> > $(srctree)/
> >
> > On Fri, 26 Apr 2019 at 11:46, Masahiro Yamada
> >  wrote:
> > >
> > > Hi.
> > >
> > >
> > > On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
> > >  wrote:
> > > >
> > > > Currently, the Kbuild core manipulates header search paths in a crazy
> > > > way [1].
> > > >
> > > > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> > > > the search paths in the srctree. Some Makefiles are already written
> > in
> > > > that way, but not all. The goal of this work is to make the notation
> > > > consistent, and finally get rid of the gross hacks.
> > > >
> > > > Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> > > > ("kbuild: do not drop -I without parameter").
> > > >
> > > > [1]: https://patchwork.kernel.org/patch/9632347/
> > > >
> > > > Signed-off-by: Masahiro Yamada 
> > > > Reviewed-by: Sam Ravnborg 
> > > > ---
> > > >
> > > > I put all gpu/drm changes into a single patch because
> > > > they are trivial conversion.
> > > >
> > > > If you are interested in the big picture of this work,
> > > > the full patch set is available at the following URL.
> > > >
> > > >
> > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.g
> > it build-test
> > >
> > >
> > > Is somebody taking care of this?
> > >
> >
> > Are you expecting this to be merged in the drm tree? if so please
> > indicate that when posting.
>
>
> Sorry for unclearness.
>
> Could you apply this to your drm tree?
>
> Thanks.
>
>
>
>
> > I'd assumed this would go via kbuild tree.
> >
> > If the later,
> > Acked-by: Dave Airlie 
> > Dave.
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

2017-08-08 Thread Dave Airlie 
On 9 August 2017 at 09:42, Joe Kniss  wrote:
> Because all drivers currently use gem objects for framebuffer planes,
> the virtual create_handle() is not required.  This change adds a
> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
> create_handle() function pointer from drm_framebuffer_funcs.  The
> corresponding *_create_handle() function is removed from each driver.
>
> In many cases this change eliminates a struct *_framebuffer object,
> as the only need for the derived struct is the addition of the gem
> object pointer.

Why the libdrm in the tag? this isn't for libdrm.

This will break drivers that don't current implement the virtual at all.

I think vwmgfx.

The current code checks if the virtual is there before callng it, this code
just calls the gem code always.

Dave.
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno