On 15.05.2014 06:01, Rahul Sharma wrote:
> Thanks Tomasz,
>
> On 15 May 2014 01:31, Tomasz Figa wrote:
>> Hi Rahul, Tomasz,
> [snip]
>>> + simplephys: simple-phys at 1004 {
>>> + compatible = "samsung,exynos5250-simple-phy";
>>
>> Missing reg property or unnecessary @unit-addr
ce they
> won't be documented.
Added where? simple-panel.txt or in separate files per compatible?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/6f9b5290/attachment.sig>
On Thu, May 15, 2014 at 10:51 PM, Lee, Chon Ming
wrote:
> On 04/30 10:07, Matt Roper wrote:
>> Pull the parameter checking from drm_primary_helper_update() out into
>> its own function; drivers that provide their own setplane()
>> implementations rather than using the helper may still want to shar
Hi Rob,
0day kernel testing robot got the below dmesg and the first bad commit is
git://people.freedesktop.org/~robclark/linux cold-fusion
commit 4eb7eae00f39d53f64441d05161317eb5fd704a6
Author: Rob Clark
AuthorDate: Sat Mar 15 12:37:16 2014 -0400
Commit: Rob Clark
CommitDate: Wed May 1
On Thu, May 15, 2014 at 07:37:32AM -0700, H. Peter Anvin wrote:
> On 05/15/2014 05:38 AM, Daniel Vetter wrote:
> > On Wed, May 14, 2014 at 09:41:12AM -0600, Ross Zwisler wrote:
> >> With this commit:
> >>
> >> 2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range
> >>
> >> If clflushopt is ava
Hi Daniel,
Thank you for the patch.
On Thursday 15 May 2014 15:00:08 Daniel Vetter wrote:
> Leftover from the old days of ums and should be used any longer. Since
>
> commit 29935554b384b1b3a7377d6f0b03b21d18a61683
> Author: Laurent Pinchart
> Date: Wed May 30 00:58:09 2012 +0200
>
> drm
|a buffer|a buffer with Tesseract
--
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/20140515/4d7e4
Like all of the other *30 ThinkPad models, the W530 has a broken acpi-video
backlight control. Note in order for this to actually fix things on the
ThinkPad W530 the commit titled:
"nouveau: Don't check acpi_video_backlight_support() before registering
backlight"
is also needed.
https://bugzilla.
When video.use_native_backlight=1 and non intel gfx are in use, the raw
backlight device of the gfx driver will show up after acpi-video has done its
acpi_video_verify_backlight_support() check.
This causes video.use_native_backlight=1 to not have the desired result.
This patch fixes this by addi
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the fin
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will us
Hi all,
Here is a patch series to make video.use_native_backlight work on laptops
with nv gfx, at least on those were nv gfx have a raw backlight interface.
I've tried this on my own somewhat old nv equipped laptop, but that does
not have a raw backlight interface.
I'm currently doing a scratch
On Thu, May 15, 2014 at 6:04 PM, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 12:32:58PM +0200, Thierry Reding wrote:
>> On Fri, May 09, 2014 at 09:59:34AM -0400, Rob Clark wrote:
>> > On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda
>> > wrote:
>> [...]
>> > > 4. And the last thing, it is more a
On 15 May 2014 19:11, Kishon Vijay Abraham I wrote:
>
>
> On Thursday 15 May 2014 07:05 PM, Rahul Sharma wrote:
>> Hi,
>>
>> On 15 May 2014 19:01, Bartlomiej Zolnierkiewicz
>> wrote:
>>>
>>> Hi,
>>>
>>> On Thursday, May 15, 2014 12:47:21 AM Rahul Sharma wrote:
From: Tomasz Stanislawski
On Thursday 15 May 2014 07:05 PM, Rahul Sharma wrote:
> Hi,
>
> On 15 May 2014 19:01, Bartlomiej Zolnierkiewicz
> wrote:
>>
>> Hi,
>>
>> On Thursday, May 15, 2014 12:47:21 AM Rahul Sharma wrote:
>>> From: Tomasz Stanislawski
>>>
>>> Add exynos-simple-phy driver to support a single register
>>>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/bbe3b5ad/attachment.html>
Hi,
On 15 May 2014 19:01, Bartlomiej Zolnierkiewicz
wrote:
>
> Hi,
>
> On Thursday, May 15, 2014 12:47:21 AM Rahul Sharma wrote:
>> From: Tomasz Stanislawski
>>
>> Add exynos-simple-phy driver to support a single register
>> PHY interfaces present on Exynos4 SoC.
>>
>> Signed-off-by: Tomasz Stan
From: Tomasz Stanislawski
The HDMIPHY (physical interface) is controlled by a single
bit in a power controller's regiter. It was implemented
as clock. It was a simple but effective hack.
This patch makes S5P-HDMI driver to control HDMIPHY via PHY interface.
Signed-off-by: Tomasz Stanislawski
S
From: Tomasz Stanislawski
The HDMIPHY (physical interface) is controlled by a single
bit in a power controller's regiter. It was implemented
as clock. It was a simple but effective hack.
This patch makes HDMI driver to control HDMIPHY via PHY interface.
Signed-off-by: Tomasz Stanislawski
Signe
From: Tomasz Stanislawski
Add exynos-simple-phy driver to support a single register
PHY interfaces present on Exynos4 SoC.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/phy/samsung-phy.txt| 57 ++
drivers/phy/Kconfig
From: Rahul Sharma
Changelog:
v4:
* Rename files to follow "phy-exynos-simple" names.
* Rename Macros to this convention PHY_EXYNOS_SIMPLE_.
* Added list of phy specifier values to documentation file.
* Removed of_match_ptr from driver probe.
* Moved u
The DRM core will translate calls to legacy cursor ioctls into universal
cursor calls automatically, so there's no need to maintain the legacy
cursor support. This greatly simplifies the transition since we don't
have to handle reference counting differently depending on which cursor
interface was
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter. The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call
Universal plane support had placeholders for cursor planes, but didn't
actually do anything with them. Save the cursor plane reference inside
the crtc and update the cursor plane parameter from void* to drm_plane.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 5 -
include/drm/d
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition
Cursor planes are a bit trickier to support via the universal plane interface
than primary planes were. Legacy cursor ioctls take handles to driver buffers
directly whereas the universal plane API takes drm_framebuffer's that represent
a buffer; due to this mismatch it isn't possible to implement
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
> op 15-05-14 17:48, Christian K?nig schreef:
>> Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
>>> op 15-05-14 15:19, Christian K?nig schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
> op 15-05-14 11:42, Christian K?nig schreef:
>>>
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/c90346ac/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #13 from Tasev Nikola ---
Created attachment 136251
--> https://bugzilla.kernel.org/attachment.cgi?id=136251&action=edit
dmesg broken 3.15-rc5
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #12 from Tasev Nikola ---
Created attachment 136241
--> https://bugzilla.kernel.org/attachment.cgi?id=136241&action=edit
dmesg working 3.15-rc5
--
You are receiving this mail because:
You are watching the assignee of the bug.
op 15-05-14 17:48, Christian K?nig schreef:
> Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
>> op 15-05-14 15:19, Christian K?nig schreef:
>>> Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian K?nig schreef:
> Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
>>>
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #11 from Tasev Nikola ---
Hi
I just notice that the 3.15-rc5 will boot successfully only once in 5-6
attempt.
When i try it the first time in sunday i was just lucky he boot at first time.
I suspend resume this computer rater then sh
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
> op 15-05-14 15:19, Christian K?nig schreef:
>> Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
>>> op 15-05-14 11:42, Christian K?nig schreef:
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
> op 15-05-14 11:21, Christian K?nig schreef:
>>>
On Thu, May 15, 2014 at 1:43 PM, Thierry Reding
wrote:
> On Wed, May 14, 2014 at 11:39:30PM +0530, Ajay kumar wrote:
> [...]
>> >> >> diff --git
>> >> >> a/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
>> >> >> b/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
>> >>
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #10 from Tasev Nikola ---
I'm compiling a patched kernel now.
I will test it but to be shure i will need 4-5 day's probably,
because i use the 3.15-rc5 from sunday and the problem appear only now.
--
You are receiving this mail becau
op 15-05-14 15:19, Christian K?nig schreef:
> Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
>> op 15-05-14 11:42, Christian K?nig schreef:
>>> Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian K?nig schreef:
> Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
>>>
On 05/15/2014 03:41 PM, Thierry Reding wrote:
> On Thu, May 15, 2014 at 09:54:07AM -0600, Stephen Warren wrote:
>> On 05/15/2014 04:54 AM, Thierry Reding wrote:
>>> On Thu, May 15, 2014 at 12:25:47PM +0200, Philipp Zabel wrote:
The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels,
w
Only the low-level irq handling functions still use integer crtc
indices with this. But fixing that will require a lot more sugery
and some good ideas for backwards compat with old ums userspace.
Both in drivers and in the drm core.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dis
We need to start somewhere ... With this the only places left in i915
where we use pipe integers is in the interrupt handling code. And
there it actually makes some amount of sense.
v2:
- Polish kerneldoc a bit (Thierry).
- Drop "dev" parameter since it's unecessary.
- Split out i915 changes (Thie
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #9 from Christian K?nig ---
(In reply to Alex Deucher from comment #8)
> Does this patch help:
> http://lists.freedesktop.org/archives/dri-devel/2014-May/059469.html
Unlikely. Tasev has an RS780, on those the feedback divider is usual
Hi,
On Thursday, May 15, 2014 12:47:21 AM Rahul Sharma wrote:
> From: Tomasz Stanislawski
>
> Add exynos-simple-phy driver to support a single register
> PHY interfaces present on Exynos4 SoC.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Rahul Sharma
>
> ---
> .../devicetree/bin
https://bugzilla.kernel.org/show_bug.cgi?id=75241
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #8 fr
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
> op 15-05-14 11:42, Christian K?nig schreef:
>> Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
>>> op 15-05-14 11:21, Christian K?nig schreef:
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
> op 14-05-14 17:29, Christian K?nig schreef:
>>>
https://bugzilla.kernel.org/show_bug.cgi?id=74751
--- Comment #21 from Daniel Vetter ---
Ok, the offending commit is actually 177cf92de4aa97ec1435987e91696ed8b5023130,
at least that one matches the diff of your change. It references the other
commit, but that's not the commit itself.
For debuggi
https://bugzilla.kernel.org/show_bug.cgi?id=75241
Tasev Nikola changed:
What|Removed |Added
CC||tasev.stefanoska at skynet.be
--- Comment
op 15-05-14 11:42, Christian K?nig schreef:
> Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
>> op 15-05-14 11:21, Christian K?nig schreef:
>>> Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian K?nig schreef:
>> +/* did fence get signaled after we enabled th
- Integrate into the drm DocBook
- Disable kerneldoc for functions not exported to drivers.
- Properly document the new drm_vblank_on|off and add cautious
comments explaining when drm_vblank_pre|post_modesets shouldn't be
used.
- General polish and OCD.
v2: Polish as suggested by Thierry.
Cc:
Leftover from the old days of ums and should be used any longer. Since
commit 29935554b384b1b3a7377d6f0b03b21d18a61683
Author: Laurent Pinchart
Date: Wed May 30 00:58:09 2012 +0200
drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers
it is a complete no-Op for kms drivers.
v2: Fix up mang
On Wed, May 14, 2014 at 09:41:12AM -0600, Ross Zwisler wrote:
> With this commit:
>
> 2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range
>
> If clflushopt is available on the system, we use it instead of clflush
> in drm_clflush_virt_range. There were two calls to clflush in this
> funct
On Thu, May 15, 2014 at 12:32:58PM +0200, Thierry Reding wrote:
> On Fri, May 09, 2014 at 09:59:34AM -0400, Rob Clark wrote:
> > On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda
> > wrote:
> [...]
> > > 4. And the last thing, it is more about the concept/design. drm_bridge,
> > > drm_hw_block sugges
From: Masanari Iida
Fix spelling typo in DocBook/drm.tmpl
Signed-off-by: Masanari Iida
Signed-off-by: Randy Dunlap
---
Documentation/DocBook/drm.tmpl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- lnx-315-rc2.orig/Documentation/DocBook/drm.tmpl
+++ lnx-315-rc2/Doc
On 15 May 2014 13:12, Thierry Reding wrote:
> On Thu, May 15, 2014 at 10:49:37AM +0530, Rahul Sharma wrote:
>> Hi Thierry,
>>
>> On 15 May 2014 03:44, Thierry Reding wrote:
>> > On Thu, May 15, 2014 at 12:47:21AM +0530, Rahul Sharma wrote:
> [...]
>> >> +#define HDMI_PHY 0
>> >> +#define DAC_
On 15.05.2014 03:51, Daniel Vetter wrote:
> @@ -964,8 +1005,13 @@ EXPORT_SYMBOL(drm_vblank_off);
>
> /**
> * drm_vblank_on - enable vblank events on a CRTC
> - * @dev: DRM device
> + * @dev: drm device
> * @crtc: CRTC in question
> + *
> + * This functions restores the vblank interrupt state
On 15.05.2014 03:51, Daniel Vetter wrote:
> Leftover from the old days of ums and should be used any longer. Since
>
> commit 29935554b384b1b3a7377d6f0b03b21d18a61683
> Author: Laurent Pinchart
> Date: Wed May 30 00:58:09 2012 +0200
>
> drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers
>
On Thu, May 15, 2014 at 12:42 PM, Thierry Reding
wrote:
> On Thu, May 15, 2014 at 12:10:16PM +0200, Daniel Vetter wrote:
>> On Thu, May 15, 2014 at 9:34 AM, Thierry Reding
>> wrote:
>> > This seems slightly backwards. Since drm_vblank_get() is what's being
>> > deprecated here, wouldn't it make m
> Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/697083ba/attachment.sig>
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/579360e2/attachment.sig>
---
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/1f23d845/attachment.sig>
On Thu, 15 May 2014 10:54:36 +0100
Chris Wilson wrote:
> i915.ko has a custom fbdev initialisation routine that aims to preserve
> the current mode set by the BIOS, unless overruled by the user. The
> user's wishes are determined by what, if any, mode is specified on the
> command line (via the v
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/b2e25225/attachment-0001.sig>
On Wed, May 14, 2014 at 5:27 PM, Rafa? Mi?ecki wrote:
> What initially seemed to be a typo in fglrx (using register 0x740c
> instead of 74dc) appeared to be a correct behavior. Without this
> 0x740c reg operation DCE 3 doesn't work and it seems we got code for
> that already in place.
> Recent RE
The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels,
which can be supported by the simple panel driver.
Signed-off-by: Philipp Zabel
---
Changes since v2:
- Added device tree binding documentation. Do we really want to add one little
file for each panel?
---
.../devicetree/bindings/pa
On Thu, May 15, 2014 at 9:34 AM, Thierry Reding
wrote:
> This seems slightly backwards. Since drm_vblank_get() is what's being
> deprecated here, wouldn't it make more sense to write
> drm_crtc_vblank_get() in terms of struct drm_crtc and make
> drm_vblank_get() call that instead? I can't seem to
On Mon, 12 May 2014, Aaron Lu wrote:
> On 05/04/2014 03:22 PM, Chris Wilson wrote:
>> 32b * 32b = 32b
>>
>> n = (u64)level * freq; to avoid overflow as you claim.
>
> Updated patch to fix this problem is here, thanks!
Pushed to -fixes with Chris' IRC r-b, thanks for the patch and review.
BR,
Ja
On Thu, May 15, 2014 at 01:44:04PM +0900, Michel D?nzer wrote:
> On 15.05.2014 03:51, Daniel Vetter wrote:
> > @@ -964,8 +1005,13 @@ EXPORT_SYMBOL(drm_vblank_off);
> >
> > /**
> > * drm_vblank_on - enable vblank events on a CRTC
> > - * @dev: DRM device
> > + * @dev: drm device
> > * @crtc:
e: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/f7e90997/attachment-0001.sig>
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
> op 15-05-14 11:21, Christian K?nig schreef:
>> Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
>>> op 14-05-14 17:29, Christian K?nig schreef:
> +/* did fence get signaled after we enabled the sw irq? */
> +if
> (atomic64_read(&
From: Stefan Agner
This panel is sold by Toradex for Colibri T20/T30 and Apalis T30
evaluation kits.
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/panel/edt,et057090dhu.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 26 ++
2 files changed,
op 15-05-14 11:21, Christian K?nig schreef:
> Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
>> op 14-05-14 17:29, Christian K?nig schreef:
+/* did fence get signaled after we enabled the sw irq? */
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence-
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/82f44106/attachment.sig>
x27;t.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/d05d45c2/attachment.sig>
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
> op 14-05-14 17:29, Christian K?nig schreef:
>>> +/* did fence get signaled after we enabled the sw irq? */
>>> +if
>>> (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
>>> fence->seq) {
>>> +radeon_irq_kms_sw_irq_pu
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed
ses.
Interfaces are exposed explicitly at probe time by the device drivers
for the devices they drive.
Even though this was designed with the above use-case in mind I can
imagine this to be useful for other things as well. For example a set of
generic interfaces could be created and devices (or even whole classes
of devices) could be made to expose these interfaces. This would cause
interfaces to be created for each of these devices. That's functionality
similar to what can be done with notifiers, albeit somewhat more
structured. That could for example be useful to apply policy to a class
of devices or collect statistics, etc.
If you think that I'm on a wild-goose chase, please let me know so that
I don't waste any more time on this.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/cec82d64/attachment.sig>
What I understood from the reviews comments from the experts, is having
a central color management at DRM kernel layer is not a good idea, and
we should create individual DRM properties for the color correction
methods, and let the control be there in the user space level, where an
atomic modes
Hi Thierry,
On 15 May 2014 03:44, Thierry Reding wrote:
> On Thu, May 15, 2014 at 12:47:21AM +0530, Rahul Sharma wrote:
> [...]
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> [...]
>> +For "samsung,exynos4210-sim
The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels,
which can be supported by the simple panel driver.
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Added compatible for EDT ET070080DH6 panel, which is exactly the same panel
minus the multitouch.
---
drivers/gpu/drm/panel/pane
ons may be different the panel may not work.
So before we go and add any new functions to DRM panel I'd like to see
them properly documented. It needs to be defined precisely what the
effect of these functions should be so that both panel driver writers
know what to implement and display driver writers need to know when to
call which function.
Also, please let's not call them .pre_enable() and .post_disable(). The
names should be something more specific to reflect what they are meant
to do. Even something like .prepare() and .unprepare() would be better
choices.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/7ebffebe/attachment.sig>
On 05/15/2014 04:54 AM, Thierry Reding wrote:
> On Thu, May 15, 2014 at 12:25:47PM +0200, Philipp Zabel wrote:
>> The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels,
>> which can be supported by the simple panel driver.
>>
>> Signed-off-by: Philipp Zabel
>> ---
>> Changes since v2:
>> - A
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/6cb9d023/attachment-0001.sig>
or the reverse lookup.
I'd still prefer to have i915 changes in a separate commit, but
otherwise:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/a73aaf70/attachment.sig>
Thanks Tomasz,
On 15 May 2014 01:31, Tomasz Figa wrote:
> Hi Rahul, Tomasz,
[snip]
>> + simplephys: simple-phys at 1004 {
>> + compatible = "samsung,exynos5250-simple-phy";
>
> Missing reg property or unnecessary @unit-address suffix in node name.
I should have removed "@unit
Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231
Signed-off-by: Rafa?
Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bu
; when
> + * disabling a crtc. This function ensures that the latest vblank frame
> count is
> + * stored so that drm_vblank_on can restore it again.
drm_vblank_on() to have it correctly highlighted?
Thierry
-- next part ------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/e240ce47/attachment-0001.sig>
attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/40ef3b0b/attachment.sig>
Sounds good to me.
Regards
Shashank
-Original Message-
From: Thierry Reding [mailto:thierry.red...@gmail.com]
Sent: Thursday, May 15, 2014 12:36 PM
To: Sharma, Shashank
Cc: Daniel Vetter; intel-gfx; dri-devel; Purushothaman, Vijay A; Mukherjee,
Indranil; Shankar, Uma; Jindal, Sonika; K
On 05/15/2014 05:38 AM, Daniel Vetter wrote:
> On Wed, May 14, 2014 at 09:41:12AM -0600, Ross Zwisler wrote:
>> With this commit:
>>
>> 2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range
>>
>> If clflushopt is available on the system, we use it instead of clflush
>> in drm_clflush_virt_rang
ves/dri-devel/attachments/20140515/185da0e2/attachment.html>
op 14-05-14 17:29, Christian K?nig schreef:
>> +/* did fence get signaled after we enabled the sw irq? */
>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
>> fence->seq) {
>> +radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring);
>> +return false;
>> +
es/dri-devel/attachments/20140515/9eb71ee3/attachment-0001.html>
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/20140515/7f06a260/attachment.html>
seems to hang the entire machine
--
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/20140515/521356ed/attachment.html>
From: Tomasz Stanislawski
The HDMIPHY (physical interface) is controlled by a single
bit in a power controller's regiter. It was implemented
as clock. It was a simple but effective hack.
This patch makes S5P-HDMI driver to control HDMIPHY via PHY interface.
Signed-off-by: Tomasz Stanislawski
S
From: Tomasz Stanislawski
The HDMIPHY (physical interface) is controlled by a single
bit in a power controller's regiter. It was implemented
as clock. It was a simple but effective hack.
This patch makes HDMI driver to control HDMIPHY via PHY interface.
Signed-off-by: Tomasz Stanislawski
Signe
From: Tomasz Stanislawski
Add exynos-simple-phy driver to support a single register
PHY interfaces present on Exynos4 SoC.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/phy/samsung-phy.txt| 56 ++
drivers/phy/Kconfig
From: Rahul Sharma
Hi All,
This series has been originally proposed by Tomasz Stanislawski. With
his permission, I have addressed the following review comments in V3.
Changelog:
v3:
* Implement lazy-init of PHYs.
* Use MACROs instead of numbers to represent phys.
* Use r
ource file.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/149ff3ae/attachment.sig>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/9a0ee03c/attachment.html>
99 matches
Mail list logo
