).
While there also switch to doing prepare and enable in one step rather
then separate steps to reduce the amount of code required.
Signed-off-by: Sjoerd Simons
Acked-by: Mark Yao
Tested-by: Yakir Yang
Tested-by: Romain Perier
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36
rockchip_drm_gem.o
> + rockchip_drm_gem.o rockchip_drm_vop.o
> Â
> Â obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> Â
> -obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o \
> - rockchip_vop_reg.o
> +obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
--
Sjoerd Simons
Collabora Ltd.
e calls to MODULE_DEVICE_TABLE
in one module, however commit 21bdd17b21b45ea solved that.
The first two patches revert the previous removals of MODULE_DEVICE_TABLE
calls, while the last one adds calls for the remaining OF match tables without a
MODULE_DEVICE_TABLE call.
Sjoerd Simons (3):
Revert "drm/exy
21bdd17b21b45ea48e06e23918d681afbe0622e9 it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_fimd.c
drivers/gpu/drm/exynos/exynos_drm_g2d.c
Signed-off-by: Sjoerd Simons
---
drivers/gpu/drm
Add MODULE_DEVICE_TABLE calls for the various OF match tables that
currently don't have one. This allows the module to be
autoloaded based on devicetree information.
Signed-off-by: Sjoerd Simons
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c| 1 +
drivers/gpu/drm/exynos/exynos_drm_rota
the patch can be
reverted to restore support for autoloading
Signed-off-by: Sjoerd Simons
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm
Hey Inki,
On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote:
> On 2014? 07? 19? 05:36, Sjoerd Simons wrote:
> > The exynos DRM module currently is not automatically loaded when build as a
> > module. This is due to the simple fact that it doesn't have any
> > M
Hey Inki,
On Mon, 2014-07-21 at 08:50 +0200, Sjoerd Simons wrote:
> Hey Inki,
>
> On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote:
> > On 2014? 07? 19? 05:36, Sjoerd Simons wrote:
> > > The exynos DRM module currently is not automatically loaded when build as
> >
Hey Inki,
On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote:
> On 2014? 07? 28? 17:30, Sjoerd Simons wrote:
> Sorry for late,
>
> I don't see why Exynos drm driver should be auto-loaded module. I think
> all devices covered by Exynos drm framework are not hot-plugged. Maybe
&
On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote:
> On 2014? 07? 28? 23:45, Sjoerd Simons wrote:
> > Hey Inki,
> >
> > On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote:
> >> On 2014? 07? 28? 17:30, Sjoerd Simons wrote:
> >> Sorry for late,
> >>
On Thu, 2014-11-06 at 23:10 +0900, Inki Dae wrote:
> This patch resovles the infinite loop issue incurred
> when Exyno drm driver is enabled but all kms drivers
> are disabled on Exynos board by returning -EPROBE_DEFER
> only in case that there is kms device registered.
It would be nice if you cou
On Tue, 2014-11-18 at 12:20 +0900, Inki Dae wrote:
> This patch makes the deferred probe is tried up to 3 times in maximum.
> However, this is considered only for Exynos drm so I think other SoC
> drivers could also produce same issue. Therefore, the best way to resolve
> this issue, infinite loop
Playing a bit with todays linux-next on my jetson, it seems this patch is
still required for enabling the GPU. Is there anything blocking it (firmware
not available yet in liux-firmware?)
On Mon, May 19, 2014 at 06:24:10PM +0900, Alexandre Courbot wrote:
> Signed-off-by: Alexandre Courbot
> ---
>
On Thu, 2014-09-25 at 18:41 +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> > On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> > >Playing a bit with todays linux-next on my jetson, it seems this patch is
> > >still requir
).
While there also switch to doing prepare and enable in one step rather
then separate steps to reduce the amount of code required.
Signed-off-by: Sjoerd Simons
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 +++--
1 file changed, 14 insertions(+), 22 deletions
On Tue, 2015-09-29 at 18:58 +0800, Yakir Yang wrote:
>
> On 09/29/2015 05:55 PM, Yakir Yang wrote:
> >
> >
> > On 09/29/2015 05:28 PM, Sjoerd Simons wrote:
> > > When doing the initial setup both the hclk and the aclk need to
> > > be
> > >
+0x58/0xa8)
[2.917976] r9: r8:c0a1cca4 r7:c0a71a48 r6:c0a1cca4 r5:ef1dc610
r4:c0440b80
Adjust the code to only unwind as necessary on probe failures
Signed-off-by: Sjoerd Simons
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 32 +---
1 file changed, 25
During probe there may not be any connectors yet if e.g. the panel
failed or hasn't been probed yet. I hitting this in practice the panels
probing was being delayed due to using a gpio backlight.
Fix this by returning -EPROBE_DEFER so the probing will be retried.
Signed-off-by: Sjoerd S
This box claims to have an LVDS interface but doesn't
actually have one.
Signed-off-by: Sjoerd Simons
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 08
This box claims to have an LVDS interface but doesn't
actually have one.
Signed-off-by: Sjoerd Simons
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 08
t; easier
> for us.
Tested on a Radxa Rock 2 square board.
Tested-By: Sjoerd Simons
> Fixes WARN present since cc1ef118fc for every pageflip event sent:
> [Â Â 209.549969] [ cut here ]
> [Â Â 209.554592] WARNING: CPU: 3 PID: 238 at
> drivers/gpu/drm/drm_irq.c:9
n this hardware while before it would get stuck
right away for the reasons pointed out by daniels
Tested-by: Sjoerd Simons
> Signed-off-by: Daniel Stone
> Cc: Sjoerd Simons
> Cc: Heiko Stuebner
> ---
> Â drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 30 ++-
> -
gle Tested-by on this series and that seems to be with a
> > bunch of out-of-tree patches applied on top. Does this now actually work
> > applied on top of upstream? Also it seems like many people actually want
> > this to get merged but there's been no Reviewed-bys and only
dpi0 {
> + pinctrl-0 = <&dpi_default_pins>;
> + pinctrl-1 = <&dpi_idle_pins>;
> + pinctrl-names = "default", "sleep";
Would be good to document that these pins clash with ethernet support,
similar to what is done in the ethernet node. Also some notes on what
nodes to enable/disable when selecting either ethernet or hdmi output
would be appreciated :)
--
Sjoerd Simons
Collabora
24 matches
Mail list logo
