This patch seprates the code, which sorts proprty sets and eliminates
duplicate properties, from drmModeAtomicCommit(). Now
drmModeAtomicCleanup() has to do the job before calling
drmModeAtomicCommit(), and drmModeAtomicCommit() just converts the cleaned
request to IOCTL argument.
Signed-off-by: H
This patch removes the trailing white spaces.
Signed-off-by: Hyungwon Hwang
---
xf86drmMode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index fc19504..d4ed5c1 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -879,7 +879,7 @@ int drmHan
This patch removes the trailing white spaces.
Signed-off-by: Hyungwon Hwang
---
tests/modetest/modetest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 4eb9eac..43bd06f 100644
--- a/tests/modetest/modetest.c
++
This patch adds support for atomic modeset. Using -a option, user can
make modeset to use DRM_IOCTL_MODE_ATOMIC instead of legacy IOCTLs.
Also, by using -W option, user can set the value of each object's property.
Signed-off-by: Hyungwon Hwang
---
tests/modetest/modetest.c | 237
This patch adds support for atomic page flip. User can specify -W option
with the plane id for testing atomic page flipping.
Signed-off-by: Hyungwon Hwang
---
tests/modetest/modetest.c | 150 +-
1 file changed, 147 insertions(+), 3 deletions(-)
diff -
This patch makes 'struct _drmModeAtomicReqItem' and 'struct
_drmModeAtomicReq' visible from outside. This is needed for userspace
applications to use those structures when calling drmModeAtomicCommit().
Signed-off-by: Hyungwon Hwang
---
xf86drmMode.c | 14 --
xf86drmMode.h | 12 +
https://bugzilla.kernel.org/show_bug.cgi?id=95911
--- Comment #21 from Michel Dänzer ---
(In reply to Alex Deucher from comment #20)
> Does this help?
I'm afraid you're wasting your time here, since the bug reporter refuses to
build a kernel for testing fixes. Anyway, FWIW:
> diff --git a/dri
https://bugzilla.kernel.org/show_bug.cgi?id=95911
--- Comment #22 from Michel Dänzer ---
(In reply to Michel Dänzer from comment #21)
> The freeze callback change makes sense to me, but the thaw callback should
> probably enable the device, not disable it?
Never mind, I misread the patch.
--
On 19.08.2015 06:58, Marek Olšák wrote:
> From: Marek Olšák
>
> Signed-off-by: Marek Olšák
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/am
Hi,
On 06/30/2015 10:54 AM, Archit Taneja wrote:
> We are currently restricted when it comes to supporting DSI on devices
> that have a non-DSI control bus. For example, DSI encoder chips are
> available in the market that are configured via i2c. Configuring their
> registers via DSI bus is either
ves/dri-devel/attachments/20150819/f8cab483/attachment.html>
On 06/30/2015 07:24 AM, Archit Taneja wrote:
> We can have devices where the data bus is MIPI DSI, but the control bus
> is something else (i2c, spi etc). A typical example is i2c controlled
> encoder bridge chips.
>
> Such devices too require passing DSI specific parameters (number of data
> lanes
David,
Please incorporate the latest Synopsis DesignWare HDMI driver development
updates, which can be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-dwhdmi-devel
with SHA1 6dc2e1bf8e0025db2ff8a35ee3e0bd88203d4402.
This is a re-send of the original pull request from the 15th July
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #38 from Hans de Goede ---
Ping, what is the status on this ? With 2 positive test results for the patch
it would be good to get this into 4.1.x ...
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 06/30/2015 07:24 AM, Archit Taneja wrote:
> mipi_dsi_devices are inherently aware of their host because they
> share a parent-child hierarchy in the device tree.
>
> Non-dsi drivers that create a dummy dsi device don't have this data.
> In order to get this information, they require to a phandle
On Tue, Aug 18, 2015 at 05:41:59PM +0100, Emil Velikov wrote:
> On 17 August 2015 at 16:15, Liviu Dudau wrote:
> > On Sun, Aug 16, 2015 at 09:56:33AM +0100, Emil Velikov wrote:
> >> Hi Liviu,
> >
> > Hi Emil,
> >
> >>
> >> On 5 August 2015 at 15:28, Liviu Dudau wrote:
> >> > The HDLCD controller
Hi,
On 08/19/2015 01:40 PM, Andrzej Hajda wrote:
> On 06/30/2015 07:24 AM, Archit Taneja wrote:
>> We can have devices where the data bus is MIPI DSI, but the control bus
>> is something else (i2c, spi etc). A typical example is i2c controlled
>> encoder bridge chips.
>>
>> Such devices too requir
On Mon, Aug 17, 2015 at 07:17:53PM +0100, Jon Medhurst (Tixy) wrote:
> I haven't reviewed the code in detail, just had one comment I alluded to
> in a private email the other day...
>
> On Wed, 2015-08-05 at 15:28 +0100, Liviu Dudau wrote:
>
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
> >
Exynos DRM reported that all planes for all supported sub-devices supports
only three pixel formats: XRGB24, ARGB24 and NV12. This patch lets each
Exynos DRM sub-drivers to provide the list of supported pixel formats
and registers this list to DRM core.
Signed-off-by: Marek Szyprowski
---
driver
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150819/244046b8/attachment.sig>
lds/linux.git/commit/?id=67ba31d3528e2460b2243b2d139b70fa479602e8
--
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/20150819/2b594ca0/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150819/b640ffa9/attachment.html>
Hmm,
this looks a lot like my patch from some time ago:
http://www.spinics.net/lists/linux-samsung-soc/msg43677.html
With best wishes,
Tobias
Marek Szyprowski wrote:
> Exynos DRM reported that all planes for all supported sub-devices supports
> only three pixel formats: XRGB24, ARGB24 and NV12.
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #39 from Alex Deucher ---
Already in 4.2:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d0ea397e22f9ad0113c1dbdaab14eded050472eb
and 4.1:
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/c
Adding Jérôme to Cc. I think he looked the userptr code before, so maybe
he has some idea what is going wrong here.
I also had a look at the code, but my knowledge about the DMA API is
almost nonexistant. However I can see that before doing any DMA via the
G2D on the buffer the code calls dma_ma
https://bugzilla.kernel.org/show_bug.cgi?id=93701
Hans de Goede changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Aug 19, 2015 at 03:53:44PM +0200, Tobias Jakobi wrote:
> Adding Jérôme to Cc. I think he looked the userptr code before, so maybe
> he has some idea what is going wrong here.
>
> I also had a look at the code, but my knowledge about the DMA API is
> almost nonexistant. However I can see
Hi Thierry, Archit,
Am Mittwoch, den 19.08.2015, 15:13 +0200 schrieb Thierry Reding:
> On Wed, Aug 19, 2015 at 10:37:54AM +0530, Archit Taneja wrote:
> > Hi,
> >
> > On 06/30/2015 10:54 AM, Archit Taneja wrote:
> > >We are currently restricted when it comes to supporting DSI on devices
> > >that
erface), you don't have
anything to glue together with an OF graph.
> Multiple device drivers in both the media and DRM universe have shown
> that they are a working way to represent those data bus connections
> between devices.
> I know this might make things a bit more complicated for Tegra DRM,
> where you have a nice parent<->child relationship between the components
> even on the control path so far, but we should really move into the
> direction of more drivers using the standardized bindings for this
> stuff, instead of doing another round of NIH.
Why are you bringing up Tegra DRM? I don't see how it's relevant in any
way to this discussion.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150819/d7b14ace/attachment-0001.sig>
On Wed, Aug 19, 2015 at 10:08 AM, Jerome Glisse wrote:
> On Wed, Aug 19, 2015 at 03:53:44PM +0200, Tobias Jakobi wrote:
>> Adding Jérôme to Cc. I think he looked the userptr code before, so maybe
>> he has some idea what is going wrong here.
>>
>> I also had a look at the code, but my knowledge
Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
> On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
> > Hi Thierry, Archit,
> >
[...]
> > > Perhaps a better way would be to invert this relationship. According to
> > > your proposal we'd have to have DT like this:
> > >
y device is the least desirable solution. But
> if there is only one control bus to the device I think it should be one
> device sitting beneath the control bus.
>
> You can then use of-graph to model the data path between the DSI encoder
> and device.
But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to
hook up with a control endpoint. And then you'll need more quirks
to describe what kind of DSI device this is.
On the other hand if you properly instantiate the DSI device you can
easily write a driver for it, and the driver will set up the correct
properties as implied by the compatible string. Once you have that you
can easily hook it up to the I2C control interface in whatever way you
like, be that an OF graph or just a simple unidirectional link by
phandle.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150819/4bc013f7/attachment.sig>
On Wed, 19 Aug 2015, Thierry Reding wrote:
> On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
>> Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
>> > I think that's a flawed interpretation of what's going on here. The
>> > device in fact has two interfaces: one is I2C,
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/20150819/7c7dab01/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150819/31a72946/attachment-0001.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/20150819/8bdc04d0/attachment.html>
On Tue, Aug 18, 2015 at 11:59 PM, Michel Dänzer wrote:
> On 19.08.2015 06:58, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> Signed-off-by: Marek Olšák
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/g
https://bugzilla.kernel.org/show_bug.cgi?id=102401
--- Comment #6 from Alex Deucher ---
(In reply to Maxqia from comment #5)
> Replacing drm_detect_monitor_audio(radeon_connector_edid(connector)) with
> true seems to fix the problem.
This means the EDID from your monitor claims not to support au
(()()
On Tue, Apr 7, 2015 at 2:09 PM, Jilai Wang wrote:
> Add writeback support in msm kms framework.
> V1: Initial change
> V2: Address Rob/Paul/Emil's comments
>
> Signed-off-by: Jilai Wang
> ---
> drivers/gpu/drm/msm/Kconfig | 10 +
> drivers/gpu/drm/msm/Makefile
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150819/f33d4b8a/attachment.html>
So the issues that Inki and Bjorn ran into with ww_acquire_fini() vs
legacy fbdev codepaths (like restore_fbdev_mode() and pan_display())
would be solved by using a single atomic update for these cases. So
I hacked up a prototype.
(disclaimer, these are completely untested hacked-up-between-sessi
Somewhat rough, not sure if some of the code should be moved to
different places, etc..
Only compile tested atm..
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic_helper.c | 129 +---
drivers/gpu/drm/drm_fb_helper.c | 74 +
include
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_fb_helper.c | 59 +
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3549b1f..eef1687 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/d
Since this already confused me once when adding addfb2.1, let's clean up
the header to split params one per line.
Signed-off-by: Rob Clark
---
include/uapi/drm/drm_mode.h | 42 ++
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/include/uapi
On Wed, Aug 19, 2015 at 7:21 PM, Rob Clark wrote:
> Since this already confused me once when adding addfb2.1, let's clean up
> the header to split params one per line.
>
> Signed-off-by: Rob Clark
Reviewed-by: Alex Deucher
> ---
> include/uapi/drm/drm_mode.h | 42 +
Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
control
After run "checkpatch.pl -f --subjective" command, I see there
are lots of alignment problem in exynos_dp driver, so let just
fix them.
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
avoid using some uncommo
Hi Eric,
Am 18.08.2015 um 23:54 schrieb Eric Anholt:
> VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
> other Broadcom SoCs.
>
> This binding follows the model of msm, imx, sti, and others, where
> there is a subsystem node for the whole GPU, with nodes for the
> individual
me limites about
those
that RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, which
means 5.4Gbps
link rate is too high for RK3288.
So I think we could treate them as hardware max values, is it okay?
Thanks,
- Yakir
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150819/29017b21/attachment-0001.html>
In order to move exynos dp code to bridge directory,
we need to convert driver drm bridge mode first. As
dp driver already have a ptn3460 bridge, so we need
to move ptn bridge to the next bridge of dp bridge.
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Take Jingoo Han sugge
Split the dp core driver from exynos directory to bridge
directory, and rename the core driver to analogix_dp_*,
leave the platform code to analogix_dp-exynos.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Thierry Reding suggest, move exynos's video_timing code
to analogix_dp-exynos platf
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relaies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Signed-off-by: Yaki
link_rate and lane_count already configed in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbp
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 binding documents.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Heiko suggest
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Heiko suggest, add rockchip dp phy driver,
collect the phy clocks and power control.
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 +++
drivers/phy/Kconfig| 7 +
drivers/phy/Ma
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Add GNU license v2 declared and samsung copyright
drivers/gpu/drm/exynos/analogix_dp-exynos.c | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 +
include/drm/bridge/analogix_dp.h| 16 ++
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Add "analogix,need-force-
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
dp phy driver which na
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error
drivers/gpu/drm/bridge/analogix_dp_reg.c | 76 -
Some edp screen with no hpd signal would need some delay time
to ensure that screen would be ready for work, so we can expand
the delay time in hpd detect function, it works prefectly on my
rk3288 sdk board.
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/b
Signed-off-by: Yakir Yang
---
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Add edid modes parse support
Changes in v2: None
drivers/gpu/drm/
ed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150819/03b0ffc6/attachment.sig>
Hi Eric,
only a few nits.
Am 18.08.2015 um 23:54 schrieb Eric Anholt:
> This is the start of a full VC4 driver. Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is). However
Hi Dave,
On 08/19/2015 06:54 PM, Dave Airlie wrote:
> On 20 August 2015 at 00:48, Yakir Yang wrote:
>> Hi all,
>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>> share the same IP, so a lot of parts can be re-used. I split the common
>> code into bridge directory, then
On Wed, Aug 19, 2015 at 7:36 PM, Dave Airlie wrote:
>> Hi Dave,
>>
>> Warnings are fixed. The pull request...
>
> Close but no cigar,
>
>
> CC [M] drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c:
> In function âfsl_dcu_d
On 07/16/2015 01:27 AM, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 11:14:43PM +0200, Daniel Vetter wrote:
>> On Thu, Jul 09, 2015 at 01:15:34PM +1000, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> This really doesn't seem to have much chance of working anymore,
>>>
>>> esp for irq context,
67 matches
Mail list logo
