On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi wrote:
> > > tcon-pixel clock is the rate that you want to achive on display side
> > > and if you have 4 lanes 32bit or lanes and different bit number that
> > > you need to have a clock that is able to put outside bits and spee
On Sat, Jul 13, 2019 at 02:03:43PM +0200, Jernej Skrabec wrote:
> In order to correctly convert image between YUV and RGB, you have to
> know color encoding and color range. This patch set adds appropriate
> properties and considers them when choosing CSC conversion matrix for
> DE2 and DE3.
>
> No
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #179 from zaindavid ---
great post.
http://www.winmilliongame.com
http://www.gtagame100.com
http://www.subway-game.com
http://www.zumagame100.com
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=97055
--- Comment #25 from sam zain ---
very useful post. thanks to you.
http://www.winmilliongame.com
http://www.gtagame100.com
http://www.subway-game.com
http://www.zumagame100.com
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=76
Bug ID: 76
Summary: Regression: AMD 2400G warning on resolution change
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>
> On 17/07/2019 19:33, Rob Herring wrote:
> > Setting the GPU VA when creating the GEM object doesn't allow for any
> > conditional adjustments. In preparation to support adjusting the
> > mapping, restructure the GEM object creation to map the
On Fri, Jul 19, 2019 at 4:39 AM Steven Price wrote:
>
> On 18/07/2019 18:03, Rob Herring wrote:
> > On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
> >>
> >> On 17/07/2019 19:33, Rob Herring wrote:
> >>> Executable buffers have an alignment restriction that they can't cross
> >>> 16MB boundar
This memory allocation flag will be used to indicate BOs containing
sensitive data that should not be leaked to other processes.
Signed-off-by: Felix Kuehling
---
include/uapi/drm/amdgpu_drm.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/dr
On Fri, Jul 19, 2019 at 9:40 PM Linus Torvalds
wrote:
>
> On Fri, Jul 19, 2019 at 8:43 AM Daniel Vetter wrote:
> >
> > drm fixes for -rc1:
> >
> > nouveau:
> > - bugfixes + TU116 enabling (minor iteration):w
>
> Asking the important question:
>
> - WTH is that ":w" thing?
>
> I have a theory tha
This notifies the driver that a BO is about to be released.
Releasing a BO also invokes the move_notify callback from
ttm_bo_cleanup_memtype_use, but that happens too late for anything
that would add fences to the BO and require a delayed delete.
Signed-off-by: Felix Kuehling
---
drivers/gpu/dr
Wipe VRAM memory containing sensitive data when moving or releasing
BOs. Clearing the memory is pipelined to minimize any impact on
subsequent memory allocation latency. Use of a poison value should
help debug future use-after-free bugs.
When moving BOs, the existing ttm_bo_pipelined_move ensures
Memory used by KFD applications can contain sensitive information that
should not be leaked to other processes. The current approach to prevent
leaks is to clear VRAM at allocation time. This is not effective because
memory can be reused in other ways without being cleared. Synchronously
clearing m
On Thu, Jul 18, 2019 at 06:14:56PM +0200, Sam Ravnborg wrote:
> First patch from Jani fixes so drm_print.h is self-contained.
> Next two patches are trivial removal of uapi dependencies.
>
> ati_pcigart is fixed to drop use of drm_os_linux.h
>
> drm_vblank is likewise fixed to drop use of drm_os_
The pull request you sent on Fri, 19 Jul 2019 17:42:56 +0200:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-07-19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/31cc088a4f5d83481c6f5041bd6eb06115b974af
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Fri, Jul 19, 2019 at 8:43 AM Daniel Vetter wrote:
>
> drm fixes for -rc1:
>
> nouveau:
> - bugfixes + TU116 enabling (minor iteration):w
Asking the important question:
- WTH is that ":w" thing?
I have a theory that it's just a "I'm confused by 'vi'" marker. Very
understandable.
But I'm al
https://bugzilla.kernel.org/show_bug.cgi?id=204227
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Fri, Jul 19, 2019 at 08:33:49PM +0200, Daniel Vetter wrote:
> On Fri, Jul 19, 2019 at 7:06 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Jul 19, 2019 at 05:23:12PM +0200, Daniel Vetter wrote:
> > > Noticed while reviewing code. I'm not sure whether this might or might
> > > not explain some of the
On Fri, Jul 19, 2019 at 7:06 PM Ville Syrjälä
wrote:
>
> On Fri, Jul 19, 2019 at 05:23:12PM +0200, Daniel Vetter wrote:
> > Noticed while reviewing code. I'm not sure whether this might or might
> > not explain some of the missed vblank hilarity we've been seeing. I
> > think those all go through
On Fri, Jul 19, 2019 at 01:51:36AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/i915/display/icl_dsi.c: In function
> 'gen11_dsi_set_transcoder_timings':
> drivers/gpu/drm/i915/display/icl_dsi.c:768:6: warning:
> variable 'hfront_porch' set but no
On Fri, Jul 19, 2019 at 05:23:12PM +0200, Daniel Vetter wrote:
> Noticed while reviewing code. I'm not sure whether this might or might
> not explain some of the missed vblank hilarity we've been seeing. I
> think those all go through the vblank completion event, which has
> unconditional barriers
On Fri, Jul 19, 2019 at 12:23:26PM -0400, Adam Jackson wrote:
> On Thu, 2019-07-18 at 14:41 -0700, Matthias Kaehlcke wrote:
>
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index 045b1b13fd0e..e49402ebd56f 100644
> > --- a/drivers/gp
On Thu, 2019-07-18 at 14:41 -0700, Matthias Kaehlcke wrote:
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 045b1b13fd0e..e49402ebd56f 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw
The MIPI DBI standard support more pixel formats than what this helper
supports. Add an init function that lets the driver use different
format(s). This avoids open coding mipi_dbi_init() in st7586.
st7586 sets preferred_depth but this is not necessary since it only
supports one format.
v2: Forgo
tinydrm_display_pipe_init() has only one user now, so move it to mipi-dbi.
Changes:
- Remove drm_connector_helper_funcs.detect, it's always connected.
- Store the connector and mode in mipi_dbi instead of it's own struct.
Otherwise remove some leftover tinydrm-helpers.h inclusions.
Cc: Eric Anho
tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers.
Use the new SPI connector type instead.
X server will now list the connector as Unknown instead of Virtual:
X.Org X Server 1.19.2
Release Date: 2017-03-02
<...>
[ 53523.905] (II) modeset(0): Output Unknown19-1 has no monitor
tinydrm.ko is going away so let's implement a connector.
Reviewed-by: Sam Ravnborg
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/repaper.c | 58 ---
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/repaper.c
b/driver
This is only used by mipi-dbi drivers so move it there.
The reason this isn't moved to the SPI subsystem is that it will in a
later patch pass a dummy rx buffer for SPI controllers that need this.
Low memory boards (64MB) can run into a problem allocating such a "large"
contiguous buffer on every
The tinydrm helper is going away so move it into the only user mipi-dbi.
Reviewed-by: Sam Ravnborg
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mipi-dbi.c| 15 ---
include/drm/tinydrm/tinydrm-helpers.h | 15 ---
2 files changed, 12 insertions(+), 18 dele
The SPI event tracing can dump the buffer now so no need for this.
Remove the debug print from tinydrm_spi_transfer() since this info can be
gleaned from the trace event.
Reviewed-by: Sam Ravnborg
Signed-off-by: Noralf Trønnes
---
.../gpu/drm/tinydrm/core/tinydrm-helpers.c| 40 -
Prep work before moving the function to mipi-dbi.
tinydrm_spi_transfer() was made to support one class of drivers in
drivers/staging/fbtft that has not been converted to DRM yet, so strip
away the unused functionality:
- Start byte (header) is not used.
- No driver relies on the automatic 16-bit b
spi-bcm2835 can handle >64kB buffers now so there is no need to check
->max_dma_len. The tinydrm_spi_max_transfer_size() max_len argument is
not used by any callers, so not needed.
Then we have the spi_max module parameter. It was added because
staging/fbtft has support for it and there was a repo
This means that tinydrm_spi_bpw_supported() can be removed.
Reviewed-by: Sam Ravnborg
Signed-off-by: Noralf Trønnes
---
.../gpu/drm/tinydrm/core/tinydrm-helpers.c| 32 +--
drivers/gpu/drm/tinydrm/mipi-dbi.c| 5 ++-
include/drm/tinydrm/tinydrm-helpers.h |
This series removes the remaining bits of tinydrm.ko.
Changes:
- Split SPI connector type patch in core and driver changes, expand
commit message (Daniel)
- Drop moving the mipi_dbi_spi_init() declaration (Sam)
- st7586: Forgot to remove the mipi->rotation assignment
Note:
This depends on a com
tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers.
Add a SPI connector type to match the actual connector.
X will list the connector as Unknown:
X.Org X Server 1.19.2
Release Date: 2017-03-02
<...>
[ 53523.905] (II) modeset(0): Output Unknown19-1 has no monitor section
[ 535
On 2019-07-19 2:37 p.m., Daniel Vetter wrote:
> On Fri, Jul 19, 2019 at 1:32 PM Sam Ravnborg wrote:
>> On Fri, Jul 19, 2019 at 11:05:44AM +0200, Michel Dänzer wrote:
>>> On 2019-07-19 8:07 a.m., Sam Ravnborg wrote:
On Thu, Jul 18, 2019 at 05:37:31PM +0200, Sam Ravnborg wrote:
> This is so
Hi Linus,
Dave is back in shape, but now family got it so I'm doing the pull. Two
things worthy of note:
- nouveau feature pull was way too late, Dave&me decided to not take that,
so Ben spun up a pull with just the fixes.
- after some chatting with the arm display maintainers we decided to
ch
We can reduce the critical section in vkms_vblank_simulate under
output->lock quite a lot:
- hrtimer_forward_now just needs to be ordered correctly wrt
drm_crtc_handle_vblank. We already access the hrtimer timestamp
without locks. While auditing that I noticed that we don't correctly
annotat
Noticed while reviewing code. I'm not sure whether this might or might
not explain some of the missed vblank hilarity we've been seeing. I
think those all go through the vblank completion event, which has
unconditional barriers - it always takes the spinlock. Therefore no
cc stable.
v2:
- Barrrier
It's the recommended version, wait_for_vblanks is a bit a hacky
interim thing that predates all the flip_done tracking. It's
unfortunately still the default ...
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
On Fri, Jul 19, 2019 at 2:09 AM Daniel Vetter wrote:
>
> On Tue, Jul 16, 2019 at 09:42:15AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Since there is no real device associated with vgem, it is impossible to
> > end up with appropriate dev->dma_ops, meaning that we have no way to
> > inva
On Fri, Jul 19, 2019 at 05:15:28PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 19, 2019 at 09:55:58AM -0400, Sean Paul wrote:
> > On Fri, Jul 19, 2019 at 11:05:53AM +0200, Daniel Vetter wrote:
> > > On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sankaran wrote:
> > > > On 2019-07-16 02:07, Daniel
On Thu, Jul 18, 2019 at 10:38 AM Timur Kristóf wrote:
>
>
> > >
> > > I took a look at amdgpu_device_get_pcie_info() and found that it
> > > uses
> > > pcie_bandwidth_available to determine the capabilities of the PCIe
> > > port. However, pcie_bandwidth_available gives you only the current
> > >
On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>
> On 17/07/2019 19:33, Rob Herring wrote:
> > The midgard/bifrost GPUs need to allocate GPU heap memory which is
> > allocated on GPU page faults and not pinned in memory. The vendor driver
> > calls this functionality GROW_ON_GPF.
> >
> > This
On Fri, Jul 19, 2019 at 09:55:58AM -0400, Sean Paul wrote:
> On Fri, Jul 19, 2019 at 11:05:53AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sankaran wrote:
> > > On 2019-07-16 02:07, Daniel Vetter wrote:
> > > > On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykum
On Fri, Jul 19, 2019 at 11:05:53AM +0200, Daniel Vetter wrote:
> On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sankaran wrote:
> > On 2019-07-16 02:07, Daniel Vetter wrote:
> > > On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykumar Sankaran wrote:
> > > > Hello All,
> > > > drm_mode_
Hi Lucas & Ahmad,
Many thanks for your patch,
Tested successfully on stm32mp157-dk2 (weston & drm).
Acked-by: Philippe Cornu
Tested-by: Philippe Cornu
Philippe :-)
On 7/12/19 10:42 AM, Lucas Stach wrote:
> From: Ahmad Fatoum
>
> To properly synchronize with other devices the fence from the
On Fri, Jul 19, 2019 at 12:05:36PM +, Koenig, Christian wrote:
> Am 19.07.19 um 11:31 schrieb Daniel Vetter:
> > On Fri, Jul 19, 2019 at 09:14:05AM +, Koenig, Christian wrote:
> >> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> >>> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wr
On Thu, Jul 18, 2019 at 08:51:50PM +0200, Daniel Vetter wrote:
> On Tue, Jul 09, 2019 at 09:58:08PM +0800, YueHaibing wrote:
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > drivers/gpu/drm/arm/display/komeda/komeda_plane.c:
> > In function komeda_plane_atomic_duplicate_state:
> > drive
On Fri, Jul 05, 2019 at 05:14:47PM +0200, Daniel Vetter wrote:
> On Thu, Jul 04, 2019 at 04:50:54PM +0200, Daniel Vetter wrote:
> > We've had this already for anything new. With my drm_prime.c cleanup I
> > also think documentation for everything already existing is complete,
> > and we can bake th
On Thu, Jun 27, 2019 at 09:33:50AM +0200, Daniel Vetter wrote:
> On Wed, Jun 26, 2019 at 10:23:12AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 26, 2019 at 07:10:21AM +, Koenig, Christian wrote:
> > > Those patches would become superfluous when merging Gerd's work.
> >
> > Not entirely, they s
On Fri, Jul 19, 2019 at 02:41:00AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/i915/display/intel_sprite.c: In function
> 'g4x_sprite_check_scaling':
> drivers/gpu/drm/i915/display/intel_sprite.c:1494:13: warning:
> variable 'src_y' set but not u
On Fri, Jul 19, 2019 at 2:34 PM Noralf Trønnes wrote:
>
>
>
> Den 19.07.2019 11.17, skrev Daniel Vetter:
> > On Wed, Jul 17, 2019 at 01:58:08PM +0200, Noralf Trønnes wrote:
> >> tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers.
> >> Stop lying and add a SPI connector type
>
On Fri, Jul 19, 2019 at 1:32 PM Sam Ravnborg wrote:
>
> Hi Michael.
>
> On Fri, Jul 19, 2019 at 11:05:44AM +0200, Michel Dänzer wrote:
> > On 2019-07-19 8:07 a.m., Sam Ravnborg wrote:
> > > On Thu, Jul 18, 2019 at 05:37:31PM +0200, Sam Ravnborg wrote:
> > >> This is some janitorial updates to the
Den 19.07.2019 11.17, skrev Daniel Vetter:
> On Wed, Jul 17, 2019 at 01:58:08PM +0200, Noralf Trønnes wrote:
>> tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers.
>> Stop lying and add a SPI connector type
>>
>> Cc: David Lechner
>> Signed-off-by: Noralf Trønnes
>
> Note
On Fri, Jul 19, 2019 at 02:57:51PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 19, 2019 at 02:15:34PM +0530, Sharma, Shashank wrote:
> > Hi Ville,
> >
> > On 7/11/2019 4:02 PM, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We're going to need two cea mode tables (on for VICs < 128,
> >
Am 19.07.19 um 11:31 schrieb Daniel Vetter:
> On Fri, Jul 19, 2019 at 09:14:05AM +, Koenig, Christian wrote:
>> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
>>> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
Am 26.06.19 um 14:29 schrieb Daniel Vetter:
[SNIP]
>>> Well
On Fri, Jul 19, 2019 at 02:15:34PM +0530, Sharma, Shashank wrote:
> Hi Ville,
>
> On 7/11/2019 4:02 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We're going to need two cea mode tables (on for VICs < 128,
> > another one for VICs >= 193). To that end replace the direct
> > edid_cea_mo
On Fri, Jul 19, 2019 at 05:58:42PM +0800, Wen He wrote:
> Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
> This property describe the ARQoS levels of DP500's QoS signaling.
>
> Signed-off-by: Wen He
Acked-by: Liviu Dudau
Thanks for the patch!
Best regards,
Liviu
> --
On Fri, Jul 19, 2019 at 05:54:45PM +0800, Wen He wrote:
> Configure the display Quality of service (QoS) levels priority if the
> optional property node "arm,malidp-aqros-value" is defined in DTS file.
>
> QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
> driven from the "R
On Fri, Jul 19, 2019 at 09:09:30AM +, Lowry Li (Arm Technology China) wrote:
> Hi Liviu,
>
> On Thu, Jul 18, 2019 at 01:17:37PM +, Liviu Dudau wrote:
> > On Thu, Jun 27, 2019 at 04:10:36AM +0100, Lowry Li (Arm Technology China)
> > wrote:
> > > Adds to print the event message when error h
Hi Michael.
On Fri, Jul 19, 2019 at 11:05:44AM +0200, Michel Dänzer wrote:
> On 2019-07-19 8:07 a.m., Sam Ravnborg wrote:
> > On Thu, Jul 18, 2019 at 05:37:31PM +0200, Sam Ravnborg wrote:
> >> This is some janitorial updates to the via driver
> >> that is required to get rid of deprecated headers
Hi Christian.
Thanks for your comments and very valid question.
On Fri, Jul 19, 2019 at 06:56:47AM +, Koenig, Christian wrote:
> Am 18.07.19 um 18:15 schrieb Sam Ravnborg:
> > drm_file used drm_magic_t from uapi/drm/drm.h.
> > This is a simple unsigned int.
> > Just opencode it as such to bre
dev_get_drvdata is a simpler implementation comparing
to to_platform_device + platform_get_drvdata.
This makes the code simpler.
Signed-off-by: Chuhong Yuan
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
2 files changed, 2 insertions(+), 2
The new LS1028A DP driver code causes a link failure when DRM_IMX built-in,
but platform is ARCH_LAYERSCAPE:
drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to `ipu_prg_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to `ipu_dc_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:53:
This patch enables the HDP controller driver on the LS1028A.
Signed-off-by: Alison Wang
Signed-off-by: Wen He
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 25 +++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
b/arch/arm64/b
This patch add HDP PHY Controller related nodes on the LS1028ARDB.
Signed-off-by: Alison Wang
Signed-off-by: Wen He
---
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
b/arch/a
This patch add HDP PHY Controller related nodes on the LS1028AQDS.
Signed-off-by: Alison Wang
Signed-off-by: Wen He
---
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
b/arch/a
Add DT bindings documentmation for the HDP-TX PHY controller. The describes
which could be found on NXP Layerscape ls1028a platform.
Signed-off-by: Wen He
---
change in v2:
- correction the node name.
.../devicetree/bindings/display/fsl,hdp.txt | 56 +++
1 file changed
Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
This property describe the ARQoS levels of DP500's QoS signaling.
Signed-off-by: Wen He
---
Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/device
Configure the display Quality of service (QoS) levels priority if the
optional property node "arm,malidp-aqros-value" is defined in DTS file.
QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
driven from the "RQOS" register, so needed to program the RQOS register
to avoid the
On 19.07.2019 10:33, Arnd Bergmann wrote:
> On Fri, Jul 19, 2019 at 9:01 AM Andrzej Hajda wrote:
>> On 18.07.2019 15:42, Arnd Bergmann wrote:
>>> Using 'imply' causes a new problem, as it allows the case of
>>> CONFIG_INPUT=m with RC_CORE=y, which fails to link:
>>
>> I have reviewed dependencies
On Fri, Jul 19, 2019 at 11:05:44AM +0200, Michel Dänzer wrote:
> On 2019-07-19 8:07 a.m., Sam Ravnborg wrote:
> > On Thu, Jul 18, 2019 at 05:37:31PM +0200, Sam Ravnborg wrote:
> >> This is some janitorial updates to the via driver
> >> that is required to get rid of deprecated headers
> >> in the d
Hi Sean,
On Thu, Jul 18, 2019 at 11:23:50AM -0400, Sean Paul wrote:
> On Thu, Jul 18, 2019 at 02:17:37PM +0100, Liviu Dudau wrote:
> > On Thu, Jun 27, 2019 at 04:10:36AM +0100, Lowry Li (Arm Technology China)
> > wrote:
>
> /snip
>
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_km
On Fri, Jul 19, 2019 at 09:14:05AM +, Koenig, Christian wrote:
> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> > On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
> >> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> >>> On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrot
On Thu, Jul 18, 2019 at 9:39 AM Ben Skeggs wrote:
> Various cleanup patches, improvements to display colour management,
> fixes to ACR ("secure boot") issues on various newer systems, TU116
> support.
For the m-l record, Dave&me figured this is too late (usual deadline
is -rc6), hence the nouveau
On Wed, Jul 17, 2019 at 02:15:37PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> drm_cflush_pages() is no-op on arm/arm64. But instead we can use
> dma_sync API.
>
> Fixes failures w/ vgem_test.
>
> Signed-off-by: Rob Clark
> ---
> An alternative approach to the series[1] I sent yesterday
>
On Wed, Jul 17, 2019 at 01:58:08PM +0200, Noralf Trønnes wrote:
> tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers.
> Stop lying and add a SPI connector type
>
> Cc: David Lechner
> Signed-off-by: Noralf Trønnes
Note this will break X (and probably a pile of others), whic
Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
>> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
>>> On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
>>> [SNIP]
>>> Also I looked at CI results and stuff, I guess you indeed
On Tue, Jul 16, 2019 at 05:13:10PM -0700, Rob Clark wrote:
> On Tue, Jul 16, 2019 at 4:39 PM Eric Anholt wrote:
> >
> > Rob Clark writes:
> >
> > > From: Rob Clark
> > >
> > > Since there is no real device associated with VGEM, it is impossible to
> > > end up with appropriate dev->dma_ops, mean
Hi Liviu,
On Thu, Jul 18, 2019 at 01:17:37PM +, Liviu Dudau wrote:
> On Thu, Jun 27, 2019 at 04:10:36AM +0100, Lowry Li (Arm Technology China)
> wrote:
> > Adds to print the event message when error happens and the same event
> > will not be printed until next vsync.
> >
> > Signed-off-by: L
On Tue, Jul 16, 2019 at 09:42:15AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Since there is no real device associated with vgem, it is impossible to
> end up with appropriate dev->dma_ops, meaning that we have no way to
> invalidate the shmem pages allocated by vgem. So, at least on platform
On 2019-07-19 8:07 a.m., Sam Ravnborg wrote:
> On Thu, Jul 18, 2019 at 05:37:31PM +0200, Sam Ravnborg wrote:
>> This is some janitorial updates to the via driver
>> that is required to get rid of deprecated headers
>> in the drm subsystem.
>>
>> The first three patches are trivial, where
>> the dep
On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sankaran wrote:
> On 2019-07-16 02:07, Daniel Vetter wrote:
> > On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykumar Sankaran wrote:
> > > Hello All,
> > > drm_mode_modeinfo::flags is a 32 bit field currently used to
> > > describe
On Tue, Jul 16, 2019 at 11:07:37PM -0300, Rodrigo Siqueira wrote:
> On 07/16, Daniel Vetter wrote:
> > On Thu, Jul 11, 2019 at 11:57:18PM -0300, Rodrigo Siqueira wrote:
> > > On 07/10, Daniel Vetter wrote:
> > > > On Tue, Jul 09, 2019 at 10:55:14PM -0300, Rodrigo Siqueira wrote:
> > > > > Currently
On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> > > On the exporter side we add optional explicit pinning callbacks. If those
> > > callbacks are implemented the fra
Hi Ville,
On 7/11/2019 4:02 PM, Ville Syrjala wrote:
From: Ville Syrjälä
We're going to need two cea mode tables (on for VICs < 128,
another one for VICs >= 193). To that end replace the direct
edid_cea_modes[] lookups with a function call. And we'll rename
the array to edid_cea_modes_0[] to i
Hi all,
In commit
b7019ac550eb ("drm/nouveau: fix bogus GPL-2 license header")
Fixes tag
Fixes: b24413180f5 (License cleanup: add SPDX GPL-2.0 license identifier to
files with no license)
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.ab
On Fri, Jul 19, 2019 at 9:01 AM Andrzej Hajda wrote:
>
> On 18.07.2019 15:42, Arnd Bergmann wrote:
> > Using 'imply' causes a new problem, as it allows the case of
> > CONFIG_INPUT=m with RC_CORE=y, which fails to link:
>
>
> I have reviewed dependencies and I wonder how such configuration is
> po
https://bugs.freedesktop.org/show_bug.cgi?id=111087
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
On 2019年07月19日 16:13, Lionel Landwerlin wrote:
On 18/07/2019 17:33, Chunming Zhou wrote:
在 2019/7/18 22:08, Lionel Landwerlin 写道:
On 18/07/2019 16:02, Chunming Zhou wrote:
在 2019/7/18 19:31, Lionel Landwerlin 写道:
On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in
https://bugs.freedesktop.org/show_bug.cgi?id=111087
--- Comment #16 from Ludovico de Nittis ---
Michel as you correctly guessed this wasn't an Xorg issue after all.
FTR it was caused by a Steam Runtime audio bug that has been fixed with the
latest beta release.
--
You are receiving this mail be
On 18/07/2019 17:33, Chunming Zhou wrote:
在 2019/7/18 22:08, Lionel Landwerlin 写道:
On 18/07/2019 16:02, Chunming Zhou wrote:
在 2019/7/18 19:31, Lionel Landwerlin 写道:
On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence
on syncobj,
the
https://bugs.freedesktop.org/show_bug.cgi?id=106856
--- Comment #4 from Michel Dänzer ---
(In reply to devbazilio from comment #3)
> [...] only 4.14 kernels don't have DC enabled
FWIW, you can always disable DC with amdgpu.dc=0 on the kernel command line.
--
You are receiving this mail because
On 17/07/2019 19:33, Rob Herring wrote:
> In preparation to create partial GPU mappings of BOs on page faults,
> split out the SG list handling of panfrost_mmu_map().
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob
On Fri, 2019-07-05 at 09:36 -0400, Alex Deucher wrote:
> On Thu, Jul 4, 2019 at 6:55 AM Michel Dänzer
> wrote:
> > On 2019-07-03 1:04 p.m., Timur Kristóf wrote:
> > > > > There may be other factors, yes. I can't offer a good
> > > > > explanation
> > > > > on
> > > > > what exactly is happening, b
The following changes since commit 3729fe2bc2a01f4cc1aa88be8f64af06084c87d6:
Revert "Merge branch 'vmwgfx-next' of
git://people.freedesktop.org/~thomash/linux into drm-next" (2019-07-16
04:07:13 +1000)
are available in the Git repository at:
git://github.com/skeggsb/linux linux-5.3
for you
> >
> > I took a look at amdgpu_device_get_pcie_info() and found that it
> > uses
> > pcie_bandwidth_available to determine the capabilities of the PCIe
> > port. However, pcie_bandwidth_available gives you only the current
> > bandwidth as set by the PCIe link status register, not the maximum
>
On Thu, Jul 18, 2019 at 5:55 PM Andrzej Hajda wrote:
>
> On 18.07.2019 16:21, Arnd Bergmann wrote:
> > On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
> >> Hi Arnd,
> >>
> >> On 18.07.2019 15:42, Arnd Bergmann wrote:
> >>> Using 'imply' causes a new problem, as it allows the case of
> >>> CO
On 17/07/2019 19:33, Rob Herring wrote:
> Setting the GPU VA when creating the GEM object doesn't allow for any
> conditional adjustments. In preparation to support adjusting the
> mapping, restructure the GEM object creation to map the GEM object after
> we've created the base shmem object.
>
> C
On 17/07/2019 19:33, Rob Herring wrote:
> Executable buffers have an alignment restriction that they can't cross
> 16MB boundary as the GPU program counter is 24-bits. This restriction is
> currently not handled and we just get lucky. As current userspace
Actually it depends which GPU you are usin
1 - 100 of 104 matches
Mail list logo
