On Thu, Mar 03, 2016 at 02:38:11AM +, Ken Moffat wrote:
> One of my machines is an A10 Kaveri desktop, with a good old VGA
> connection to the monitor. I've only just started trying to boot
> any 4.5 kernel on it, but with 4.5.0-rc6 and now linus's tree from a
> few hours ago (4.5.0-rc6-00018-
On Thu, Mar 03, 2016 at 08:17:14AM -0800, Greg Kroah-Hartman wrote:
> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Play safe and add flags member to all structs. So we don't need to
> > break API or create new IOCTL in the future if new featur
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/9072d3d0/attachment.html>
levels on the card to
try and see what causes the extra power / heat usage?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachment
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/cik.c| 2 --
drivers/gpu/drm/amd/amdgpu/vi.c | 4
3 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 0c42a85..cfd35b0 100644
--- a/driv
Hi!
First time sending a patch to the list.
This patch deletes a set-but-not-read member from the amdgpu_device
struct but I'm not sure the correct thing is to delete it. Maybe it
should be checked some where?
BR
Nils
Nils Wallménius (1):
drm/amdgpu: delete set-but-not-read member has_uvd f
-
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/56c7e3c6/attachment.sig>
Hi Tomi,
Thank you for the patch.
On Thursday 03 March 2016 16:01:16 Tomi Valkeinen wrote:
> Having -Werror in the omapdrm Makefile makes development and debugging a
> PITA. Let's remove it.
Well, shouldn't we target having no warning ? :-)
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/
This is pretty late, and since it's not regressions, I won't be at all
surprised if you want to pull this into -next instead. I could rebase
it back to -rc3 if you want it for -next.
The following changes since commit 81f70ba233d5f660e1ea5fe23260ee323af5d53a:
Linux 4.5-rc5 (2016-02-20 13:39:35
From: Gustavo Padovan
Burn the old opcode to avoid any potential old userspace running the old
API to get weird errors. Changing the opcodes will make them fail right
away.
This is just a precaution, there no upstream users of these interfaces
yet and the only user is Android, but we don't expec
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/3b333417/attachment.html>
First Kangaroo: What does a frog say when it washes car windows?
Second Kangaroo: Rub it, rub it, rub it.
https://lists.freedesktop.org/archives/dri-devel/2016-January/097945.html
https://patchwork.freedesktop.org/patch/65722
https://bugzilla.redhat.com/show_bug.cgi?id=1295646
It's been more tha
Hi Alex,
On 29 February 2016 at 21:23, Alex Deucher wrote:
> From: Christian König
>
> A fence is never later than itself. This caused a bunch of overhead for
> AMDGPU.
>
Thanks; added to for-next.
> v2: simplify check as suggested by Michel.
>
Best regards,
~Sumit.
h
more useful with this.
Acked-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/adb76513/attachment.sig>
Hi Maarten,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20160303]
[cannot apply to v4.5-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Maarten-Lankhorst
ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.
Signed-off-by: Alexey Brodkin
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-snps-arc at lists.infradead.org
This series add support of ARC PGU display controller.
ARC PGU is a quite simple byte streamer that gets data from the framebuffer
and pushes it to hte connected encoder (DP or HDMI).
It was tested on ARC SDP boards (axs101 in particular).
Changes v1 -> v2:
* Clean-up of DT bindings documentatio
On Thu, Mar 03, 2016 at 03:40:56PM +0100, Fabien DESSENNE wrote:
>
> On 03/03/2016 02:33 PM, Ville Syrjälä wrote:
> > On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote:
> >>
> >> On 03/03/2016 12:28 PM, Ville Syrjälä wrote:
> >>> On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien D
On Thu, Mar 3, 2016 at 3:54 PM, Rob Clark wrote:
> On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman
> wrote:
>> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Play safe and add flags member to all structs. So we don't need to
>>> break API o
2016-03-03 Gustavo Padovan :
> Hi Greg,
>
> 2016-03-03 Greg Kroah-Hartman :
>
> > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Play safe and add flags member to all structs. So we don't need to
> > > break API or create new IOCTL in t
From: Gustavo Padovan
Play safe and add flags member to all structs. So we don't need to
break API or create new IOCTL in the future if new features that requires
flags arises.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
v2: check if flags are valid (zero, in this case)
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to
From: Gustavo Padovan
struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
drivers/staging/android/uapi/sync.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Gustavo Padovan
We don't use the 'fence' name to refer to sync_file anymore. So rename it
to SYNC_IOC_FILE_INFO.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
drivers/staging/android/sync.c | 2 +-
drivers/staging/android/uapi/sync.h | 2 +-
2 files changed, 2 i
From: Gustavo Padovan
Inform userspace how many fences are in the sync_fence_info field.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
drivers/staging/android/sync.c | 2 ++
drivers/staging/android/uapi/sync.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/dri
Hi Dave,
Big ticket items are hdmi support for 8996 (aka snapdragon 820), and
adreno 430 support. Also one more small uapi addition to support
timestamp queries.
The following changes since commit d2eaa59000c7717e68a75cf2c106f056d2bc30b4:
Merge branch 'drm-rockchip-next-2016-02-18' of
https:/
Hi Greg,
2016-03-03 Greg Kroah-Hartman :
> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Play safe and add flags member to all structs. So we don't need to
> > break API or create new IOCTL in the future if new features that requires
> > flag
On Mon, 29 Feb 2016 15:39:53 +0100,
Jani Nikula wrote:
>
> On Mon, 29 Feb 2016, Martin Kepplinger wrote:
> > Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
> >> Sorry, Cc to Jani was missing mistakenly.
> >>
> >> Please check this. It's a regression in 4.5-rc.
> >>
> >>
> >> thanks,
> >>
> >>
omapdss driver now depends on omapdrm, so we no longer should select
OMAP2_DSS from omapdrm's Kconfig.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
index 336a
From: Laurent Pinchart
When an error occurs in omap_gem_new() the function calls
omap_gem_free_object() to clean up. However, that function expects to be
called on a fully initialized GEM object and thus crashes.
Replace it by manual cleanup.
Signed-off-by: Laurent Pinchart
Signed-off-by: Tomi
Having -Werror in the omapdrm Makefile makes development and debugging a
PITA. Let's remove it.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/Makefile b/drivers/gpu/drm/omapdrm/Makefi
Hi,
A few more patches for omapdrm for 4.6. These are based on the "drm/omap:
patches for v4.6 part 2" series sent earlier.
Tomi
Laurent Pinchart (1):
drm/omap: gem: Fix omap_gem_new() error path
Tomi Valkeinen (2):
drm/omap: remove -Werror from Makefile
drm/omap: no need to select OMAP2
Op 03-03-16 om 15:34 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer
>
> Now num_fences can be filled by the caller to inform how many fences it
> wants to retrieve from the kernel. If the num_fences passed i
On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman
wrote:
> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Play safe and add flags member to all structs. So we don't need to
>> break API or create new IOCTL in the future if new features that requi
On 1 March 2016 at 20:40, Archit Taneja wrote:
>
>
> On 3/1/2016 3:44 PM, Xinliang Liu wrote:
>>
>> Hi,
>>
>> On 1 March 2016 at 02:48, Archit Taneja wrote:
>>>
>>>
>>>
>>> On 2/26/2016 2:10 PM, Xinliang Liu wrote:
Add vblank irq handle.
v6: None.
v5: None.
v4:
Hi Matt,
On 11/02/16 02:32, Matt Roper wrote:
> Gen9 platforms allow CRTC's to be programmed with a background/canvas
> color below the programmable planes. Let's expose this as a property to
> allow userspace to program a desired value.
>
> This patch is based on earlier work by Chandra Konduru;
On 03/03/2016 02:33 PM, Ville Syrjälä wrote:
> On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote:
>>
>> On 03/03/2016 12:28 PM, Ville Syrjälä wrote:
>>> On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote:
Hi Ville,
Using DRM_MODE_PRESENT_TOP_FIELD/DRM_
On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote:
>
>
> On 03/03/2016 12:28 PM, Ville Syrjälä wrote:
> > On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote:
> >> Hi Ville,
> >>
> >> Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes
> >> that the
https://bugzilla.kernel.org/show_bug.cgi?id=107381
--- Comment #5 from Robin KERDILES ---
Created attachment 206701
--> https://bugzilla.kernel.org/attachment.cgi?id=206701&action=edit
dmesg under kernel 4.4 - archlinux x64
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=107381
Robin KERDILES changed:
What|Removed |Added
CC||xxdrshadowxx at gmail.com
--- Comment #
On Thu, Mar 03, 2016 at 03:50:23PM +, Lionel Landwerlin wrote:
> Hi Matt,
>
> On 11/02/16 02:32, Matt Roper wrote:
> >Gen9 platforms allow CRTC's to be programmed with a background/canvas
> >color below the programmable planes. Let's expose this as a property to
> >allow userspace to program
On 03/03/2016 12:28 PM, Ville Syrjälä wrote:
> On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote:
>> Hi Ville,
>>
>> Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes
>> that the userland controls the field presentation on the display output.
>> This assumes t
Hi Dave, a couple of Intel fixes for v4.5.
BR,
Jani.
The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af:
Linux 4.5-rc6 (2016-02-28 08:41:20 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-03-03
for
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/a17cb4ad/attachment.html>
On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote:
> Hi Ville,
>
> Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes
> that the userland controls the field presentation on the display output.
> This assumes that the userland is aware of the field actually on dis
ttachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/6f374dcd/attachment.html>
The DRM core depends on mm->mmap_sem being the outer lock in order to
setup/teardown and utilize fault handlers. If we taint the mm->mmap_sem
as soon as we open the device for a process, we can define this proper
ordering for lockdep and so it will report any violations early.
Signed-off-by: Chris
Both are maintained by same team.
Signed-off-by: Alex Deucher
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c647c40..20166fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3712,7 +3712,7 @@ F:drivers/gpu/vga/
F:
From: Gustavo Padovan
Play safe and add flags member to all structs. So we don't need to
break API or create new IOCTL in the future if new features that requires
flags arises.
v2: check if flags are valid (zero, in this case)
v3: return -EINVAL if flags are not zero'ed
v4: add padding for 64-
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to
Use the upper_32_bits() macro instead of the four line equivalent that
triggers a GCC warning on 32 bits x86:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function
'vmw_cmdbuf_header_submit':
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:297:25: warning: right shift count
>= width of type [-Wshift
Hi Ville,
Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes
that the userland controls the field presentation on the display output.
This assumes that the userland is aware of the field actually on display
and I think that this information is not provided by the DRM framewor
The value of pdev->rom_attr is the definitive indicator of the fact that
we're created a sysfs attribute. Check that rather than rom_size, which is
only used incidentally when deciding whether to create a sysfs attribute.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-sysfs.c | 13 +++--
The IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY bits are unused.
Remove them and code that depends on them.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/remove.c |1 -
drivers/pci/rom.c | 31 +--
include/linux/ioport.h |2 --
3 files changed, 1 i
Loongson 3 used the IORESOURCE_ROM_COPY flag for its ROM resource. There
are two problems with this:
- When IORESOURCE_ROM_COPY is set, pci_map_rom() assumes the resource
contains virtual addresses, so it doesn't ioremap the resource. This
implies loongson_sysconf.vgabios_addr is a vir
Use a temporary struct resource pointer to avoid needless repetition of
"pdev->resource[PCI_ROM_RESOURCE]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/mips/pci/fixup-loongson3.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/m
A struct resource contains CPU physical addresses, not virtual addresses.
But sn_acpi_slot_fixup() and sn_io_slot_fixup() stored the virtual address
of a shadow ROM copy in the resource. To compensate, pci_map_rom() had a
special case that returned the resource address directly rather than
calling
Depositing __IA64_UNCACHED_OFFSET in the upper address bits is essentially
equivalent to ioremap(): it converts a CPU physical address to a virtual
address using the ia64 uncacheable identity map.
Call ioremap() instead of doing the phys-to-virt conversion manually with
__IA64_UNCACHED_OFFSET.
No
Use a temporary struct resource pointer to avoid needless repetition of
"dev->resource[idx]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/sn/kernel/io_acpi_init.c | 10 +
arch/ia64/sn/kernel/io_init.c | 39
2 fi
Remove unnecessary indentation in pci_map_rom(). This is logically part of
the previous patch; I split it out to make the critical changes in that
patch more obvious. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 37 ++---
IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in
RAM. The existence of such a copy and its location are arch-specific.
Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the
0xC-0xD location was hard-coded into the PCI core.
If we're using a shadow
If we're using a RAM shadow copy instead of the ROM BAR, we don't need to
touch the ROM BAR enable bit.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 9eaca39..
IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set,
don't bother trying to assign or reassign the resource.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/setup-res.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
A shadow copy of an option ROM is placed by the BIOS as a fixed address.
Set IORESOURCE_PCI_FIXED to indicate that we can't move the shadow copy.
This prevents warnings like the following when we assign resources:
BAR 6: [??? 0x flags 0x2] has bogus alignment
This warning is emitted by
The purpose of this series is to:
- Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
messages reported by Linus [1], Andy [2], and others.
- Move arch-specific shadow ROM location knowledge, e.g.,
0xC-0xD, from PCI core to arch code.
- Fix the ia64 and MIPS L
Hello Dave,
Here are sti patches for drm-next.
It brings:
- The support of the atomic_check for the planes and minor fixes for
planes
- The support of the vendor specific infoframe for HDMI and the
support of 2 HDMI properties related to the connector
- The support of the DVO solving panel
Op 02-03-16 om 20:52 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer
>
> Now num_fences can be filled by the caller to inform how many fences it
> wants to retrieve from the kernel. If the num_fences passed i
Hi,
> > Did testing a while back & reported back to John (not sure this was in
> > public on the list as we had some ping-ping emails beforehand due to
> > some problems of applying the patches). No new version of the series
> > since.
> >
> The only comment that I can see is this one [1] which
connector_state->crtc can no longer be unset by accident,
so that check can be removed. The other code open-codes
drm_atomic_get_existing_crtc_state, so use that.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 17 -
1 file changed, 4 insertions(+), 13
Now that only encoders can be stolen that are part of the state
steal_encoder no longer needs to inspect all connectors,
just those that are part of the atomic state.
Changes since v1:
- Change return value to void, can no longer fail.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_at
The current check doesn't handle the case where we don't steal an
encoder, but keep it on the current connector. If we repurpose
disable_conflicting_encoders to do the checking, we just have
to reject the ones that conflict.
Changes since v1:
- Return early with empty encoder_mask, drm_for_each_co
Instead of failing with -EINVAL when conflicting encoders are found,
the legacy set_config will disable other connectors when encoders
conflict.
With the previous commit this becomes a lot easier to implement.
set_config only adds connectors to the state that are modified,
and because of the previ
There's no need to have a separate function to get the crtc
which is stolen, this can already be found when actually
stealing the encoder.
drm_for_each_connector already checks for connection_mutex, so
use that macro now.
Changes since v1:
- Do not check for NULL crtc in connector_state,
this m
Minor cleanup, connector and connector_state are always non-NULL here.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
With the addition of crtc_state->connector_mask other connectors from
different crtc's aren't needed any more, so only call
add_affected_connectors on the target crtc. This allows a cleanup
to first remove all current connectors, then add all set->connectors
to the target crtc.
Signed-off-by: Maar
This is a resend of "drm/atomic: Fix encoder stealing" with updated patches.
Maarten Lankhorst (7):
drm/atomic: Clean up update_output_state.
drm/atomic: Pass connector and state to update_connector_routing.
drm/atomic: Always call steal_encoder, v2.
drm/atomic: Handle encoder stealing fro
On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote:
> The purpose of this series is to:
> [ .. ]
The patches look ok to me and seem to make sense.
Of course, let's see what they break. Hopefully nothing, but any time
the PCI resource code changes I get a bit worried. PTSD, I guess.
Hi,
On 3 March 2016 at 02:29, Rob Herring wrote:
> On Fri, Feb 26, 2016 at 04:40:18PM +0800, Xinliang Liu wrote:
>> Add ADE display controller binding doc.
>> Add DesignWare DSI Host Controller v1.20a binding doc.
>>
>> v6:
>> - Cleanup values part of reg and clocks properties.
>> - Change "pclk_
On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Play safe and add flags member to all structs. So we don't need to
> break API or create new IOCTL in the future if new features that requires
> flags arises.
>
> v2: check if flags are valid (zero, in t
Hi Dave,
Some more radeon and amdgpu stuff for drm-next. Mostly just bug fixes
for new features and cleanups.
The following changes since commit d2eaa59000c7717e68a75cf2c106f056d2bc30b4:
Merge branch 'drm-rockchip-next-2016-02-18' of
https://github.com/markyzq/kernel-drm-rockchip into drm-n
80 matches
Mail list logo
