Am Samstag, 24. Oktober 2015, 11:06:37 schrieb Yakir Yang:
> Add dt binding documentation for rockchip display port PHY.
>
> Tested-by: Javier Martinez Canillas
> Signed-off-by: Yakir Yang
> ---
phy binding looks nice and easy
Reviewed-by: Heiko Stuebner
Am Samstag, 24. Oktober 2015, 11:06:04 schrieb Yakir Yang:
> Add phy driver for the Rockchip DisplayPort PHY module. This
> is required to get DisplayPort working in Rockchip SoCs.
>
> Tested-by: Javier Martinez Canillas
> Signed-off-by: Yakir Yang
> ---
> diff --git a/drivers/phy/phy-rockchip-
Patch subject should probably be something like:
dt-bindings: add document for rockchip variant of analogix_dp
or similar, but definitly should mention that it's the Rockchip variant.
Am Samstag, 24. Oktober 2015, 11:06:03 schrieb Yakir Yang:
> Rockchip DP driver is a helper driver of analogix_
Hi Yakir,
Am Samstag, 24. Oktober 2015, 11:06:00 schrieb Yakir Yang:
> Analogix dp driver is split from exynos dp driver, so we just
> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
>
> Beside update some exynos dtsi file with the latest change
> according to the devicetree bindin
On 27.10.2015 17:44, Michael Burian wrote:
> On 10/27/15 03:36, Michel Dänzer wrote:
>>>
>>> [0] contains dmesg output with your patch applied (which fixes the
>>> backlight issue)
>>
>> This is very surprising: The patch just adds some debugging output, it's
>> not supposed to have any functiona
On 10/27/15 17:43, Alex Deucher wrote:
>
> I see the problem. We don't enable native backlight control on older
> asics like yours by default. Does the attached patch help?
>
Yes, backlight is on again. (tested against mainline:
858e904bd71dd0057a548d6785d94ce5ec4aeabd)
thanks
On 10/27/15 16:10, Alex Deucher wrote:
>
> It would appear that your system does not use the gpu backlight
> controller. Either it's lying or messing with the GPU backlight
> controller causes some bad interaction with whatever does control it.
> Does the attached radeon patch help? I'm also at
nts/20151027/572dc1b2/attachment.html>
From: Christian König
No need to duplicate the functionality any more.
v2: fix handling if no fence is available.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher (v1)
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 --
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 98
From: Christian König
Waiting for the first fence in an array of fences to signal.
This is useful for device driver specific resource managers
and also Vulkan needs something similar.
v2: more parameter checks, handling for timeout==0,
remove NULL entry support, better callback removal.
S
Well that's strange. Essentially those are just duplicates to the
existing files and the driver should fallback to them.
IIRC the radeon/*_sdma1.bin files are only requested when you try to use
CIK support with amdgpu which isn't a good idea in a production environment.
What's the link for the
> -Original Message-
> From: Seth Forshee [mailto:seth.forshee at canonical.com]
> Sent: Tuesday, October 27, 2015 12:06 PM
> To: Koenig, Christian
> Cc: Deucher, Alexander; Oded Gabbay; dri-devel at lists.freedesktop.org
> Subject: Re: Missing amdgpu firmware files
>
> On Tue, Oct 27, 201
https://bugzilla.kernel.org/show_bug.cgi?id=106291
--- Comment #8 from universaledge97 at gmail.com ---
It turned out that the amdgpu kernel module was not included in compilation. I
normally use the linux-mainline package from the AUR (I run Arch Linux) to
install rc kernels, where, for some reas
> -Original Message-
> From: Koenig, Christian
> Sent: Tuesday, October 27, 2015 11:48 AM
> To: Seth Forshee; Deucher, Alexander; Oded Gabbay
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: Missing amdgpu firmware files
>
> Well that's strange. Essentially those are just duplicates
https://bugzilla.kernel.org/show_bug.cgi?id=106271
--- Comment #6 from Alex Deucher ---
(In reply to Aneroid from comment #5)
> Yes, I try to do that.
>
> xrandr --listproviders
> Providers: number : 2
> Provider 0: id: 0x7e cap: 0xf, Source Output, Sink Output, Source Offload,
> Sink Offload cr
Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume tha
Hi,
this is v11 of an attempt to make it easier for devices to remain in
runtime PM when the system goes to sleep, mainly to reduce the time
spent resuming devices.
For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors are
https://bugzilla.kernel.org/show_bug.cgi?id=106271
--- Comment #5 from Aneroid ---
Yes, I try to do that.
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7e cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 4 outputs: 4 associated providers: 0 name:radeon
P
DRM_TEGRA_FBDEV config is currently used to enable/disable legacy fbdev
emulation for the tegra kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option instead.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/tegra/Kconfig | 12
drivers/
DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation
for the sti kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option instead where applicable.
We replace the #ifdef in sti_drm_load with CONFIG_DRM_FBDEV_EMULATION.
It's probably o
DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev
emulation for the imx kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option where applicable. Using this config lets us also prevent
wrapping around drm_fb_helper_* calls with #ifdefs i
Instead of using a custom legacy fbdev emulation config option, use the
top level DRM_FBDEV_EMULATION config option.
There are 3 drivers which use custom config options: imx, sti and tegra.
Since the last revision, i915 and msm drivers have removed their custom
configs.
Remove the remaining confi
ex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-dpms-when-driver-backlight-control-is.patch
Type: text/x-patch
Size: 2351 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/7192775b/attachment-0001.bin>
Am Montag, den 26.10.2015, 20:48 + schrieb Russell King - ARM Linux:
> On Fri, Sep 25, 2015 at 01:57:58PM +0200, Lucas Stach wrote:
> > +void etnaviv_gpu_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf)
> > +{
> > + dma_free_writecombine(cmdbuf->gpu->dev, cmdbuf->size,
> > +
Michael, please keep the Cc: list intact.
On 26.10.2015 19:46, Michael Burian wrote:
> On 10/26/15 10:32, Michel Dänzer wrote:
>> On 25.10.2015 04:25, Michael Burian wrote:
>>>
>>> # first bad commit: [5a633828b4b2bef343826afcb0a70770c4911c55] drm/radeon:
>>> Restore LCD backlight level on res
On Tue, Oct 27, 2015 at 04:10:33PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Seth Forshee [mailto:seth.forshee at canonical.com]
> > Sent: Tuesday, October 27, 2015 12:06 PM
> > To: Koenig, Christian
> > Cc: Deucher, Alexander; Oded Gabbay; dri-devel at lists.freedes
taching an amdgpu
patch for reference in case the same problem appears on amdgpu.
Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-amdgpu-fix-backlight-handling-when-not-controlle.patch
Type: text/x-patch
Size: 2441 bytes
Desc: not available
URL:
&
On 10/27/15 10:17, Michel Dänzer wrote:
>
> I'm not familiar with the ATOM bytecode, but since the number of
> bytecode instructions executed seems the same in both cases, I suspect
> that dig->backlight_level == 0 => ATOM_LCD_BLOFF is executed. (The
> debugging output in my patch would have prov
On Tue, Oct 27, 2015 at 04:47:53PM +0100, Christian König wrote:
> Well that's strange. Essentially those are just duplicates to the
> existing files and the driver should fallback to them.
>
> IIRC the radeon/*_sdma1.bin files are only requested when you try to
> use CIK support with amdgpu whic
On 10/27/2015 05:33 AM, Rob Clark wrote:
> On Mon, Oct 26, 2015 at 5:54 AM, Archit Taneja
> wrote:
>> MDP5 has line count and frame count registers for each interface. Enable
>> these counters and use them to implement the get_vblank_timestamp drm
>> driver op.
>>
>> The line counter starts wit
I've received reports from Ubuntu users about missing amdgpu firmware
files with 4.2 kernels. The driver calls out a number of
radeon/*_sdma1.bin files that are not present in the linux-firmware git
repo. Are these files available anywhere (under a license that allows
redistribution), and will they
On Tue, 27 Oct 2015, Eric Biggers wrote:
> On Mon, Oct 26, 2015 at 03:28:37PM +0200, Jani Nikula wrote:
>> Please file two separate bugs at [1], one for the above, and another for
>> the below. Please add drm.debug=14 module parameter, and attach dmesg
>> all the way from boot to the problem.
>
>
EG[0x1EBC]
.[31:24] -> 0x02
src:
IMM 0x01
dst:
REG[0x1EBC]
.[31:24] <- 0x03
JUMP @ 0xD3F8
target: 0x015B
EOT @ 0xD405
<<
radeon_stop_backlight_old_way
-- next part --
A non-text attachment was scrubbed...
Name: atomdebug.diff
Type: text/x-patch
Size: 1430 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/a392214c/attachment-0001.bin>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/d9c69f3c/attachment.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/aa282ace/attachment.html>
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >
> > > Furthermore, that applies only to devices that use synchronous suspend.
> > > Async suspend is becoming common, and the
https://bugzilla.kernel.org/show_bug.cgi?id=106291
--- Comment #7 from Michel Dänzer ---
The log from 4.3-rc6 doesn't show any trace of the amdgpu driver. Did you
accidentally disable it when compiling that kernel?
--
You are receiving this mail because:
You are watching the assignee of the bu
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is s
38 matches
Mail list logo
