later).
--
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/20141202/2a7669ba/attachment.html>
y it means that the driver supports KMS and secondly
> > it means that a lot of the legacy stuff isn't supported. It also changes
> > the way in which driver initialisation is performed. Would it make sense
> > for the DRIVER_RENDER flag to have a similar effect? In other words,
> > should it turn off legacy stuff and use the newer method of driver
> > initialisation?
>
> DRIVER_MODESET means you have a modern driver which binds to the device.
> We should probably RENAME it to DRIVER_LEGACY and invert it's sense, but
> no one has stepped up to the taks.
Actually I did[0] a while ago. This is the second time that this has
come up within a month, so perhaps I should revive the series.
Thierry
[0]: http://lwn.net/Articles/588016/
-- 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/20141202/a500631b/attachment.sig>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/22554941/attachment.sig>
Hi Philipp:
On 2014å¹´12æ02æ¥ 18:24, Philipp Zabel wrote:
> Hi Andy,
>
> Am Dienstag, den 02.12.2014, 15:45 +0800 schrieb Andy Yan:
> [...]
>> +static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
>> + void *data)
>> +{
>> +struct platform_d
Hi Andy,
Am Dienstag, den 02.12.2014, 15:42 +0800 schrieb Andy Yan:
> diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
> b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
> new file mode 100644
> index 000..107c1ca
> --- /dev/null
> +++ b/Documentation/devicetree
On Wed, Nov 19, 2014 at 05:47:09PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The i915.ko driver needs a way to schedule certain functions to run
> after some amount of vblanks. There are many different pieces of the
> driver which could benefit from that.
>
> Since what we want is esse
On Wed, Nov 19, 2014 at 05:47:08PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The drivers need a way to schedule functions to be ran after a certain
> number of vblanks. The i915.ko driver has plenty of examples where
> this could be used, such as for unpinning buffers after a modeset.
>
8880 r5: r4:ee965b00
> [ 114.062927] [<7f015550>] (ResManFreeResByPtr+0x0/0x80 [omapdrm_pvr])
> from [<7f009314>] (async_unmap+0x34/0x54 [omapdrm_pvr])
> [ 114.062927] r5:7f0268a0 r4:ee9653c0
> [ 114.062957] [<7f0092e0>] (async_unmap+0x0/0x54 [omapdrm_pvr]) from
> [<803244e0>] (notify_worker+0x40/0x48)
> [ 114.062957] r6:7f0092e0 r5:807bbaa4 r4:ee965420 r3:
> [ 114.062957] [<803244a0>] (notify_worker+0x0/0x48) from [<80058198>]
> (process_one_work+0x278/0x488)
> [ 114.062988] r7:ef2aca00 r6:8073ee00 r5:ee965420 r4:ef0661c0
> [ 114.062988] [<80057f20>] (process_one_work+0x0/0x488) from [<80058808>]
> (worker_thread+0x278/0x398)
> [ 114.062988] [<80058590>] (worker_thread+0x0/0x398) from [<800600d4>]
> (kthread+0xbc/0xcc)
> [ 114.062988] [<80060018>] (kthread+0x0/0xcc) from [<8000ee18>]
> (ret_from_fork+0x14/0x20)
> [ 114.063018] r7: r6: r5:80060018 r4:ef0a5e58
> [ 114.063018] Code: e24cb004 e52de004 e8bd4000 e59031cc (e5130014)
> [ 114.063018] ---[ end trace 2441b1bbdffd41f0 ]---
> [ 114.063018] Fixing recursive fault but reboot is needed!
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/58488e96/attachment-0001.html>
On Mon, Dec 1, 2014 at 1:56 PM, Jilai Wang wrote:
> Add HDMI HDCP support including HDCP PartI/II/III authentication.
>
> Signed-off-by: Jilai Wang
> ---
Hi Jilai,
[..]
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
[..]
>
> @@ -119,6 +137,22 @@ struct hdmi
On Tuesday, December 02, 2014 5:17 PM, Javier Martinez Canillas wrote:
>
> Hello Kukjin,
>
> On Mon, Nov 24, 2014 at 6:41 AM, Vivek Gautam
> wrote:
> > DP PHY now require pmu-system-controller to handle PMU register
> > to control PHY's power isolation. Adding the same to dp-phy
> > node.
> >
>
Hi Dave
The following changes since commit 656d7077d8ffd1c2492d4a0a354367ab2e545059:
dt-bindings: iommu: Add documentation for rockchip iommu (2014-11-03
17:29:09 +0100)
are available in the git repository at:
https://github.com/markyzq/kernel-drm-rockchip.git drm_iommu_v15
for you to f
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
Changes in v7: No
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subsystem.
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
Cha
This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: Mark Yao
Signed-off-by: Daniel Kurtz
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- use the component framework to defer main drm driver probe
until all VOP devices have been probed.
-
This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.
The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two s
ture
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/e52bb147/attachment.sig>
"chess".
--
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/20141202/eceb057a/attachment.html>
From: Dave Airlie
Introduced in b440bde74f, however it was added to
the wrong function in nouveau.
https://bugzilla.kernel.org/show_bug.cgi?id=86011
Cc: Bjorn Helgaas
CC: stable at vger.kernel.org # v3.15+
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file ch
On Tue, Dec 02, 2014 at 09:21:51AM +, Frank Binns wrote:
> On 01/12/14 15:28, Daniel Vetter wrote:
> > On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote:
> >> Hi,
> >>
> >> We are currently in negotiations with one of our customers (Mediatek) on
> >> a strategy that will allow them to
On 10/13/2014 08:23 PM, Dave Airlie wrote:
> Hi,
>
> So I've been hacking on mutter and the gnome pieces for tiling, and
> I've at least fixed mutter locally so maximise windows works and the
> heads are in the right order.
>
> Now I've strung all the pieces together using a single KMS property
> t
Hi Dave,
A few more small fixes for 3.18.
The following changes since commit 8b62c8c6df08ca567c78afa51aa7bbc554cede06:
nouveau: move the hotplug ignore to correct place. (2014-12-02 16:27:25 +1000)
are available in the git repository at:
git://people.freedesktop.org/~agd5f/linux drm-fixes-
Rockchip RK3288 hdmi is compatible with dw_hdmi
this patch is depend on patch by Mark Yao Add drm
driver for Rockchip Socs
see https://lkml.org/lkml/2014/11/19/1153
Signed-off-by: Andy Yan
---
Changes in v15:
- remove THIS_MODULE in platform driver
Changes in v14: None
Changes in v13: None
C
Signed-off-by: Andy Yan
---
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8:
- Add documentation for rockchip dw hdmi
Changes in v7: None
Changes in v6: None
Changes in v5: None
Chang
RK3288 HDMI will not work without the spare bit of
HDMI_PHY_CONF0 enable
Signed-off-by: Andy Yan
---
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes i
HDMI_IH_I2CMPHY_STAT0 is a clear on write register, which indicates i2cm
operation status(i2c transfer done or error), every hdmi phy register
configuration must check this register to make sure the configuration
has complete. But the indication bit should be cleared after check, otherwise
the corr
some platform may not support all the display mode,
add mode_valid interface check it
Signed-off-by: Andy Yan
---
Changes in v15: None
Changes in v14:
- remove drm_connector_register, because imx-drm core has registered
connector
Changes in v13: None
Changes in v12: None
Changes in v11: None
C
On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers. Byte width accesses (writeb,
readb) generate an imprecise external abort.
Signed-off-by: Andy Yan
---
Changes in v15:
- remove unio of the multi-byte register access, adviced by Philipp Zabel
Changes in v14: None
Signed-off-by: Andy Yan
---
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description
Changes in v7: None
Changes
the original imx hdmi driver is under drm/imx/,
which depends on imx-drm, so move the imx hdmi
driver out to drm/bridge and rename it to dw_hdmi
Signed-off-by: Andy Yan
---
Changes in v15:
- add prefix dw_hdmi/DW_HDMI for public used dw_hdmi structs
adviced by Philipp Zabel
- remove THIS_MODU
hdmi phy configuration is platform specific, which can be adusted
according to the board to get the best SI
Signed-off-by: Andy Yan
---
Changes in v15: None
Changes in v14: None
Changes in v13:
- split phy configuration from patch#4
Changes in v12: None
Changes in v11: None
Changes in v10: Non
IMX6 and Rockchip RK3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly differences, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.
To reuse the imx
drm driver may probe before the i2c bus, so the driver should
defer probing until it is available
Signed-off-by: Andy Yan
Reviewed-by: Daniel Kurtz
---
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12:
- refactor of_node_put(ddc_node)
Changes in v11: None
Changes
CHECK: Alignment should match open parenthesis
+ if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
+ (hdmi->vic == 12) || (hdmi->vic == 13) ||
CHECK: braces {} should be used on all arms of this statement
+ if (hdmi->hdmi_data.video_mode.mdvi)
[...]
+ else {
[...]
Sign
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 differences, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only be access
Hi Dave,
Ok, updated pull request with the embarrassing compile noise I've
completely forgotten about taken care of.
drm-intel-next-2014-11-21:
- infoframe tracking (for fastboot) from Jesse
- start of the dri1/ums support removal
- vlv forcewake timeout fixes (Imre)
- bunch of patches to polish
://lists.freedesktop.org/archives/dri-devel/attachments/20141202/3b413e0b/attachment.sig>
"live"/mobile gnu/linux distro ready (need
to code a few more components).
--
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
Hello Ben Goz,
The patch 241f24f82363: "amdkfd: Add packet manager module" from Jul
17, 2014, leads to the following static checker warning:
drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c:357
pm_send_set_resources()
error: potentially using uninitialized 'packet'.
drivers/gpu/d
On Tue, Dec 2, 2014 at 1:47 PM, Sean Paul wrote:
> On Wed, Nov 26, 2014 at 4:19 PM, Rob Clark wrote:
>> Keep property pointer, instead of id, in per mode-object attachments.
>> This will simplify things in later patches.
>>
>> ---
>> Does anyone care about the lifetime issue and dangling property
Hi Andy,
Am Dienstag, den 02.12.2014, 20:34 +0800 schrieb Andy Yan:
> Hi Philipp:
> On 2014å¹´12æ02æ¥ 18:24, Philipp Zabel wrote:
> > Hi Andy,
> >
> > Am Dienstag, den 02.12.2014, 15:45 +0800 schrieb Andy Yan:
> > [...]
> >> +static int dw_hdmi_rockchip_bind(struct device *dev, struct device
>
On 27 November 2014 at 17:01, Mark yao wrote:
> Hi Dave
>
> this pull request is for rockchip drm v14, based on Joerg's iommu
> arm/rockchip branch.
>
> The following changes since commit 656d7077d8ffd1c2492d4a0a354367ab2e545059:
>
> dt-bindings: iommu: Add documentation for rockchip iommu (
From: Martin Bugge
Use the new logging functions from the hdmi module.
Signed-off-by: Martin Bugge
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/Kconfig | 1 +
drivers/media/i2c/adv7842.c | 174
2 files changed, 47 insertions(+), 128 deleti
From: Martin Bugge
When receiving video it is very useful to be able to unpack the InfoFrames.
Logging is useful as well, both for transmitters and receivers.
Especially when implementing the VIDIOC_LOG_STATUS ioctl (supported by many
V4L2 drivers) for a receiver it is important to be able to ea
From: Hans Verkuil
Add new Video InfoFrame colorspace information introduced in HDMI 2.0
and new Audio Coding Extension Types, also from HDMI 2.0.
HDMI_CONTENT_TYPE_NONE was renamed to _GRAPHICS since that's what
it is called in CEA-861-F.
Signed-off-by: Hans Verkuil
Reviewed-by: Thierry Redin
This patch series adds new HDMI 2.0/CEA-861-F defines to hdmi.h and
adds unpacking and logging functions to hdmi.c. It also uses those
in the V4L2 adv7842 driver (and they will be used in other HDMI drivers
once this functionality is merged).
Patches 2 and 3 have been posted before by Martin Bugge
On Mon, Dec 1, 2014 at 3:51 PM, Jilai Wang wrote:
> Add HDCP related register description.
>
> Signed-off-by: Jiali Wang
> ---
> drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 76
> +
> 1 file changed, 60 insertions(+), 16 deletions(-)
>
This one I'll just drop and r
On Tue, Dec 2, 2014 at 10:46 AM, Rob Clark wrote:
> We had _power_up(), but drivers also need to be able to power down.
>
> Signed-off-by: Rob Clark
Reviewed-by: Alex Deucher
> ---
> This lets me drop edp_sink_power_state() from msm eDP code, and use
> the helpers instead.
>
> drivers/gpu/drm
On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar wrote:
> Currently, third party bridge drivers(ptn3460) are dependent
> on the corresponding encoder driver init, since bridge driver
> needs a drm_device pointer to finish drm initializations.
> The encoder driver passes the drm_device pointer to the
>
Hi Andy,
Am Dienstag, den 02.12.2014, 15:45 +0800 schrieb Andy Yan:
[...]
> +static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + const struct dw_hdmi_pl
st one time thing or only
happened with older kernels.
--
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/20141202/47eb1b89/attachment.html>
On 29 November 2014 at 00:22, Daniel Vetter wrote:
> On Fri, Nov 28, 2014 at 02:30:45PM +0100, Daniel Vetter wrote:
>> Hi Dave,
>>
>> As discussed on irc here's the slightly late (because our QA cycle was a
>> bit misaligned) final feature pull request for 3.19. I have a few fixes to
>> sort out i
On Wed, Nov 26, 2014 at 4:19 PM, Rob Clark wrote:
> Keep property pointer, instead of id, in per mode-object attachments.
> This will simplify things in later patches.
>
> ---
> Does anyone care about the lifetime issue and dangling property ptrs?
Judging by the lack of response, it seems like th
We had _power_up(), but drivers also need to be able to power down.
Signed-off-by: Rob Clark
---
This lets me drop edp_sink_power_state() from msm eDP code, and use
the helpers instead.
drivers/gpu/drm/drm_dp_helper.c | 31 +++
include/drm/drm_dp_helper.h | 1 +
Hi Inki,
Can you please review this? I also have sent other two patch sets that sits on
top of this one. Thanks.
Gustavo
2014-11-24 Gustavo Padovan :
> From: Gustavo Padovan
>
> Hi Inki,
>
>
Hi Mark,
Am Dienstag, 2. Dezember 2014, 17:13:20 schrieb Mark Yao:
> This a series of patches is a DRM Driver for Rockchip Socs, add support
> for vop devices. Future patches will add additional encoders/connectors,
> such as eDP, HDMI.
>
> The basic "crtc" for rockchip is a "VOP" - Video Output
On 01/12/14 15:28, Daniel Vetter wrote:
> On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote:
>> Hi,
>>
>> We are currently in negotiations with one of our customers (Mediatek) on
>> a strategy that will allow them to push a DRM modesetting driver into
>> the upstream kernel. We are writin
Hello Kukjin,
On Mon, Nov 24, 2014 at 6:41 AM, Vivek Gautam
wrote:
> DP PHY now require pmu-system-controller to handle PMU register
> to control PHY's power isolation. Adding the same to dp-phy
> node.
>
> Signed-off-by: Vivek Gautam
> Reviewed-by: Jingoo Han
> Tested-by: Javier Martinez Cani
On Tue, Dec 02, 2014 at 11:02:59AM +1000, Dave Airlie wrote:
> On 29 November 2014 at 00:22, Daniel Vetter wrote:
> > On Fri, Nov 28, 2014 at 02:30:45PM +0100, Daniel Vetter wrote:
> >> Hi Dave,
> >>
> >> As discussed on irc here's the slightly late (because our QA cycle was a
> >> bit misaligned)
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141202/e52ddc78/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/716c4abe/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/132d88b2/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/2b4f0550/attachment-0001.html>
This codepath is mostly hit when rebinding after a backup buffer swapout. It's
amazing that this error hasn't been more obvious but probably the shaders are
not reread from guest memory that often..
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Reviewed-by: Sinclair Yeh
---
dr
The commit "vmwgfx: Rework fence event action" introduced a number of bugs
that are fixed with this commit:
a) A forgotten return stateemnt.
b) An if statement with identical branches.
Cc:
Reported-by: Rob Clark
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Reviewed-by: Sincl
Kernel side fence objects are used when unbinding resources and may thus be
created as part of a memory reclaim operation. This might trigger recursive
memory reclaims and result in the kernel running out of stack space.
So a simple way out is to avoid accounting of these fence objects.
In princip
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/89bfa312/attachment-0001.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/d02a856d/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141202/668323be/attachment.html>
68 matches
Mail list logo
