I've sent two udl fixes for plugging in, these two fix the unplug scenario,
The first avoids hitting the unregister path twice, once in device unplug
and once in last open fd release.
The second avoids uninit the modeset configs while userspace still has
the open fd which can access them.
Dave.
From: Dave Airlie
When we release the file handle on a device that has been unplugged
it has already called the unregister path, which doesn't like being
called again. We should just do the dev put version instead.
This fixes some crashes unplugged in a udl device.
Signed-off-by: Dave Airlie
From: Dave Airlie
If we unplug a udl device, the usb callback with deinit the
mode_config struct, however userspace will still have an open
file descriptor and a framebuffer on that device. When userspace
closes the fd, we'll oops because it'll try and look stuff up
in the object idr which we've
Hey,
Not sure how long this has been broken, considering plugging it in was
broken, unplugging is much worse. Is there anything outside my tree
that might be fixing this?
Currently it appears if I unplug udl while userspace has the device
open, it's bad, I get the userspace fb leaked thing which
On Fri, Mar 15, 2019 at 10:34 AM Yongqiang Niu
wrote:
>
> On Tue, 2018-12-25 at 12:15 +0800, Nicolas Boichat wrote:
> > On Mon, Dec 24, 2018 at 6:53 PM Yongqiang Niu
> > wrote:
> > >
> > > This patch add gmc_bits for ovl private data
> > >
> > > Signed-off-by: Yongqiang Niu
> > > ---
> > >
On Fri, Mar 15, 2019 at 10:06 AM Yongqiang Niu
wrote:
>
> On Tue, 2018-12-25 at 11:57 +0800, Nicolas Boichat wrote:
> > On Mon, Dec 24, 2018 at 6:52 PM Yongqiang Niu
> > wrote:
> > >
> > > This patch redefine mtk_ddp_sout_sel
> >
> > Can you describe a bit more why you are making this change?
>
https://bugs.freedesktop.org/show_bug.cgi?id=110117
Craig changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
https://bugs.freedesktop.org/show_bug.cgi?id=110117
Bug ID: 110117
Summary: Waking from Suspend causes screen to appear with grey
static (like a TV with no signal)
Product: DRI
Version: XOrg git
Hardware: Other
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Unlike what the binding for multiple pipeline documents, the A64 doesn't
> have the cross links between the TCON and the mixers.
>
> Let's add them.
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Unlike what the binding for multiple pipeline documents, the A83t doesn't
> have the cross links between the TCON and the mixers.
>
> Let's add them.
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Using the new helpers introduced since we wrote that code, we can simplify
> the code to retrieve the mixer ID significantly.
>
> The new code will also allow us to deal nicely with endpoints that don't
> have a reg property, as expected in
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Using the new helpers introduced since we wrote that code, we can simplify
> the code to retrieve the backend ID significantly.
>
> The new code will also allow us to deal nicely with endpoints that don't
> have a reg property, as expected
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> The soc node in the A80 DTSI has a ranges property, but no matching unit
> address, which results in a DTC warning. Add the unit address to remove
> that warning.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun9i-a80.dtsi |
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Our display engine endpoints trigger some DTC warnings due to the fact that
> we're having a single endpoint that doesn't need any reg property, and
> since we don't have a reg property, we don't need the address-cells and
> size-cells
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Our display engine endpoints trigger some DTC warnings due to the fact that
> we're having a single endpoint that doesn't need any reg property, and
> since we don't have a reg property, we don't need the address-cells and
> size-cells
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Our display engine endpoints trigger some DTC warnings due to the fact that
> we're having a single endpoint that doesn't need any reg property, and
> since we don't have a reg property, we don't need the address-cells and
> size-cells
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Our display engine endpoints trigger some DTC warnings due to the fact that
> we're having a single endpoint that doesn't need any reg property, and
> since we don't have a reg property, we don't need the address-cells and
> size-cells
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Our display engine endpoints trigger some DTC warnings due to the fact that
> we're having a single endpoint that doesn't need any reg property, and
> since we don't have a reg property, we don't need the address-cells and
> size-cells
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Our display engine endpoints trigger some DTC warnings due to the fact that
> we're having a single endpoint that doesn't need any reg property, and
> since we don't have a reg property, we don't need the address-cells and
> size-cells
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Since most of the display IPs have a single endpoint, having a reg
> property, a unit-address and #address-cells and #size-cells will emit a
> warning.
>
> Let's remove those.
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Our display engine endpoints trigger some DTC warnings due to the fact that
> we're having a single endpoint that doesn't need any reg property, and
> since we don't have a reg property, we don't need the address-cells and
> size-cells
On Thu, 14 Mar 2019 at 18:25, Robert Tarasov wrote:
>
> Now drm/udl driver uses drm_do_get_edid() function to retreive and
> validate all blocks of EDID data. Old approach had insufficient
> validation routine and had problems with retreiving of extra blocks
>
> Signed-off-by: Robert Tarasov
On Sat, 9 Mar 2019 at 19:39, Robert Tarasov wrote:
>
> Filter out all modes with clock higher than 165 MHz for DVI connector in
> drm/udl driver.
>
> Signed-off-by: Robert Tarasov
> ---
> drivers/gpu/drm/udl/udl_connector.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git
From: Dave Airlie
If the downscaling fails and we end up with a best_depth of 0,
then ignore it.
This actually works around a cascade of failure, but it the
simplest fix for now.
The scaling patch broke the udl driver, as the udl driver doesn't
expose planes at all, so gets the two default
From: Dave Airlie
When Daniel removed struct_mutex he didn't fix this call to the unlocked
variant which is required since we no longer use struct mutex.
This fixes a bunch of:
WARNING: CPU: 4 PID: 1370 at drivers/gpu/drm/drm_gem.c:931
drm_gem_object_put+0x2b/0x30 [drm]
Modules linked in: udl
Hi Linus,
A few various fixes pulls and one late -next pull but it was nearly
all fixes anyways.
etnaviv:
- late next pull
- mmu mapping fix
- build non-ARM arches
- misc fixes
i915:
- HDCP state handling fix
- shrinker interaction fix
- atomic state leak fix
qxl:
- kick out framebuffers early
Rob Herring writes:
> On Thu, Mar 14, 2019 at 3:45 PM Dave Airlie wrote:
>>
>> On Thu, 14 Feb 2019 at 19:12, Christian König via dri-devel
>> wrote:
>> >
>> > Am 14.02.19 um 03:52 schrieb Alex Deucher via dri-devel:
>> > > [SNIP]
>> > > +static int lima_ioctl_gem_va(struct drm_device *dev,
The CRTC suspend and resume functions have been replaced, but the
prototypes were not removed.
Remove the redundant definitions.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
The rcar_du_crtc_mode_valid() and rcar_du_crtc_get_crc_sources()
functions are accessed only through a function pointer table.
Convert the function definitions to be static to the module.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 9 +
1 file changed, 5
The drm_crtc_state documentation contains a subtle misspelling of the
word subtle. Correct it.
Signed-off-by: Kieran Bingham
---
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index
Three fairly trivial cleanup patches from while I've been working on the CRTC
code on rcar-du.
The first is a small spelling error in the drm_crtc_state documentation, and
the following two are more directly cleaning up the rcar-du.
Kieran Bingham (3):
drm: fix subtle spelling error in
On Thu, Mar 14, 2019 at 3:45 PM Dave Airlie wrote:
>
> On Thu, 14 Feb 2019 at 19:12, Christian König via dri-devel
> wrote:
> >
> > Am 14.02.19 um 03:52 schrieb Alex Deucher via dri-devel:
> > > [SNIP]
> > > +static int lima_ioctl_gem_va(struct drm_device *dev, void *data,
> > > struct
To all X.Org Foundation Members:
In order to give members more time to process the proposed changes to the bylaw
the elections committee decided to delay the start of voting by one week.
Updated Schedule:
Nomination period Start: Jan 31 00:00 UTC
Nomination period End: Feb 28 23:59 UTC
To all X.Org Foundation Members:
My previous emails about the 2019 X.Org elections failed to mention on
important ballot items that we'd like to vote on, in addition to the new board
members: the Bylaw change
The updated Bylaws to be voted on can be found here:
On 2019-03-14 4:40 p.m., Luc Verhaegen wrote:
> On Thu, Mar 14, 2019 at 08:36:13PM +, Wentland, Harry wrote:
>> On 2019-03-12 6:49 a.m., Luc Verhaegen wrote:
>>>
>>> Are these candidates the only thing we will be voting on?
>>>
>>
>> You're right. The FDO question totally slipped me mind.
>>
On Thu, 14 Feb 2019 at 19:12, Christian König via dri-devel
wrote:
>
> Am 14.02.19 um 03:52 schrieb Alex Deucher via dri-devel:
> > [SNIP]
> > +static int lima_ioctl_gem_va(struct drm_device *dev, void *data,
> > struct drm_file *file)
> > +{
> > + struct drm_lima_gem_va
On Thu, Mar 14, 2019 at 08:36:13PM +, Wentland, Harry wrote:
> On 2019-03-12 6:49 a.m., Luc Verhaegen wrote:
> >
> > Are these candidates the only thing we will be voting on?
> >
>
> You're right. The FDO question totally slipped me mind.
>
> We'll also be voting on the bylaw change I sent
On 2019-03-12 6:49 a.m., Luc Verhaegen wrote:
> On Tue, Mar 12, 2019 at 12:24:00AM +, Wentland, Harry wrote:
>> To all X.Org Foundation Members:
>>
>> The election for the X.Org Foundation Board of Directors will begin on
>> 14 March 2019. We have 6 candidates who are running for 4 seats.
The MBUS controller drives the MBUS that other devices in the SoC will
use to perform DMA. It also has a register interface that allows to
monitor and control the bandwidth and priorities for masters on that
bus.
Signed-off-by: Maxime Ripard
---
The current DT bindings assume that the DMA will be performed by the
devices through their parent DT node, and rely on that assumption for the
address translation using dma-ranges.
However, some SoCs have devices that will perform DMA through another bus,
with separate address translation rules.
Hi,
We've had for quite some time to hack around in our drivers to take into
account the fact that our DMA accesses are not done through the parent
node, but through another bus with a different mapping than the CPU for the
RAM (0 instead of 0x4000 for most SoCs).
After some discussion after
Now that we can express our DMA topology, rely on those property instead of
hardcoding an offset from the dma_addr_t which wasn't really great.
We still need to add some code to deal with the old DT that would lack that
property, but we move the offset to the DRM device dma_pfn_offset to be
able
Some SoCs have devices that are using a separate bus from the main bus to
perform DMA.
These buses might have some restrictions and/or different mapping than from
the CPU side, so we'd need to express those using the usual dma-ranges, but
using a different DT node than the node's parent.
Now
The MBUS clock is used by the MBUS controller, so let's export it so that
we can use it in our DT node.
Reviewed-by: Rob Herring
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/ccu-sun5i.h | 4
include/dt-bindings/clock/sun5i-ccu.h | 2 +-
2 files changed, 1 insertion(+), 5
The MBUS (and its associated controller) is the bus in the Allwinner SoCs
that DMA devices use in the system to access the memory.
Among other things (and depending on the SoC generation), it can also
enforce priorities or report bandwidth usages on a per-master basis.
One of the most notable
The __of_translate_address function is used to translate the device tree
addresses to physical addresses using the various ranges property to create
the offset.
However, it's shared between the CPU addresses (based on the ranges
property) and the DMA addresses (based on dma-ranges). Since we're
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
Using the new helpers introduced since we wrote that code, we can simplify
the code to retrieve the mixer ID significantly.
The new code will also allow us to deal nicely with endpoints that don't
have a reg property, as expected in the case where there's a single
endpoint for a given port.
The soc node in the A80 DTSI has a ranges property, but no matching unit
address, which results in a DTC warning. Add the unit address to remove
that warning.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
Unlike what the binding for multiple pipeline documents, the A64 doesn't
have the cross links between the TCON and the mixers.
Let's add them.
Signed-off-by: Maxime Ripard
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 33 ++--
1 file changed, 30 insertions(+), 3
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
Here is the rest of the series that fixes most of our DTC warnings. The
number of warnings when compiled with W=1 after applying this series is now
reduced to 2.
The two remaining one are on the A80 and would require some change in
the clock driver. Given how little activity there is on the A80,
Using the new helpers introduced since we wrote that code, we can simplify
the code to retrieve the backend ID significantly.
The new code will also allow us to deal nicely with endpoints that don't
have a reg property, as expected in the case where there's a single
endpoint for a given port.
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
Unlike what the binding for multiple pipeline documents, the A83t doesn't
have the cross links between the TCON and the mixers.
Let's add them.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 30 --
1 file changed, 28 insertions(+), 2
Since most of the display IPs have a single endpoint, having a reg
property, a unit-address and #address-cells and #size-cells will emit a
warning.
Let's remove those.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i.dtsi | 25 +
1 file changed, 5 insertions(+),
On Thu, Mar 14, 2019 at 3:07 PM Neil Armstrong wrote:
>
> Hi Rob,
>
> Le 14/03/2019 19:55, Rob Herring a écrit :
> > On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong
> > wrote:
> >>
> >> On 08/03/2019 15:54, Rob Herring wrote:
> >>> On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong
> >>> wrote:
>
Hi Rob,
Le 14/03/2019 19:55, Rob Herring a écrit :
> On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong
> wrote:
>>
>> On 08/03/2019 15:54, Rob Herring wrote:
>>> On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong
>>> wrote:
Hi Rob,
On 08/03/2019 00:13, Rob Herring wrote:
> On
Rob Herring writes:
> On Thu, Mar 14, 2019 at 11:34 AM Eric Anholt wrote:
>>
>> The new shmem helpers from Noralf and Rob abstract out a bunch of our
>> BO creation and mapping code.
>>
>> v2: Use the new sgt getter, and flag pages as dirty before freeing.
>>
>> Signed-off-by: Eric Anholt
>>
Rob Herring writes:
> On Wed, Mar 13, 2019 at 3:56 PM Eric Anholt wrote:
>>
>> Rob Herring writes:
>>
>> > From: Noralf Trønnes
>> >
>> > This adds a library for shmem backed GEM objects.
>>
>> I read through the whole thing, and the only bit I didn't like
>> (drm_gem_shmem_create_with_handle
On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong wrote:
>
> On 08/03/2019 15:54, Rob Herring wrote:
> > On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong
> > wrote:
> >>
> >> Hi Rob,
> >>
> >> On 08/03/2019 00:13, Rob Herring wrote:
> >>> On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong
> >>> wrote:
>
Allow atomic_enable and atomic_disable operations from
drm_crtc_helper_funcs struct optional. With this, the target display
drivers don't need to define a dummy function if they don't need one.
Changes since v2:
* Don't make funcs optional
* Update kerneldoc for atomic_enable/disable
* Replace
Pushed to drm-misc, thanks for the patch and the review!
Regards
Manasi
On Wed, Mar 13, 2019 at 02:48:36PM -0400, Alex Deucher wrote:
> On Tue, Mar 12, 2019 at 10:15 PM Manasi Navare
> wrote:
> >
> > Current driver sets the tile property only for DP MST connectors.
> > However there are some
Hi Benoit,
Thank you for the patch.
On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> During a suspend cycle the atomic state is saved to be used during the
> restore cycle.
>
> However the current state duplication logic does not duplicate private
> objects. This leads to state
On Thu, Mar 14, 2019 at 11:34 AM Eric Anholt wrote:
>
> The new shmem helpers from Noralf and Rob abstract out a bunch of our
> BO creation and mapping code.
>
> v2: Use the new sgt getter, and flag pages as dirty before freeing.
>
> Signed-off-by: Eric Anholt
> ---
>
Hi,
On Mon, Mar 04, 2019 at 07:05:52PM +0100, Sam Ravnborg wrote:
> Hi Thierry.
>
> > Changes from v2
> > * As per review comments from Sam Ravnborg
> > * Lowercase sentinel
> > * Drop '_panel' postfix
> > * DRM_DEV_ logging instead of plain DRM_
> > * Add Sam's Reviewed-by:
> > * Add
On Thu, Mar 14, 2019 at 8:42 AM Maxime Ripard wrote:
>
> Hi Vasily,
>
> On Wed, Mar 13, 2019 at 07:58:38PM -0700, Vasily Khoruzhick wrote:
> > Add support for gamma corretion to sun4i TCON driver. Its LUT has 256
> > entries and can be updated only when gamma correction is disabled.
> >
> >
On 3/14/19 6:15 AM, Michel Dänzer wrote:
> On 2019-03-13 7:08 p.m., Helen Koike wrote:
>> On 3/13/19 6:58 AM, Michel Dänzer wrote:
>>> On 2019-03-13 4:42 a.m., Tomasz Figa wrote:
On Wed, Mar 13, 2019 at 12:52 AM Boris Brezillon
wrote:
> On Tue, 12 Mar 2019 12:34:45 -0300
>
Hello Chenbo,Thank you for your RFC series.
On Wed, 27 Feb 2019 at 09:24, Chenbo Feng wrote:
>
> Currently, all dma-bufs share the same anonymous inode. While we can count
> how many dma-buf fds or mappings a process has, we can't get the size of
> the backing buffers or tell if two entries
On 14/03/2019 13:05, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This series are based on 4.20-rc1 and provide 18 patches to
> support mediatek SOC MT8183
> Resend first version
>
I think you send the very same series several times yesterday. Please check your
config and
On Wed, Mar 13, 2019 at 3:56 PM Eric Anholt wrote:
>
> Rob Herring writes:
>
> > From: Noralf Trønnes
> >
> > This adds a library for shmem backed GEM objects.
>
> I read through the whole thing, and the only bit I didn't like
> (drm_gem_shmem_create_with_handle returns an unrefcounted object
>
Eric Anholt writes:
> The new shmem helpers from Noralf and Rob abstract out a bunch of our
> BO creation and mapping code.
>
> v2: Use the new sgt getter, and flag pages as dirty before freeing.
>
> Signed-off-by: Eric Anholt
> @@ -185,83 +33,120 @@ void v3d_free_object(struct drm_gem_object
Hello Jyri,
STM32MP157C-DK2 discovery boards use a SiI9022A HDMI transmitter.
see: https://www.st.com/en/evaluation-tools/stm32mp157c-dk2.html
On this board audio samples are sent to HDMI transmitter through the i2s
link. This i2s link does not provide a master clock. internal PLL is
used
The new shmem helpers from Noralf and Rob abstract out a bunch of our
BO creation and mapping code.
v2: Use the new sgt getter, and flag pages as dirty before freeing.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/Kconfig | 1 +
drivers/gpu/drm/v3d/v3d_bo.c | 317
Rob Herring writes:
> On Tue, Mar 12, 2019 at 12:37 PM Eric Anholt wrote:
>>
>> Rob Herring writes:
>>
>> > On Fri, Mar 8, 2019 at 10:17 AM Eric Anholt wrote:
>> >>
>> >> Now that we have the reservation object in the GEM object, it's easy
>> >> to provide a helper for this common case.
Signed-off-by: David Howells
cc: David Airlie
cc: Daniel Vetter
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index
Hi Al,
Here's a set of patches that:
(1) Provides a convenience member in struct fs_context that is OR'd into
sb->s_iflags by sget_fc().
(2) Provides a convenience vfs_init_pseudo_fs_context() helper function
for doing most of the work in mounting a pseudo filesystem.
(3)
On 03/11, Liviu Dudau wrote:
> On Sun, Mar 10, 2019 at 06:20:34PM -0300, Rodrigo Siqueira wrote:
> > Hi,
>
> Hi Rodrigo,
>
> >
> > In the last few weeks, I was focused on implementing the writeback on
> > VKMS by using the feedback that I got from Brian Starkey and Daniel
> > Vetter in my
Ville Syrjälä wrote on Thu [2019-Mar-14
17:31:29 +0200]:
> On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> > During a suspend cycle the atomic state is saved to be used during the
> > restore cycle.
> >
> > However the current state duplication logic does not duplicate private
Hi Vasily,
On Wed, Mar 13, 2019 at 07:58:38PM -0700, Vasily Khoruzhick wrote:
> Add support for gamma corretion to sun4i TCON driver. Its LUT has 256
> entries and can be updated only when gamma correction is disabled.
>
> Signed-off-by: Vasily Khoruzhick
It's not really clear to me what you
On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
> Maxime Ripard writes:
>
> > Hi!
> >
> > On Mon, Mar 11, 2019 at 01:47:13PM +, Mans Rullgard wrote:
> >> Sometimes it is desirabled to use a separate i2c controller for ddc
> >> access. This adds support for the ddc-i2c-bus
On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> During a suspend cycle the atomic state is saved to be used during the
> restore cycle.
>
> However the current state duplication logic does not duplicate private
> objects. This leads to state inconsistencies at resume time.
>
>
On 03/13, Mamta Shukla wrote:
> On Sun, Mar 10, 2019 at 9:00 PM Rodrigo Siqueira
> wrote:
> >
> > Hi,
> >
> > Thanks for your patch.
> >
> > You can see my comments inline.
> >
> > On 03/09, Mamta Shukla wrote:
> > > Add overlay plane support in vkms aligned with cursor and primary
> > > plane
During a suspend cycle the atomic state is saved to be used during the
restore cycle.
However the current state duplication logic does not duplicate private
objects. This leads to state inconsistencies at resume time.
With private objects modeset lock now integrated, we can make sure that
https://bugzilla.kernel.org/show_bug.cgi?id=202799
--- Comment #6 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
It might be useful to have a dmesg log from after the problem occurred with
drm.debug=4 set in your kernel boot parameters.
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=110113
Bug ID: 110113
Summary: AMD Vega64 issue setting custom voltages
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Thu, Mar 14, 2019 at 4:01 AM Neil Armstrong wrote:
>
> On 08/03/2019 01:24, Rob Herring wrote:
> > From: "Marty E. Plummer"
> >
> > This adds the initial driver for panfrost which supports Arm Mali
> > Midgard and Bifrost family of GPUs. Currently, only the T860 Midgard GPU
> > has been
On 3/14/19 5:50 AM, Daniel Vetter wrote:
> On Wed, Mar 13, 2019 at 05:41:52PM +, Kazlauskas, Nicholas wrote:
>> On 3/13/19 1:33 PM, Michel Dänzer wrote:
>>> On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote:
On 3/13/19 11:54 AM, Christian König wrote:
> Am 13.03.19 um 16:38 schrieb
Hi Kieran,
On Thu, Mar 14, 2019 at 08:28:27AM +, Kieran Bingham wrote:
> On 13/03/2019 15:56, Laurent Pinchart wrote:
> > On Wed, Mar 13, 2019 at 11:42:34AM +, Kieran Bingham wrote:
> >> On 13/03/2019 00:05, Laurent Pinchart wrote:
> >>> Extend the vsp1_du_atomic_flush() API with
Simply add all pci memory bars to struct apertures_struct in
remove_conflicting_pci_framebuffers(), without depending on the
res_id parameter.
The plan is to drop the res_id parameter later on. For now keep the
parameter, use it for sanity-checking and warn on inconsistencies.
Signed-off-by:
On Thu, Mar 14, 2019 at 11:37:13AM +0100, Daniel Vetter wrote:
> On Wed, Mar 13, 2019 at 12:07:41PM +0100, Gerd Hoffmann wrote:
> > Simply add all pci memory bars to struct apertures_struct in
> > remove_conflicting_pci_framebuffers(). That allows to drop
> > the res_id parameter.
> >
> > TODO:
Remove trailing white space from sii902x display bridge binding.
Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The pixel clock unit in the first two registers (0x00 and 0x01) of
sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
10 fixes the issue.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/sii902x.c | 5 +++--
1
Set output mode to HDMI or DVI according to EDID HDMI signature.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/sii902x.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c
The sii902x chip family supports also HDMI audio. Add binding for
describing the necessary i2s and mclk wiring for it.
Signed-off-by: Jyri Sarha
---
.../bindings/display/bridge/sii902x.txt | 33 +++
1 file changed, 33 insertions(+)
diff --git
From: Tomi Valkeinen
The driver always sets InputBusFmt:EDGE to 0 (falling edge).
Add drm_bridge_timings's input_bus_flags to reflect that the bridge
samples on falling edges.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
1 - 100 of 276 matches
Mail list logo
