On Tue, May 2, 2017 at 11:29 AM, Jose Abreu wrote:
> On 02-05-2017 09:48, Daniel Vetter wrote:
>> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
>>> Some crtc's may have restrictions in the mode they can display. In
>>> this patch a new callback (crtc->mode_valid()) is introduced that
On Tue, May 2, 2017 at 11:29 AM, Jose Abreu wrote:
> On 02-05-2017 09:48, Daniel Vetter wrote:
>> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
>>> Some crtc's may have restrictions in the mode they can display. In
>>> this patch a new callback (crtc->mode_valid()) is introduced that
This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.
v2:
- Add LINEAR and Yf modifiers to list (Ville)
- Combine i8xx and i965 into one list of formats (Ville)
- Allow 1010102 formats for Y/Yf tiled (Ville)
v
Updated blob layout (Rob, Daniel, Kristian, xerpi)
Cc: Rob Clark
Cc: Daniel Stone
Cc: Kristian H. Kristensen
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_mode_config.c | 7 +++
drivers/gpu/drm/drm_plane.c | 119 ++
include/drm/drm_mode_config
v2: A minor addition from Daniel
Cc: Daniel Stone
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 1 +
drivers/gpu/drm/arm/hdlcd_crtc.c| 1 +
drivers/gpu/drm/arm/malidp_planes.c | 2 +-
drivers/gpu/drm/armada/armada_crtc.c
On 03/05/17 12:06 AM, Gerd Hoffmann wrote:
>
>> Removing the definition also removes the possibility to describe a lot
>> of pixel formats, so that should definitely be mentioned. I think it
>> would also be good to have some kind of justified claim that no
>> hardware actually needs the pixel for
Hi Daniel,
On 02-05-2017 09:48, Daniel Vetter wrote:
> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
>> Some crtc's may have restrictions in the mode they can display. In
>> this patch a new callback (crtc->mode_valid()) is introduced that
>> is called at the same stage of connector
On Fri, 2017-04-28 at 13:32 -0500, Rob Herring wrote:
> On Tue, Apr 25, 2017 at 10:06:44AM +0800, hean.loong@intel.com
> wrote:
> >
> > From: "Ong, Hean Loong"
> >
> > Device tree binding for Intel FPGA Video and Image
> > Processing Suite. The binding involved would be generated
> > from th
2017-05-02 6:25 GMT+02:00 Martin Peres :
> On 26/04/17 19:46, Oscar Salvador wrote:
>> This patch introduces the nouveau_hwmon_ops structure, sets up
>> .is_visible and .read_string operations and adds all the functions
>> for these operations.
>> This is also a preparation for the next patches, wh
Hello there,
Source code is
max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
tc_write(DP0_MISC, (max_tu_symbol << 23) | TU_SIZE_RECOMMENDED | BPC_8);
and
#define TU_SIZE_RECOMMENDED (0x3f << 16) /* LSCLK cycles per TU */
So it looks to me like 44 bits are required. Suggest use type long ?
Hello there,
drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv04.c:124:18: warning: this
statement may fall through [-Wimplicit-fallthrough=]
Source code is
switch (dmaobj->base.access) {
case NV_MEM_ACCESS_RO:
dmaobj->flags0 |= 0x4000;
break;
case NV_MEM_ACCESS_WO:
2017-05-02 7:07 GMT+02:00 Martin Peres :
> On 26/04/17 19:46, Oscar Salvador wrote:
>> This patch replaces the symbolic permissions with the numeric ones,
>> and adds me to the authors too.
>>
>> Signed-off-by: Oscar Salvador
>
>
>> ---
>> drivers/gpu/drm/nouveau/nouveau_hwmon.c | 14 +++-
Hi Sean,
On Tue, Apr 11, 2017 at 7:30 PM, Shawn Guo wrote:
> From: Shawn Guo
>
> It adds VGA driver support, which needs to configure corresponding VOU
> interface in RGB_888 format, and thus the following changes are needed
> on zx_vou.
>
> - Rename the CSC block of Graphic Layer a bit to make
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head: 677efd69b448d24dd74e0dfb1d74fb6408c9df81
commit: 9ca8070c97b1eb2b948f065fdbccc15b6e8be639 [3/17] drm/amd/display: rename
bandwidth_calcs.c to dce_calcs.c (v2)
config: parisc-allyesconfig (attached as .config)
compiler: h
On Tue, May 2, 2017 at 6:51 PM, Christian König wrote:
> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
>> On Tue, Apr 25, 2017 at 4:19 PM, Christian König
>> wrote:
>>> +int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long
>>> type)
>>> +{
>>> + const unsigned long typ
On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> The existing drm_gem_prime_import function uses the underlying
> struct device of a drm_device for attaching to a dma_buf. Some drivers
> (notably vgem) may not have an underlying device structure. Offer
> an alternate function to atta
From: Markus Elfring
Date: Tue, 2 May 2017 21:35:48 +0200
A few single characters should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/radeon/radeon_sa.c | 9 +
From: Markus Elfring
Date: Tue, 2 May 2017 21:50:14 +0200
Two strings which did not contain data format specifications should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
dri
From: Markus Elfring
Date: Tue, 2 May 2017 21:54:49 +0200
Strings which did not contain data format specifications should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers
From: Markus Elfring
Date: Tue, 2 May 2017 22:00:02 +0200
Three update suggestions were taken into account
from static source code analysis.
Markus Elfring (3):
Use seq_putc() in radeon_sa_bo_dump_debug_info()
Use seq_puts() in radeon_debugfs_pm_info()
Use seq_puts() in r100_debugfs_cp_csq
On Sat, Apr 29, 2017 at 08:39:07PM +0800, Jeffy Chen wrote:
> Remove unused check and variables after:
> drm/rockchip: Set line flag config register in vop_crtc_enable
>
> Signed-off-by: Jeffy Chen
>
> ---
Applied to -misc-next, thanks.
Sean
>
> drivers/gpu/drm/rockchip/analogix_dp-rockchip
On Tue, May 2, 2017 at 11:06 AM, Gerd Hoffmann wrote:
> Radeon and nvidia (nv40) cards where mentioned. I'll try to summarize
> (feel free to correct me if I'm wrong).
>
> nvidia has support for 8 bit-per-color formats only on bigendian hosts.
> Not sure whenever this is a driver or hardware limi
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Cc: intel-...@lists.freedesktop.org
Reviewed-by: Chris Wilson
Signed-off-by: Laura Abbott
---
v3: Minor fixes suggested by Chris Wilson
---
dri
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Cc: intel-...@lists.freedesktop.org
Reviewed-by: Chris Wilson
Signed-off-by: Laura Abbot
Hi,
This is v3 of the series to add dma_buf import functions for vgem.
This is mostly a rebase to drm-misc/drm-misc-next with a fixup of
the resulting conflicts. More details can be found on the individual
patches.
Thanks,
Laura
Laura Abbott (3):
drm/vgem: Add a dummy platform device
drm/pri
The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using a platform device associated
with drm_device.
Cc: intel-...@
Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
On Tue, Apr 25, 2017 at 4:19 PM, Christian König
wrote:
From: Christian König
This allows device drivers to request resizing their BARs.
The function only tries to reprogram the windows of the bridge directly above
the requesting device and onl
By setting the SFTRST bit, the PRE will be held in the lowest power state
with clocks to the internal blocks gated. When external clock gating is
used (from the external clock controller, or by setting the CLKGATE bit)
the PRE will sporadically fail to start.
Signed-off-by: Lucas Stach
---
This i
Hi,
> I also think that this patch requires more comments than the
> commit message has at the moment.
>
> Removing the definition also removes the possibility to describe a lot
> of pixel formats, so that should definitely be mentioned. I think it
> would also be good to have some kind of just
Am 26.04.2017 um 18:45 schrieb Andy Shevchenko:
[SNIP]
-#define PCI_REBAR_CTRL_NBAR_MASK (7 << 5)/* mask for # bars */
-#define PCI_REBAR_CTRL_NBAR_SHIFT 5 /* shift for # bars */
+#define PCI_REBAR_CTRL_NBAR_MASK (7 << 5)/* mask for # BARs */
+#define PCI_
Hi,
On Fri, Apr 28, 2017 at 08:48:41AM -0500, Rob Herring wrote:
> On Fri, Apr 21, 2017 at 04:38:49PM +0800, Chen-Yu Tsai wrote:
> > The Allwinner display pipeline contains many hardware components, some
> > of which can consume data from one of multiple upstream components.
> > The numbering sche
Pekka Paalanen writes:
> I was under the impression that if you have a VR application running on
> the HMD, it necessarily also implies that you have a VR compositor
> running, which means that there is always some process providing a valid
> image to the HMD. (At least in end-user setups.)
Yes,
On Tue, 2 May 2017 14:53:43 +0100
Emil Velikov wrote:
> Hi Gerd,
>
> I did not have the change to follow through the discussion.
> Pardon if my suggestion have already been discussed.
>
> On 2 May 2017 at 14:34, Gerd Hoffmann wrote:
> > It's unused.
> >
> > Suggested-by: Daniel Vetter
> > Sig
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 995c8f9c69..305bc34be0 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -33,8 +33,6 @@ extern "C" {
> > #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) <<
Hi Gerd,
I did not have the change to follow through the discussion.
Pardon if my suggestion have already been discussed.
On 2 May 2017 at 14:34, Gerd Hoffmann wrote:
> It's unused.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> ---
> include/uapi/drm/drm_fourcc.h | 2 --
Add drm_mode_legacy_fb_format variant which returns fourcc codes
for framebuffer format in host byte order.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fourcc.h | 3 +++
drivers/gpu/drm/drm_fourcc.c | 54 +++-
2 files changed, 56 insertions(+), 1
Add fourcc variants in cpu byte order. With these at hand we don't
need #ifdefs in drivers want support framebuffers in cpu endianess.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fourcc.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/include/d
It's unused.
Suggested-by: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
include/uapi/drm/drm_fourcc.h | 2 --
drivers/gpu/drm/drm_fourcc.c | 3 +--
drivers/gpu/drm/drm_framebuffer.c | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b
Hi,
Ok, next round. Patches 1+2 are unmodified, driver updates are left out
for now.
Patch #3 adds a new drm_mode_legacy_fb_format_he() function instead of
changing drm_mode_legacy_fb_format behavior, so we keep things working
for now.
Comments?
Suggestions how to handle the drm_mode_legacy_
https://bugs.freedesktop.org/show_bug.cgi?id=100802
--- Comment #3 from Timo Aaltonen ---
Ran more tests and tried to bisect mesa, but the end result is something weird
that I can't figure out anymore where the bug is. Using whatever combination of
kernel, llvm, mesa, or the radeon X driver on Ub
Am Freitag, den 28.04.2017, 11:33 -0700 schrieb Ben Widawsky:
> On 17-04-28 14:11:56, Lucas Stach wrote:
> >Hi Ben,
> >
> >Am Dienstag, den 04.04.2017, 12:41 -0700 schrieb Ben Widawsky:
> >> On 17-04-04 11:07:26, Daniel Stone wrote:
> >> >Hi,
> >> >
> >> >On 1 April 2017 at 19:47, Rob Clark wrote:
Op 02-05-17 om 11:44 schreef Daniel Vetter:
> On Mon, May 01, 2017 at 03:37:54PM +0200, Maarten Lankhorst wrote:
>> Some connectors may not allow all scaling mode properties, this function
>> will allow
>> creating the scaling mode property with only the supported subset. It also
>> wires up
>> t
Hi,
On 2 May 2017 at 09:10, Daniel Vetter wrote:
> On Fri, Apr 21, 2017 at 03:41:10PM -0300, Gustavo Padovan wrote:
>> Do you know which hw would that be? I don't know. Maybe we should just
>> don't care for now and see how drivers will solve this to then extract
>> helpers like we did for atomic
On Wed, Apr 12, 2017 at 3:12 PM, Eric Anholt wrote:
> If we follow the typical pattern of the base class being the first
> member, we can use the default dma_fence_free function.
>
> Signed-off-by: Eric Anholt
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.
On Wed, Apr 12, 2017 at 3:11 PM, Eric Anholt wrote:
> Without this, polling on the dma-buf (and presumably other devices
> synchronizing against our rendering) would return immediately, even
> while the BO was busy.
>
> Signed-off-by: Eric Anholt
> Reviewed-by: Daniel Vetter
> Cc: sta...@vger.ke
On Mon, May 01, 2017 at 03:37:57PM +0200, Maarten Lankhorst wrote:
> Some atomic properties are common between the various kinds of
> connectors, for example a lot of them use panel fitting mode.
> It makes sense to put a lot of it in a common place, so each
> connector can use it while they're bei
On Mon, May 01, 2017 at 03:37:53PM +0200, Maarten Lankhorst wrote:
> This is only used in i915, which had used its own non-taomic way to
> deal with the picture aspect ratio. Move selected aspect_ratio to
> atomic state and use the atomic state in the affected i915 connectors.
>
> Signed-off-by: M
On Mon, May 01, 2017 at 03:37:54PM +0200, Maarten Lankhorst wrote:
> Some connectors may not allow all scaling mode properties, this function will
> allow
> creating the scaling mode property with only the supported subset. It also
> wires up
> this state for atomic.
>
> This will make it possib
On Tue, May 2, 2017 at 10:55 AM, Arnd Bergmann wrote:
> On Tue, May 2, 2017 at 10:41 AM, Stephen Rothwell
> wrote:
>> Hi Daniel,
>>
>> On Tue, 2 May 2017 10:25:18 +0200 Daniel Vetter wrote:
>>>
>>> Since this is an all-new driver it might be best to stagger the pull
>>> requests and merge the n
On 05/02/17 11:33, Daniel Vetter wrote:
> On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
>> Add standard properties to control YCbCr to RGB conversion in DRM
>> planes. The created properties are stored to drm_plane object to allow
>> different set of supported conversion modes for dif
On Fri, Apr 28, 2017 at 03:42:22PM -0700, Eric Anholt wrote:
> The FBDEV initialization would throw an error in dmesg, when we just
> want to silently not initialize fbdev on a V3D-only VC4 instance.
>
> Signed-off-by: Eric Anholt
With the commit message updated that passing num_connector is the
On Thu, Apr 27, 2017 at 11:35:06AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Use "non-blocking" and "blocking" instead of old names.
>
> Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> 1 file changed, 2 insert
On Wed, Apr 26, 2017 at 02:12:29PM -0700, Laura Abbott wrote:
> The existing drm_gem_prime_import function uses the underlying
> struct device of a drm_device for attaching to a dma_buf. Some drivers
> (notably vgem) may not have an underlying device structure. Offer
> an alternate function to atta
On Fri, Apr 28, 2017 at 8:05 PM, Rob Clark wrote:
> The ->preclose() hook is a good place to block for pending atomic
> updates. We can't do this in ->postclose(), as it needs to happen
> before drm_fb_release(). Otherwise, since we have already swapped
> state (in the case of a non-blocking ato
On Tue, May 2, 2017 at 10:41 AM, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Tue, 2 May 2017 10:25:18 +0200 Daniel Vetter wrote:
>>
>> Since this is an all-new driver it might be best to stagger the pull
>> requests and merge the new tee subsystem (or whatever it is) after drm?
>>
>> Not sure wha
On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
> Some crtc's may have restrictions in the mode they can display. In
> this patch a new callback (crtc->mode_valid()) is introduced that
> is called at the same stage of connector->mode_valid() callback.
>
> This shall be implemented if t
Hi Daniel,
On Tue, 2 May 2017 10:25:18 +0200 Daniel Vetter wrote:
>
> Since this is an all-new driver it might be best to stagger the pull
> requests and merge the new tee subsystem (or whatever it is) after drm?
>
> Not sure what to best do here ...
This will merge via Dave, so Dave just needs
On Fri, Apr 21, 2017 at 02:29:12PM +0100, Jose Abreu wrote:
> ++ Daniel
>
> ++ Dave
>
>
> On 21-04-2017 13:59, Jose Abreu wrote:
> > Hi All,
> >
> >
> > Is there any callback available, at the crtc level, that can
> > validate the probed modes before making them available for
> > userspace? I me
On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
> Add standard properties to control YCbCr to RGB conversion in DRM
> planes. The created properties are stored to drm_plane object to allow
> different set of supported conversion modes for different planes on
> the device. For simplicity
On Fri, Apr 21, 2017 at 02:47:44PM +0300, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Friday 21 Apr 2017 12:51:13 Jyri Sarha wrote:
> > Change drm_atomic_replace_property_blob_from_id()'s first parameter
> > from drm_crtc to drm_device, so that the function can be used
On Mon, Apr 24, 2017 at 11:25:12AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 21 Apr 2017 12:10:14 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/tee/tee_shm.c:87:2: error: u
On Thu, Apr 20, 2017 at 09:38:19PM -0300, Gabriel Krisman Bertazi wrote:
> While reading drm_for_each_connector_iter, I noticed a mention to
> drm_connector_begin which doesn't exist. It should be
> drm_connector_get.
>
> Signed-off-by: Gabriel Krisman Bertazi
Fixes: b982dab1e66d ("drm: Rename c
Op 02-05-17 om 10:12 schreef Daniel Vetter:
> On Mon, Apr 24, 2017 at 02:01:05PM +0200, Maarten Lankhorst wrote:
>> On 19-04-17 17:43, Daniel Vetter wrote:
>>> On Thu, Apr 13, 2017 at 11:15:37AM +0200, Maarten Lankhorst wrote:
This is required to for i915 to convert connector properties to ato
On Mon, Apr 24, 2017 at 10:26:45AM -0400, Alex Deucher wrote:
> On Fri, Apr 21, 2017 at 6:53 PM, Eric Anholt wrote:
> > Daniel Vetter writes:
> >
> >> On Wed, Apr 19, 2017 at 7:55 PM, Eric Anholt wrote:
> >>> Daniel Vetter writes:
> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt wrote:
> >>
On Mon, Apr 24, 2017 at 01:51:39PM +0100, Emil Velikov wrote:
> On 18 April 2017 at 23:16, Daniel Vetter wrote:
> > On Tue, Apr 18, 2017 at 8:33 PM, Kristian Høgsberg
> > wrote:
> As far as I understand the property mechanism, the numeric values
> aren't actually ABI. The string names
On Mon, Apr 24, 2017 at 02:01:05PM +0200, Maarten Lankhorst wrote:
> On 19-04-17 17:43, Daniel Vetter wrote:
> > On Thu, Apr 13, 2017 at 11:15:37AM +0200, Maarten Lankhorst wrote:
> >> This is required to for i915 to convert connector properties to atomic.
> >>
> >> Changes since v1:
> >> - Add doc
On Fri, Apr 21, 2017 at 03:41:10PM -0300, Gustavo Padovan wrote:
> 2017-04-11 Daniel Vetter :
>
> > On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote:
> > > Gustavo Padovan writes:
> > >
> > > > From: Gustavo Padovan
> > Some async cursor updates are not 100% async, as in the hw might
On Fri, 28 Apr 2017 15:03:17 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > IMHO, if nothing is providing a picture intended for the HMD, the HMD
> > should be off. There is no use in showing an arbitrary image that does
> > not look right, is there?
>
> Well, if the HMD is being
68 matches
Mail list logo
