On 03/04/2019 22:56, Sean Paul wrote:
> From: Sean Paul
>
> The file was removed in the below patch and is causing this error:
> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function
> Canvas ../drivers/gpu/drm/meson/meson_canvas.c' failed with return code
>
> Fixes: 2bf6b5b0
On Thu, Apr 4, 2019 at 7:51 AM Gerd Hoffmann wrote:
>
> On Thu, Apr 04, 2019 at 12:58:09PM +1000, David Airlie wrote:
> > On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
> > >
> > > Time to kill some bad sample code people are copying from ;)
> > >
> > > This is a complete rewrite of the cirr
Fixed the warnings: Function parameter or member 'xxx' not described
when make htmldocs
This patch depends on:
- https://patchwork.freedesktop.org/series/54448/
- https://patchwork.freedesktop.org/series/54449/
- https://patchwork.freedesktop.org/series/54450/
Signed-off-by: James Qian Wang (Arm
On Thu, Apr 04, 2019 at 12:58:09PM +1000, David Airlie wrote:
> On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
> >
> > Time to kill some bad sample code people are copying from ;)
> >
> > This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> > function is pretty much the o
On Wed, 2019-04-03 at 23:07 +0200, Sam Ravnborg wrote:
> Hi Joe.
>
> Thanks for your patch.
>
> > ---
> > drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 210
> > +
> > 1 file changed, 136 insertions(+), 74 deletions(-)
>
> Hmmm, add more lines than it deletes.
Yeah,
Hi Dave, Daniel,
Fixes for 5.1:
- Fix for pcie dpm
- Powerplay fixes for vega20
- Fix vbios display on reboot if driver display state is retained
- Gfx9 resume robustness fix
The following changes since commit 0ab925d3690614aa44cd29fb84cdcef03eab97dc:
drm/amd/display: Only allow VRR when vrefr
On Wed, Apr 3, 2019 at 7:58 PM David Airlie wrote:
> On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
> >
> > Time to kill some bad sample code people are copying from ;)
> >
> > This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> > function is pretty much the only funct
On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
>
> Time to kill some bad sample code people are copying from ;)
>
> This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> function is pretty much the only function which is carried over largely
> unmodified. Everything else
On Thu, 4 Apr 2019 at 02:07, Thierry Reding wrote:
>
> On Fri, Mar 22, 2019 at 02:15:17PM +0100, Thierry Reding wrote:
> > Hi Dave,
> >
> > The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
> >
> > Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
> >
> > are available in the
https://bugs.freedesktop.org/show_bug.cgi?id=108029
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEEDINFO
https://bugs.freedesktop.org/show_bug.cgi?id=108979
--- Comment #5 from Timothy Arceri ---
Ideally you would try building Mesa from git and do a git bisect to find the
commit that broke things. Or if you can do that you could try getting an
apitrace [1] of the issue so that someone else can bisec
https://bugs.freedesktop.org/show_bug.cgi?id=109712
Timothy Arceri changed:
What|Removed |Added
Product|Mesa|DRI
Component|Drivers/Gallium
For a while, we've had the problem of i2c bus access not grabbing
a runtime PM ref when it's being used in userspace by i2c-dev, resulting
in nouveau spamming the kernel log with errors if anything attempts to
access the i2c bus while the GPU is in runtime suspend. An example:
[ 130.078386] nouve
[dropping the robot]
I think Philip fixed those issues on amd-staging-drm-next. Either some
fixes are missing on drm-next-5.2-wip, or they are there but should be
squashed to avoid hitting these errors on intermediate builds.
Regards,
Felix
On 2019-04-03 2:26 p.m., kbuild test robot wrote:
Hi Joe.
Thanks for your patch.
> ---
> drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 210
> +
> 1 file changed, 136 insertions(+), 74 deletions(-)
Hmmm, add more lines than it deletes.
>
> diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> b/drivers
From: Sean Paul
The file was removed in the below patch and is causing this error:
WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function Canvas
../drivers/gpu/drm/meson/meson_canvas.c' failed with return code
Fixes: 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provide
To all X.Org Foundation Members:
We're currently halfway through our annual election at 71.4% turnout. If you
haven't done so please login to https://members.x.org/, click on the Active
ballot "X.Org 2019 Elections v2 and xorg+fdo merger" and leave your vote.
In order to pass the proposed bylaw
On Wed, 2019-04-03 at 10:11 -0700, Joe Perches wrote:
> On Wed, 2019-04-03 at 18:17 +0200, Thierry Reding wrote:
> > On Mon, Apr 01, 2019 at 12:35:32PM +0200, Guido Günther wrote:
> > > v4 fixes up the DT binding example and uses a wider cc list since I
> > > failed to extend that when touching mor
Hi Tomi & Laurent,
On Tue, Apr 02, 2019 at 06:55:08PM +0300, Laurent Pinchart wrote:
> On Tue, Apr 02, 2019 at 06:36:21PM +0300, Tomi Valkeinen wrote:
> > On 21/11/2018 18:09, Sebastian Reichel wrote:
> > > Hi,
> > >
> > > Here is another round of the DSI command mode panel patchset
> > > integra
On Wed, Apr 03, 2019 at 10:22:16PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 03, 2019 at 12:07:35PM -0700, Manasi Navare wrote:
> > On Wed, Apr 03, 2019 at 09:55:56PM +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> > > > On Wed, Apr 03, 2019 at 03:
Hi,
I’m working to add writeback support to vkms; you can see my current
patch at the end of this email (some prints highlight the issue that I’m
asking for help here). I’m using the Liviu Dudau and Brian Starkey IGT
patchset, which can be seen here:
https://patchwork.freedesktop.org/series/39229/
On Wed, Apr 03, 2019 at 12:07:35PM -0700, Manasi Navare wrote:
> On Wed, Apr 03, 2019 at 09:55:56PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> > > On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Apr 02, 2019 at 02:
Paul Kocialkowski writes:
> Hi,
>
> On Mon, 2019-04-01 at 11:35 -0700, Eric Anholt wrote:
>> One might want to use the VC4 display stack without using Mesa.
>> Similar to the debugfs fixes for not having all of the possible
>> display bits enabled, make sure you can't oops in vc4 if v3d isn't
>>
On Wed, Apr 03, 2019 at 09:55:56PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> > On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > > > For certain eDP 1.4 panels,
Paul Kocialkowski writes:
> Since the OOM interrupt directly deals with the binner bo, it doesn't
> make sense to try and handle it without a binner buffer registered.
> The interrupt will kick again in due time, so we can safely ignore it
> without a binner bo allocated.
>
> Signed-off-by: Paul
On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > > For certain eDP 1.4 panels, we need to use max lane count for the
> > > link training to succeed.
Paul Kocialkowski writes:
> The binner bo is not required until the V3D is in use, so avoid
> allocating it at probe and do it on the first non-dumb BO allocation.
> Keep track of which clients are using the V3D and liberate the buffer
> when there is none left.
>
> We also want to keep it alive
On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > For certain eDP 1.4 panels, we need to use max lane count for the
> > link training to succeed.
> >
> > This patch adds a EDID quirk for such eDP panels using
> > the
On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and vari
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 5666aea3ea494d4dd96df8f092cab32dbeeac321
commit: 95db8d6001df8966e3370a66c9f358925fbcc890 [21/42] drm/amdgpu: replace
get_user_pages with HMM mirror helpers
config: s390-allyesconfig (attached as .config)
compiler: s390
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 5666aea3ea494d4dd96df8f092cab32dbeeac321
commit: ba5896bd6a1a175b21609c6c81dea9813cbf296c [19/42] drm/amdgpu: use HMM
callback to replace mmu notifier
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-l
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 5666aea3ea494d4dd96df8f092cab32dbeeac321
commit: 95db8d6001df8966e3370a66c9f358925fbcc890 [21/42] drm/amdgpu: replace
get_user_pages with HMM mirror helpers
config: mips-allyesconfig (attached as .config)
compiler: mips
https://bugs.freedesktop.org/show_bug.cgi?id=110258
--- Comment #3 from ukbeas...@protonmail.com ---
I am able to use 4.19LTS with amdgpu.dc=0 to have suspend working.
I hope the next 5.1 gets fixed.
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Rob,
On 3/27/19 11:52 AM, Rob Clark wrote:
> On Wed, Mar 13, 2019 at 8:21 PM Helen Koike wrote:
>>
>> Async update callbacks are expected to set the old_fb in the new_state
>> so prepare/cleanup framebuffers are balanced.
>>
>> Cc: # v4.14+
>> Fixes: 224a4c970987 ("drm/msm: update cursors asy
Hi, any update on this/do you guys need any more information here? Would very
much like to get this upstream
On Fri, 2019-03-22 at 06:30 -0500, Bjorn Helgaas wrote:
> On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote:
> > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote:
> >
On Wed, 2019-04-03 at 18:17 +0200, Thierry Reding wrote:
> On Mon, Apr 01, 2019 at 12:35:32PM +0200, Guido Günther wrote:
> > v4 fixes up the DT binding example and uses a wider cc list since I
> > failed to extend that when touching more files.
[]
> Applied, thanks.
>
> checkpatch does complain a
On Wed, Apr 03, 2019 at 10:15:50PM +0530, Jagan Teki wrote:
> Hi Sam,
>
> On Mon, Apr 1, 2019 at 11:54 PM Sam Ravnborg wrote:
> >
> > Hi Thierry.
> >
> > We have a few panel drivers that are reviewed, at least by me,
> > and next step is either to have someone else to step up and
> > do review or
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #160 from Michel Dänzer ---
To clarify comment 155: If the problem happens with commit 52098fada7e, please
bisect between 6dc96de30329 and that. Otherwise, please bisect between
52098fada7e and the current commit you were testing.
--
Hi Sam,
On Mon, Apr 1, 2019 at 11:54 PM Sam Ravnborg wrote:
>
> Hi Thierry.
>
> We have a few panel drivers that are reviewed, at least by me,
> and next step is either to have someone else to step up and
> do review or to have them applied to drm-misc.
>
> Rocktech jh057n00900 - from Guido Günth
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #159 from Michel Dänzer ---
Andrew, see comments 154 & 155.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.
On Mon, Apr 01, 2019 at 08:24:11PM +0200, Sam Ravnborg wrote:
> Hi Thierry.
>
> We have a few panel drivers that are reviewed, at least by me,
> and next step is either to have someone else to step up and
> do review or to have them applied to drm-misc.
>
> Rocktech jh057n00900 - from Guido Günth
On Thu, Mar 14, 2019 at 01:26:20PM +0100, Paul Cercueil wrote:
> The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components
> are transferred sequentially on a 8-bit bus.
>
> Signed-off-by: Paul Cercueil
> ---
>
> Notes:
> v2: New patch
>
> include/uapi/linux/media-bus-format.h
On Thu, Mar 21, 2019 at 09:07:26AM +0100, Yannick Fertré wrote:
> The panel does not support clock frequency over 30.74 Mhz.
> The clock rate has been reduced to 29.70 Mhz & new timings have
> been computed to get a framerate of 50fps.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/pa
On Thu, Mar 21, 2019 at 09:05:35AM +0100, Yannick Fertré wrote:
> Do not print an error message if the regulator framework
> returns EPROBE_DEFER.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Ap
On Thu, Mar 21, 2019 at 09:04:44AM +0100, Yannick Fertré wrote:
> Do not print an error message if the regulator framework
> returns EPROBE_DEFER.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
https://bugs.freedesktop.org/show_bug.cgi?id=110318
Bug ID: 110318
Summary: Disabling ARB_fragment_shader causes implementation
errors
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
On Thu, Mar 21, 2019 at 09:04:05AM +0100, Yannick Fertré wrote:
> At the end of initialization, a delay is required by the panel.
> Without this delay, the panel could received a frame early &
> generate a crash of panel (black screen).
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/p
On Mon, Apr 01, 2019 at 12:35:32PM +0200, Guido Günther wrote:
> v4 fixes up the DT binding example and uses a wider cc list since I
> failed to extend that when touching more files.
>
> The panel is a 5.5" 720x1440 TFT LCD MIPI DSI panel with built in
> touchscreen and backlight as found in the L
On Mon, Mar 25, 2019 at 05:08:10PM +0100, Guido Günther wrote:
> Some examples were missing the unit names triggering
>
> Warning (unit_address_vs_reg): .../panel: node has a reg or ranges property,
> but no unit name
>
> warnings when used verbatim in DTs and running dtc with W=1.
>
> Signed-
On Fri, Mar 22, 2019 at 02:15:17PM +0100, Thierry Reding wrote:
> Hi Dave,
>
> The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
>
> Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/tegra/linux
On Wed, 2019-04-03 at 16:15 +0100, Daniel Stone wrote:
> There's already a list of supported formats for each DRM plane, which
> you can get via drmModeGetPlane (being careful to enable universal
> planes so you can discover the primary plane). The same information is
> present in the 'IN_FORMATS'
Since the OOM interrupt directly deals with the binner bo, it doesn't
make sense to try and handle it without a binner buffer registered.
The interrupt will kick again in due time, so we can safely ignore it
without a binner bo allocated.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/
The binner bo is not required until the V3D is in use, so avoid
allocating it at probe and do it on the first non-dumb BO allocation.
Keep track of which clients are using the V3D and liberate the buffer
when there is none left.
We also want to keep it alive during runtime suspend/resume to avoid
Changes since v3:
* Split changes into more commits when possible;
* Reworked binner bo alloc condition as discussed.
Changes since v2:
* Removed deprecated sentence about fristopen;
* Added collected Reviewed-By tags.
Changes since v1:
* Squashed the two final patches into one.
Paul Kocialkowsk
Check that we have a V3D device registered before attempting to
allocate a binner buffer object.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_v3d.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers
Since we'll be using the binner bo allocation helper in other parts
of the driver, reformat it with a vc4_v3d prefix and pass the vc4 dev
directly to match other functions.
Make the function visible to the whole driver too.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_v3d.c | 11
On Wed, Feb 13, 2019 at 02:11:08AM +0530, Jagan Teki wrote:
> Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
>
> Add dt-bingings for it.
>
> Signed-off-by: Jagan Teki
> Reviewed-by: Rob Herring
> ---
> Changes for v7, v6, v5, v4, v3:
> - none
> Changes for v2:
> - new patch, d
On Fri, Mar 29, 2019 at 06:09:18PM -0700, Ronan KERYELL wrote:
> I am adding linux-f...@vger.kernel.org, since this is why I missed this
> thread in the first place...
> > On Fri, 29 Mar 2019 14:56:17 +1000, Dave Airlie
> > said:
> Dave> On Thu, 28 Mar 2019 at 10:14, Sonal Santan
>
On 03/21/2019 11:52 PM, Christoph Hellwig wrote:
> Just like we do for all other DMA operations.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
On 03/21/2019 11:52 PM, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
A
On Wed, Apr 03, 2019 at 02:48:11PM +0800, Yue Haibing wrote:
> From: YueHaibing
>
> When building CONFIG_DEBUG_FS is not set
> gcc warn this:
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c: In function a6xx_show:
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:1124:2: error: implicit
> declarati
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #158 from andrew.m.mcma...@gmail.com ---
Hold on a minute!
I've just applied that patch to the latest mesa - now correct me if I'm wrong -
but the source already has that change applied:
https://gitlab.freedesktop.org/mesa/mesa/blob/ma
On Wed, 3 Apr 2019 at 16:12, Adam Jackson wrote:
> On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote:
> > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does
> >that too by default. There was a module parameter which enables 24/32
> >bpp support and disables highe
On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote:
> - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does
>that too by default. There was a module parameter which enables 24/32
>bpp support and disables higher resolutions (due to cirrus hardware
>constrains).
On Wed, Apr 3, 2019 at 4:17 PM Moritz Fischer wrote:
>
> Hi Daniel,
>
> On Wed, Apr 03, 2019 at 03:14:49PM +0200, Daniel Vetter wrote:
> > On Fri, Mar 29, 2019 at 06:09:18PM -0700, Ronan KERYELL wrote:
> > > I am adding linux-f...@vger.kernel.org, since this is why I missed this
> > > thread in th
Hi Daniel,
On Wed, Apr 03, 2019 at 03:14:49PM +0200, Daniel Vetter wrote:
> On Fri, Mar 29, 2019 at 06:09:18PM -0700, Ronan KERYELL wrote:
> > I am adding linux-f...@vger.kernel.org, since this is why I missed this
> > thread in the first place...
> >
> > > On Fri, 29 Mar 2019 14:56:17 +1000,
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #157 from andrew.m.mcma...@gmail.com ---
So I've had a go at compiling mesa with the fix applied.
I'll list what I've done here to be absolutely clear.
Cloned a new copy of mesa
> git clone https://gitlab.freedesktop.org/mesa/mesa.git
On 04/02/2019 11:09 PM, Sudip Mukherjee wrote:
> On Mon, Apr 1, 2019 at 6:41 PM Tom Li wrote:
>>
>> On Sun, Mar 31, 2019 at 08:08:01PM +0100, Sudip Mukherjee wrote:
>>> Technically I donot have any problem with this, you seem to know more
>>> about SM712 than I know. But Teddy Wang is also an exi
Hi,
On Mon, 2019-04-01 at 11:35 -0700, Eric Anholt wrote:
> One might want to use the VC4 display stack without using Mesa.
> Similar to the debugfs fixes for not having all of the possible
> display bits enabled, make sure you can't oops in vc4 if v3d isn't
> enabled.
Just thought about this: pe
On Wed, Apr 03, 2019 at 11:19:52AM +0100, Lee Jones wrote:
> To whom it may concern,
>
> Enjoy!
>
> The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
>
> Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.or
On Wed, Apr 03, 2019 at 02:56:58PM +0200, Noralf Trønnes wrote:
> This is done to stay consistent with our naming scheme of
> _register() = others can start calling us from any thread.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
> ---
> drivers/
On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > For certain eDP 1.4 panels, we need to use max lane count for the
> > link training to succeed.
> >
> > This patch adds a EDID quirk for such eDP panels using
> > the
On Fri, Mar 29, 2019 at 06:09:18PM -0700, Ronan KERYELL wrote:
> I am adding linux-f...@vger.kernel.org, since this is why I missed this
> thread in the first place...
>
> > On Fri, 29 Mar 2019 14:56:17 +1000, Dave Airlie
> > said:
>
> Hi Dave!
>
> Dave> On Thu, 28 Mar 2019 at 10:1
This is done to stay consistent with our naming scheme of
_register() = others can start calling us from any thread.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 11 ++-
drivers/gpu/drm/drm_fb_helper.c | 2 +-
include/drm/drm_client.h
On Wed, Apr 3, 2019 at 1:54 PM Qiang Yu wrote:
>
> Hi guys,
>
> I have some questions after reading the drm maintainer tools doc:
> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
>
> 1. As a committer to drm-misc, do I still need to use dim? Wouldn't just
> raw git command
On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> For certain eDP 1.4 panels, we need to use max lane count for the
> link training to succeed.
>
> This patch adds a EDID quirk for such eDP panels using
> their vendor ID and product ID to force using max lane count in the driver.
R
Hi guys,
I have some questions after reading the drm maintainer tools doc:
https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
1. As a committer to drm-misc, do I still need to use dim? Wouldn't just
raw git commands enough? For example just "git push" to the target
drm-misc b
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #156 from andrew.m.mcma...@gmail.com ---
Picked up XCOM Complete for ~£3 @ Voidu.
I've played it before of course but thought I'd try out Feral's Linux version
rather than playing the Windows-only GOG release through WINE.
Debian Unst
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 02b76b4ae25fd4c0ac0bf07155cc642f9eeccbbd
commit: 02b76b4ae25fd4c0ac0bf07155cc642f9eeccbbd [477/477] drm/amdgpu: fix old
fence check in amdgpu_fence_emit
reproduce:
# apt-get install sparse
git checkout 0
On 02/04/2019 05:16, Andrey Smirnov wrote:
> The early return above causes tc_get_display_props() to never be
> called for eDP case, which in turn result in tc_mode_valid() returning
> MODE_BAD for every mode it is given since it depends on tc->link.base
> being initialized properly. I had to chan
Hi,
> > So I can just remove cirrus_fb_dirty() and hook up
> > drm_atomic_helper_dirtyfb() instead. Easy ;)
>
> You can even use drm_gem_fb_create_with_dirty() instead of
> drm_gem_fb_create_with_funcs().
Ah, cool. /me happily continues removing code lines.
thanks,
Gerd
PS: incremental f
To whom it may concern,
Enjoy!
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
ib-backlight-drm-v5.2
for you to f
On Thu, 17 Jan 2019, Alexander Shiyan wrote:
> This patch removes dependencies on BACKLIGHT_CLASS_DEVICE for items
> that are already placed under #if BACKLIGHT_CLASS_DEVICE.
>
> Signed-off-by: Alexander Shiyan
> ---
> drivers/video/backlight/Kconfig | 25 -
> 1 file cha
Den 03.04.2019 10.53, skrev Gerd Hoffmann:
>>> +struct cirrus_device {
>>> + struct drm_device *dev;
>>
>> Why not embed drm_device? It's the latest rage :-)
>
> Sure, can do that.
>
>>> +void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
>>> +
On Tue, Apr 02, 2019 at 06:40:56PM +0100, Robin Murphy wrote:
> On 01/04/2019 17:06, Liviu Dudau wrote:
> > On Fri, Mar 29, 2019 at 06:46:21PM +, Robin Murphy wrote:
> > > On 19/03/2019 14:49, Liviu Dudau wrote:
> > > > On Tue, Mar 19, 2019 at 01:14:54PM +, Robin Murphy wrote:
> > > > > [ +
https://bugs.freedesktop.org/show_bug.cgi?id=110304
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
Signed-off-by: Mickael Reulier
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/ltdc.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index b1741a9..6fa8fbc 100644
--- a/drivers/gpu/drm/stm/lt
Display controller reset must be done as soon as possible after enable
the clock to avoid partial refresh on screen.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/ltdc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/
Den 02.04.2019 09.55, skrev Daniel Vetter:
> On Mon, Apr 01, 2019 at 04:13:58PM +0200, Noralf Trønnes wrote:
>> Hotplug can happen while drm_fbdev_generic_setup() is running so move
>> drm_client_add() call after setup is done to avoid
>> drm_fbdev_client_hotplug() running in two threads at the s
If the number of layer is greater than LTDC_MAX_LAYER, we can have
memory overflow when reading plane_fpsi[].
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/ltdc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/l
Den 26.03.2019 19.23, skrev Daniel Vetter:
> On Tue, Mar 26, 2019 at 06:55:31PM +0100, Noralf Trønnes wrote:
>> The gamma_size variable has not been used since
>> commit 4abe35204af8 ("drm/kms/fb: use slow work mechanism for normal hotplug
>> also.")
>>
>> While in the area move a comment back t
Den 27.03.2019 17.36, skrev Eric Anholt:
> Noralf Trønnes writes:
>
>> drm_dev_register() initializes internal clients like bootsplash as the
>> last thing it does, so all setup needs to be done at this point.
>>
>> Fix by calling vc4_kms_load() before registering.
>> Also check the error code
Hi,
Le lundi 01 avril 2019 à 11:35 -0700, Eric Anholt a écrit :
> The global list of all debugfs entries for the driver was painful: the
> list couldn't see into the components' structs, so each component had
> its own debugs show function to find the component, then find the
> regset and dump it.
> > +struct cirrus_device {
> > + struct drm_device *dev;
>
> Why not embed drm_device? It's the latest rage :-)
Sure, can do that.
> > +void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
> > + struct drm_plane_state *old_state)
> > +{
> > +
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #61 from Diego Viola ---
I just want to retract myself from saying these commits caused the problem for
me, sorry about that.
As suggested by MrCooper, I've compiled/installed mesa to /usr/local and added
/usr/local/lib to /etc/ld.s
This patch adds documentation of a new property phy-dsi-supply to the
STM32 DSI controller.
Signed-off-by: Yannick Fertré
---
Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc
The dsi physical layer is powered by the 1v8 power controller supply.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
b/arch/arm/boot/dts/stm32mp157c.dtsi
index 6ce75f6..4611b57 100644
--
Add support of an optional regulator for the phy part of the DSI
controller.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-
This property is already defined into stm32mp157c.dtsi file.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c-dk2.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 9a81d2d..d4038e7 100644
---
Move regulators reg11 & reg18 from device-tree files stm32mp157c-ed1.dts
& stm32mp157c-dk2.dts to file stm32mp157c.dtsi.
Signed-off-by: Yannick Fertré
---
arch/arm/boot/dts/stm32mp157c-dk2.dts | 8
arch/arm/boot/dts/stm32mp157c-ed1.dts | 16
arch/arm/boot/dts/stm32mp15
1 - 100 of 111 matches
Mail list logo
