On Mon, Jun 16, 2014 at 11:13:02AM -0300, Fabio Estevam wrote:
> On Wed, Jun 11, 2014 at 5:17 AM, Russell King - ARM Linux
> wrote:
>
> > The problem here is that we need more inteligence from CCF in order to
> > do that - we need it to be able to reprogram the dividers so that the
> > IPU DI0 cl
>
> --
> Sylvain
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/a05873ff/attachment.html>
ves/dri-devel/attachments/20140616/2365ec18/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78111
--- Comment #4 from Alex Deucher ---
You may get system or GPU hangs, but it shouldn't fry anything.
--
You are receiving this mail because:
You are watching the assignee of the bug.
ches on this bug.
--
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/20140616/76f508d1/attachment.html>
.
--
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/20140616/46aa9a14/attachment.html>
nts/20140616/7f01e239/attachment.html>
reedesktop.org/archives/dri-devel/attachments/20140616/dc2077a4/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78111
Kertesz Laszlo changed:
What|Removed |Added
CC||laszlo.kertesz at gmail.com
--- Comment
On 16/06/2014 19:03, Lee Jones wrote:
> On Mon, 16 Jun 2014, Boris BREZILLON wrote:
>> On 16/06/2014 14:50, Lee Jones wrote:
The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by
On Mon, 16 Jun 2014, Boris BREZILLON wrote:
> On 16/06/2014 14:50, Lee Jones wrote:
> >> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> >> family or sama5d3 family) exposes 2 subdevices:
> >> - a display controller (controlled by a DRM driver)
> >> - a PWM chip
> >>
> >>
Make sure we have an HDMI monitor before validating modes with
clocks >165 Mhz on single link connections.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon
When we have a passive adapter validate the clocks
against the HMDI/DVI limits.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/driver
The tegra-cpufreq driver is only for Tegra20, an upcoming driver for
Tegra124 will be separate, so this is not needed.
Thanks,
- Mikko
On 06/16/2014 04:35 PM, Tomeu Vizoso wrote:
> Instead of setting a direct correlation to the CPU frequency. This allows
> for other devices to influence the fina
roper fix, I will post it to this bug (this could be a
while).
--
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/20140616/
It should be mentioned that calling clk_set_rate on the EMC clock
currently does absolutely nothing (except probably returning an error).
The rate switching sequence is not implemented (nor is the clock tree
entirely correct. For example, the kernel thinks that PLL_M is disabled).
Another note:
On Mon, Jun 16, 2014 at 2:20 PM, Stephane Viau wrote:
> This changes activates the iommu support for MDP5, through the
> platform config structure.
>
> Iommu support is also slightly modified in order to make sure
> that MDP iommu is properly cleaned up if a probe deferral is
> requested. Before t
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #10 from maxis11 ---
3.16-rc1 still buggy
--
You are receiving this mail because:
You are watching the assignee of the bug.
Instead of setting a direct correlation to the CPU frequency. This allows
for other devices to influence the final effective EMC frequency.
In the future, this should be done instead by an ACTMON driver,
which would also take load stats into account when calculating the
floor EMC frequency.
Signe
Request it based solely on the current mode's refresh rate. More
accurate requirements can be requested in future patches.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/tegra/dc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc
Add a device node for the EMC found on Tegra124.
Signed-off-by: Tomeu Vizoso
---
arch/arm/boot/dts/tegra124.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 6e6bc4e..5aa42ff 100644
--- a/arch/arm/boot/dts/te
Adds functionality for registering memory bandwidth needs and setting
the EMC clock rate based on that.
Also adds API for setting floor and ceiling frequency rates.
Signed-off-by: Tomeu Vizoso
---
.../bindings/arm/tegra/nvidia,tegra124-emc.txt | 26
drivers/memory/Kconfig
Hi,
here is an initial implementation of EMC scaling for Tegra124, I'm most
interested in feedback on the approach.
The present incarnation is very much specific to Tegra, but I'm sure that we
could find an API that can be shared across SoC families.
I have looked at using existing frameworks (c
Hello Lee,
On 16/06/2014 14:50, Lee Jones wrote:
>> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
>> family or sama5d3 family) exposes 2 subdevices:
>> - a display controller (controlled by a DRM driver)
>> - a PWM chip
>>
>> Add support for the MFD device which will just
|--- |FIXED
--
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/20140616/f50f7d21/attachment.html>
u 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/20140616/82614389/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78111
--- Comment #2 from Alex Deucher ---
Created attachment 139971
--> https://bugzilla.kernel.org/attachment.cgi?id=139971&action=edit
enable bapm
The attached patch will allow the GPU and CPU to share TDP, but note that this
is disabled by defaul
https://bugzilla.kernel.org/show_bug.cgi?id=78111
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
oes the attached patch help?
--
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/20140616/575079e0/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/5561046b/attachment.html>
On 06/16/2014 12:11 PM, Denis Carikli wrote:> + reg_lcd_3v3: lcd-en {
> +compatible = "regulator-fixed";
> +pinctrl-names = "default";
> +pinctrl-0 = <&pinctrl_reg_lcd_3v3>;
> +regulator-name = "lcd-3v3";
> +regulator-min-microvolt =
https://bugzilla.kernel.org/show_bug.cgi?id=78111
Bug ID: 78111
Summary: APU turbo core boost not working when radeon.dpm=1
Product: Drivers
Version: 2.5
Kernel Version: 3.14.6
Hardware: x86-64
OS: Linux
Tree:
This changes activates the iommu support for MDP5, through the
platform config structure.
Iommu support is also slightly modified in order to make sure
that MDP iommu is properly cleaned up if a probe deferral is
requested. Before this change, IOMMU faults would occur if the
probe failed (-EPROBE_
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/c44937ae/attachment.html>
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
> Request it based solely on the current mode's refresh rate. More
> accurate requirements can be requested in future patches.
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> + bandwidth = mode->clock * window.bits_per_pixel
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
> Adds functionality for registering memory bandwidth needs and setting
> the EMC clock rate based on that.
>
> Also adds API for setting floor and ceiling frequency rates.
> diff --git
> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra124-em
> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> family or sama5d3 family) exposes 2 subdevices:
> - a display controller (controlled by a DRM driver)
> - a PWM chip
>
> Add support for the MFD device which will just retrieve HLCDC clocks and
> create a regmap so that su
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/20140616/0e3c5d90/attachment.html>
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v11->v13:
- No changes
ChangeLog v9->v11:
- Now uses the drm-panel instead of the display-timings.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- The backlight is now on at boot.
ChangeLog
The CMO-QVGA, DVI-SVGA and DVI-VGA are added.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v10->v13:
- Rebased
- Removed enable-active-high in reg_lcd_3v3: its GPIO
already has the GPIO_ACTIVE_HIGH flag.
Without this removal, the display was off at boot
and powerin
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v12->v13:
- Added a note explaining why the size is zero in
the eukrea_mbimxsd51_dvi(s)vga structs.
ChangeLog v11->v12:
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
ChangeLog v10->v11:
- New patch.
The previous hardware behaviour was kept if the
flags are not set.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Rebased
ChangeLog v12->v13:
- This patch doesn't need the DRM_MODE_FLAG_POL_*_PRESERVE flags anymore.
- code cleanup to improve readability:
- ENABLE_POL_PRESERVE is now go
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Fixed DRM_MODE_FLAG_POL_DE_HIGH's description.
ChangeLog v12->v13:
- Added Docbook
The imx-drm driver can't use the de-active and
pixelclk-active display-timings properties yet.
Instead the data-enable and the pixel data clock
polarity are hardcoded in the imx-drm driver.
So theses properties are now set to keep
the same behaviour when imx-drm will start
using them.
Signed-off
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Rebased
ChangeLog 12->v13:
- No changes
ChangeLog 11->v12:
- Improved the define names to match the hardware:
ENABLE_POL is not a clock signal but instead an enable signal.
ChangeLog v9->v10:
- New patch which was splitted out from:
"stag
The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- Rebased
ChangeLog v10->v13:
- Rebased
ChangeLog v9->v10:
- Rebased.
- Added Philipp Zab
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- Rebased
ChangeLog v9->v13:
- Rebased
ChangeLog v8->v9:
- Rebased.
- Added Philipp Zabel's ack.
- Shortened the patch title.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- Rebased.
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Signed-off-by: Denis Carikli
Acked-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- None
ChangeLog v10->v13:
- No changes
On Mon, Jun 16, 2014 at 12:11:17PM +0200, Denis Carikli wrote:
> The current BGR666 is not consistent with the other color mapings like BGR24.
> BGR666 should be in the same byte order than BGR24.
>
> Signed-off-by: Denis Carikli
> Acked-by: Philipp Zabel
As I said probably around v10 time, I a
On Mon, Jun 16, 2014 at 12:11:16PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli
> Acked-by: Philipp Zabel
As I said probably around v10 time, I already have this patch queued,
and I was going to send it to Greg before the previous merge window,
but due to the number of patches I wa
On Mon, Jun 16, 2014 at 12:11:15PM +0200, Denis Carikli wrote:
> That new macro is needed by the imx_drm staging driver
> for supporting the QVGA display of the eukrea-cpuimx51 board.
As I said probably around v10 time, I already have this patch queued,
and I was going to send it to Greg before
On Wed, Jun 11, 2014 at 5:17 AM, Russell King - ARM Linux
wrote:
> The problem here is that we need more inteligence from CCF in order to
> do that - we need it to be able to reprogram the dividers so that the
> IPU DI0 clock remains at 148.5MHz while increasing the output of
> pll5_video_div thr
On Sunday, June 15, 2014 9:11 AM, Martin Kepplinger wrote:
>
> Fix a sparse warning: ttm_bo_reserve()'s last argument is a
> pointer to a struct, so use NULL as nullpointer.
>
> Signed-off-by: Martin Kepplinger
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> this applies to next-201
2014-06-15 16:48 GMT+02:00 Boris BREZILLON :
>
>
> Hello JJ,
>
> On 15/06/2014 10:53, Jean-Jacques Hiblot wrote:
> > On 06/09/2014 06:04 PM, Boris BREZILLON wrote:
> >> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> >> family or sama5d3 family) exposes 2 subdevices:
> >>
lem "solved itself": the machine recently died of hardware
failure. ;-|
Gr??e,
Thomas
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL:
<http://lists.freedesktop.o
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/026349e0/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/00ec7752/attachment.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/0dfc2c91/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/7349fc56/attachment.html>
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/d94c3a5d/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140616/b442e4ae/attachment.html>
vel/attachments/20140616/dd3d6378/attachment.html>
||
--
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/20140616/20c0e86c/attachment.html>
||
--
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/20140616/e83352b1/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/4e3a2fc3/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/e2548295/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140616/b4d03f02/attachment.html>
commit 4133c7126c8c694ee4b05da1f312c411c0f6fdeb
X log is attached.
--
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/20140616/bb55f298/attachment-0001.html>
68 matches
Mail list logo
