On Tue, Nov 4, 2014 at 11:30 PM, Sean Paul wrote:
>> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
>> index 89829ae58e97..ea0ef43b19e1 100644
>> --- a/Documentation/DocBook/drm.tmpl
>> +++ b/Documentation/DocBook/drm.tmpl
>> @@ -996,6 +996,10 @@ int max_width, max_he
From: Dave Airlie
This stuff is ancient, we have docs now in the kernel,
lets just drop it.
Pointed out by Glenn
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/README.drm | 43 ---
1 file changed, 43 deletions(-)
delete mode 100644 drivers/gpu/drm/READ
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #70 from prettyvanilla at posteo.at ---
I just had my Sapphire HD 6870 (Dirt3 Edition) successfully reset itself after
a lockup for the first time (as opposed to the usual black or funnily patterned
screen), so I can post my dmesg. Gami
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #71 from prettyvanilla at posteo.at ---
Created attachment 156571
--> https://bugzilla.kernel.org/attachment.cgi?id=156571&action=edit
dmesg after (uvd related) gpu lockup and successful reset
--
You are receiving this mail because:
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #72 from prettyvanilla at posteo.at ---
Created attachment 156581
--> https://bugzilla.kernel.org/attachment.cgi?id=156581&action=edit
vbios of the sapphire radeon hd 6870 dirt3 edition
--
You are receiving this mail because:
You ar
On November 5, 2014 2:03:16 AM Dave Airlie wrote:
> From: Dave Airlie
>
> This stuff is ancient, we have docs now in the kernel,
> lets just drop it.
>
> Pointed out by Glenn
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/README.drm | 43 ---
> 1
On 2014å¹´11æ04æ¥ 22:29, Russell King - ARM Linux wrote:
> On Tue, Nov 04, 2014 at 09:33:10PM +0800, Andy Yan wrote:
>> From: Andy yan
>>
>> We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
>> use the interface compatible Designware HDMI IP, but they also have some
I filed this with bugzilla @ kernel.org (87741) Not sure if I need to send here.
Long running stable systems exhibit the following with all mods
removed, as distributed. (I use my own scheduler and file system - the
kernels below use the stock ext4 file system):
Kernel Command line: BOOT_IMAGE=/b
Hi ZubairLK:
On 2014å¹´11æ04æ¥ 21:50, Zubair Lutfullah Kakakhel wrote:
> Hi,
>
> On 04/11/14 13:39, Andy Yan wrote:
>> From: Andy yan
>>
>> the original imx hdmi driver is under staging/imx-drm,
>> which depends on imx-drm, so move the imx hdmi drvier out
>> to drm/bridge and rename imx-hdmi to
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141105/afc83609/attachment.html>
On Wed, 05 Nov 2014, Jim McDevitt wrote:
> I filed this with bugzilla @ kernel.org (87741) Not sure if I need to
> send here.
Thanks for the report; for drm/i915 we do track the bugs at kernel.org
and freedesktop.org bugzillas, so let's have the follow-ups in
https://bugzilla.kernel.org/show_bug.
esktop.org/archives/dri-devel/attachments/20141105/a80ce9b8/attachment.html>
le count for the record owner and the registry owner.
Can you elaborate what you think is confusing? Perhaps I can add more
kerneldoc to clarify.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/00a5f89f/attachment.sig>
On Tue, Nov 04, 2014 at 09:39:58PM +0800, Andy Yan wrote:
> From: Andy yan
Leave this out. It's for when you are forwarding a patch from someone
else. Also it has a typo and your email From: header is correct.
>
> the original imx hdmi driver is under staging/imx-drm,
> which depends on imx-d
is mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/da24c2b8/attachment.html>
The exynos fimd provides video type selection bits from system register
but exynos3 series don't has it, so needs has_vtsel flag and we can
distinguish whether set video type selection bits.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +-
1 file changed, 5
The exynos fimd provides video type selection bits from system register
but exynos3 series don't has it, so needs has_vtsel flag and we can
distinguish whether set video type selection bits.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +-
1 file changed, 5
The exynos fimd provides video type selection bits from system register
but exynos3 series don't has it, so needs has_vtsel flag and we can
distinguish whether set video type selection bits.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +-
1 file changed, 5
On 04/11/14 22:09, Daniel Vetter wrote:
> Currently there is no way to implement async flips using atomic, that
> essentially requires us to be able to cancel pending requests
> mid-flight.
>
> To be able to do that (and I guess we want this since vblank synced
> updates whic opportunistically can
On 11/04/2014 05:29 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a generic implementation of an object registry. This targets drivers
> and subsystems that provide auxiliary objects that other drivers need to
> look up. The goal is to put the difficult parts (keep object references,
>
On Tue, Nov 04, 2014 at 05:26:13PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Write more complete kerneldoc comments for the DRM panel API and
> integrate the helpers in the DRM DocBook reference.
>
> Signed-off-by: Thierry Reding
A few comments below. With thos addressed this is
Hi Dave,
Just various stuff all over from a bunch of people. Shortlog gives a beter
overview, it's really all misc drm patches.
Cheers, Daniel
The following changes since commit 1bcecfacde6269dc6cee9a098bc454222d441ff9:
drm/core: use helper to check driver features (2014-10-03 10:38:56 +0200
On 11/05/2014 12:07 AM, Daniel Vetter wrote:
> /**
> + * struct struct drm_atomic_state - the global state object for atomic
> updates
> + * @dev: parent DRM device
> + * @flags: state flags like async update
> + * @planes: pointer to array of plane pointers
> + * @plane_states: pointer to array
From: Thierry Reding
Drivers currently treat the IOCTL data for DRM_IOCTL_MODE_CREATE_DUMB
inconsistently. While the documentation clearly states that the handle,
pitch and size fields are outputs, some drivers use their values as a
minimum hint from userspace, presumably to allow userspace to ov
From: Thierry Reding
While at it, adjust the drm_gem_handle_create() function declaration to
be more consistent with other functions in the file.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_gem.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/
From: Thierry Reding
Use spaces consistently for indentation in the memory-management
section.
Signed-off-by: Thierry Reding
---
Documentation/DocBook/drm.tmpl | 268 -
1 file changed, 134 insertions(+), 134 deletions(-)
diff --git a/Documentation/DocBo
From: Thierry Reding
Most of the functions already have the beginnings of kerneldoc comments
but are using the wrong opening marker. Use the correct opening marker
and flesh out the comments so that they can be integrated with the DRM
DocBook document.
Signed-off-by: Thierry Reding
---
Documen
From: Thierry Reding
This function is similar to drm_gem_cma_dumb_create() but targetted at
kernel internal users so that they can override the pitch and size
requirements of the dumb buffer.
It is important to make this difference because the IOCTL says that the
pitch and size fields are to be
From: Thierry Reding
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags fields are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size.
Drivers must not treat these values as possible inputs, otherwise th
From: Thierry Reding
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags fields are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size.
Drivers must not treat these values as possible inputs, otherwise th
From: Thierry Reding
Some drivers treat the pitch and size fields as inputs and will use them
as minima provided by userspace so that they are only overwritten if the
minimal requirements of the driver exceed them.
This can cause strange behaviour when applications don't zero out these
fields, c
On 11/04/2014 03:39 PM, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 03:21:14PM +0100, Andrzej Hajda wrote:
>> On 11/04/2014 02:58 PM, Thierry Reding wrote:
>>> On Tue, Nov 04, 2014 at 12:43:21PM +0100, Andrzej Hajda wrote:
On 11/03/2014 10:13 AM, Thierry Reding wrote:
> [...]
> diff --
Hi Andy,
I think separating the core from the SoC specific part is a good step
into the right direction.
Am Mittwoch, den 05.11.2014, 20:55 +0800 schrieb Andy Yan:
> imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
> use the interface compatible Designware HDMI IP, but they
> also have s
Some differences compared to Rob's patches again:
- Dropped the committed and checked booleans. Checking will be
internally enforced by always calling ->atomic_check before
->atomic_commit. And async handling needs to be solved differently
because the current scheme completely side-steps ww m
Well, except page_flip since that requires async commit, which isn't
there yet.
For the functions which changes planes there's a bit of trickery
involved to keep the fb refcounting working. But otherwise fairly
straight-forward atomic updates.
The property setting functions are still a bit incomp
Currently there is no way to implement async flips using atomic, that
essentially requires us to be able to cancel pending requests
mid-flight.
To be able to do that (and I guess we want this since vblank synced
updates whic opportunistically cancel still pending updates seem to be
wanted) we'd ne
onflicts with the reference counted life-
times of these record objects.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/4e6c84bb/attachment-0001.sig>
On Wed, Nov 05, 2014 at 02:25:13PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> While at it, adjust the drm_gem_handle_create() function declaration to
> be more consistent with other functions in the file.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Daniel Vetter
> ---
> driv
On Wed, Nov 05, 2014 at 02:25:14PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Use spaces consistently for indentation in the memory-management
> section.
>
> Signed-off-by: Thierry Reding
Acked-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 268
> +++
Some differences compared to Rob's patches again:
- Dropped the committed and checked booleans. Checking will be
internally enforced by always calling ->atomic_check before
->atomic_commit. And async handling needs to be solved differently
because the current scheme completely side-steps ww m
On Wed, Nov 05, 2014 at 02:25:12PM +0100, Thierry Reding wrote:
> Discussion on IRC lead to the conclusion that new IOCTLs should have
> input validation and require userspace to zero out output parameters to
> avoid this kind of mess in the future. In order to help avoid this kind
> of ambiguity i
On Wed, Nov 05, 2014 at 02:25:15PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Most of the functions already have the beginnings of kerneldoc comments
> but are using the wrong opening marker. Use the correct opening marker
> and flesh out the comments so that they can be integrated w
On Wed, Nov 05, 2014 at 02:25:16PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> This function is similar to drm_gem_cma_dumb_create() but targetted at
> kernel internal users so that they can override the pitch and size
> requirements of the dumb buffer.
>
> It is important to make th
On Wed, Nov 05, 2014 at 02:25:17PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
> IOCTL, only the width, height, bpp and flags fields are inputs. The
> caller is not guaranteed to zero out or set handle, pitch and
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/dfa3a341/attachment.sig>
On Wed, Nov 05, 2014 at 02:25:18PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
> IOCTL, only the width, height, bpp and flags fields are inputs. The
> caller is not guaranteed to zero out or set handle, pitch and
On 11/04/2014 02:29 PM, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 11:41:15AM +0100, Andrzej Hajda wrote:
>> On 11/03/2014 10:13 AM, Thierry Reding wrote:
> [...]
>>> diff --git a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt
>>> b/Documentation/devicetree/bindings/panel/sharp
On Wed, Nov 05, 2014 at 02:25:19PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Some drivers treat the pitch and size fields as inputs and will use them
> as minima provided by userspace so that they are only overwritten if the
> minimal requirements of the driver exceed them.
>
> Thi
very human
readable. If that works for you it'd at least give you a means to check
that the kerneldoc comments you've added are consistent.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819
hen. E.g. here
>
> "This function implements an augmented version of the gem DRM file mmap
> operation for cma objects: In addition to the usual gem vma setup it
> immediately faults in the entire object instead of using on-demand
> faulting. Drivers which employ the cma helpers should use this function as
> their ->mmap handler for the DRM device file's file_operation structure."
I've taken the easy route and simply copied your example.
> So requires grepping each function and hunting for the usual pattern (and
> noticing tons of crazy stuff, usually).
>
> Same for all the functions below.
Okay, I'll see what I can come up with.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/13ffdda2/attachment.sig>
On Wed, Nov 05, 2014 at 02:24:42PM +, Russell King - ARM Linux wrote:
> On Wed, Nov 05, 2014 at 02:25:12PM +0100, Thierry Reding wrote:
> > Discussion on IRC lead to the conclusion that new IOCTLs should have
> > input validation and require userspace to zero out output parameters to
> > avoid
On Wed, Nov 05, 2014 at 04:01:26PM +0100, Thierry Reding wrote:
> On Wed, Nov 05, 2014 at 03:34:40PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 05, 2014 at 02:25:15PM +0100, Thierry Reding wrote:
> > > + * Return: A struct drm_gem_cma_object * on success or an
> > > ERR_PTR()-encoded
> >
> > Sam
started
with mesa 10.3.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/5819663d/attachment-0001.html>
ative speaker here ;-)
Alright, I'll go with the variant that you proposed for the sake of
consistency.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/fd7d4352/attachment.sig>
Reviewed-by: Rodrigo Vivi
On Tue, Oct 28, 2014 at 7:20 AM, Jani Nikula wrote:
> The Baseline_ELD_Len field does not include ELD Header Block size.
>
> From High Definition Audio Specification, Revision 1.0a:
>
> The header block is a fixed size of 4 bytes. The baseline block
> is
On 11/05/2014 03:04 PM, Thierry Reding wrote:
> On Wed, Nov 05, 2014 at 01:36:24PM +0100, Andrzej Hajda wrote:
>> On 11/04/2014 05:29 PM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Add a generic implementation of an object registry. This targets drivers
>>> and subsystems that provide
--
> include/drm/drm_modeset_lock.h | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/f63342a9/attachment.sig>
y;
> + uint32_t src_h, src_w;
Do we really use the 16.16 fixed point format for these? Maybe now would
be a good time to get rid of that if we don't need it. If they're not a
16.16 fixed point format they could also be unsized.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/dd908b27/attachment-0001.sig>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/c7200ca8/attachment.html>
On Sun, Nov 02, 2014 at 02:19:21PM +0100, Daniel Vetter wrote:
> Converting a driver to the atomic interface can be a daunting
> undertaking. One of the prerequisites is to have full universal planes
> support.
>
> To make that transition a bit easier this pathc provides plane helpers
s/pathc/patc
On Wed, Nov 5, 2014 at 5:45 PM, Sean Paul wrote:
>> + /* There's no other way to figure out whether the crtc is running. */
>> + ret = drm_crtc_vblank_get(crtc[i]);
>> + if (ret == 0) {
>> + drm_crtc_wait_one_vblank(crtc[i]);
>> + drm_crtc_vblank_put(crtc[i]);
>> + }
>
> This will be good motivati
Converting a driver to the atomic interface can be a daunting
undertaking. One of the prerequisites is to have full universal planes
support.
To make that transition a bit easier this patch provides plane helpers
which use the new atomic helper callbacks just only for the plane
changes. This way t
On Wed, Nov 5, 2014 at 5:26 PM, Thierry Reding
wrote:
>> +struct drm_plane_state {
>> + struct drm_crtc *crtc;
>> + struct drm_framebuffer *fb;
>> +
>> + /* Signed dest location allows it to be partially off screen */
>> + int32_t crtc_x, crtc_y;
>> + uint32_t crtc_w, crtc_h;
Some differences compared to Rob's patches again:
- Dropped the committed and checked booleans. Checking will be
internally enforced by always calling ->atomic_check before
->atomic_commit. And async handling needs to be solved differently
because the current scheme completely side-steps ww m
On Wed, Nov 05, 2014 at 06:04:59PM +0100, Daniel Vetter wrote:
> On Wed, Nov 5, 2014 at 5:26 PM, Thierry Reding
> wrote:
> >> +struct drm_plane_state {
> >> + struct drm_crtc *crtc;
> >> + struct drm_framebuffer *fb;
> >> +
> >> + /* Signed dest location allows it to be partially off
On Sun, Nov 02, 2014 at 02:19:22PM +0100, Daniel Vetter wrote:
> These two functions allow drivers to reuse their atomic plane helpers
> functions for the primary plane to implement the interfaces required
> by the crtc helpers for the legacy ->set_config callback.
>
> This is purely transitional a
On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote:
> So this is finally the integration of the crtc and plane helper
> interfaces into the atomic helper functions.
>
> In the check function we now have a few steps:
>
> - First we update the output routing and figure out which crtcs need
https://bugzilla.kernel.org/show_bug.cgi?id=87791
Bug ID: 87791
Summary: radeonsi lockup and oops
Product: Drivers
Version: 2.5
Kernel Version: 3.17
Hardware: x86-64
OS: Linux
Tree: Mainline
Status
https://bugzilla.kernel.org/show_bug.cgi?id=87791
--- Comment #1 from aCaB ---
Created attachment 156771
--> https://bugzilla.kernel.org/attachment.cgi?id=156771&action=edit
lockup example (with oops)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=87791
aCaB changed:
What|Removed |Added
Attachment #156771|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=87791
aCaB changed:
What|Removed |Added
Attachment #156761|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=87791
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
On Wed, Nov 05, 2014 at 02:46:10PM +0100, Daniel Vetter wrote:
> Well, except page_flip since that requires async commit, which isn't
> there yet.
>
> For the functions which changes planes there's a bit of trickery
> involved to keep the fb refcounting working. But otherwise fairly
> straight-forw
https://bugzilla.kernel.org/show_bug.cgi?id=87791
--- Comment #3 from aCaB ---
(In reply to Alex Deucher from comment #2)
> This sounds like a mesa regression rather than a kernel driver bug. Can you
> bisect mesa?
I understand mesa may be sending crap to the kernel space but that doesn't
sound
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/50d0a3a2/attachment.sig>
I've applied all the other nits, replies to the more interesting bits
below.
On Wed, Nov 05, 2014 at 01:53:48PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote:
> > + if (new_encoder != connector_state->best_encoder) {
>
> nit: If you just returned early wh
On Wed, Nov 05, 2014 at 02:48:48PM -0500, Sean Paul wrote:
> > + if (!crtc && crtc != set->crtc)
>
> I think this should be an ||
Hm. My idea idea was actually something along the lines of
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 4f80885de3f6..
boots but without dpm.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/67bfc131/attachment.html>
> "GR" == Guenter Roeck writes:
...
GR> AMD CPUs are known report wildly off temperatures especially at
GR> low temperatures.
Thanks. After some further digging, I wonder whether Aravind's recent
patch might help? The apu does have both PCI_DEVICE_ID_AMD_16H_M30H_NB_F3
and PCI_DEVICE_ID_AM
Hi Thierry,
Thank you for the patch.
On Wednesday 05 November 2014 14:25:18 Thierry Reding wrote:
> From: Thierry Reding
>
> When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
> IOCTL, only the width, height, bpp and flags fields are inputs. The
> caller is not guaranteed t
On Wed, Nov 05, 2014 at 10:13:53AM +0100, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 08:38:45AM -0800, Greg Kroah-Hartman wrote:
> > On Tue, Nov 04, 2014 at 05:29:27PM +0100, Thierry Reding wrote:
> [...]
> > > diff --git a/drivers/base/registry.c b/drivers/base/registry.c
> [...]
> > > +/**
>
We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly difference, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only access by w
imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly difference, such as phy pll configuration,
register width(imx hdmi register is one byte, but rk3288 is 4
bytes width), 4K support(imx6 doesn't support 4k, but r
This one patch does too much to be reviewed easily.
One patch is supposed to modify/add one thing at a time in the kernel.
Separating platform specific code from imx-drm/imx-hdmi is one thing.
Adding support for multi-byte register access is something different.
i.e. Something like.
1/3 split
On Wed, Nov 05, 2014 at 04:15:54PM -0500, James Cloos wrote:
> I'm getting odd temp readings on an A8-7600 with 3.3.4 and Linus'
> current kernel.
>
> Eg, the gpu temp shows up when (mostly) idle as:
>
> radeon-pci-0008
> Adapter: PCI adapter
> temp1: -1.0°C (crit = +120.0°C, hyst =
the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi drvier out
to drm/bridge and rename imx-hdmi to dw-hdmi
Signed-off-by: Andy Yan
---
drivers/gpu/drm/bridge/Kconfig | 5 +
drivers/gpu/drm/bridge/Makefile
2014-11-05 17:38 GMT+03:00 Thierry Reding :
> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
>> Hi,
>>
>> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM
>> of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is
>> set to 'y'.
>> The issue h
On Wed, Nov 05, 2014 at 06:34:20PM -0500, James Cloos wrote:
> > "GR" == Guenter Roeck writes:
>
> ...
> GR> AMD CPUs are known report wildly off temperatures especially at
> GR> low temperatures.
>
> Thanks. After some further digging, I wonder whether Aravind's recent
> patch might help?
imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly difference, such as phy pll configuration,
register width(imx hdmi register is one byte, but rk3288 is 4
bytes width), 4K support(imx6 doesn't support 4k, but r
89 matches
Mail list logo
