An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/a9d38f9a/attachment.html>
attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/5f5de183/attachment.sig>
archives/dri-devel/attachments/20141117/8ab2dcb9/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/901c56bf/attachment-0001.html>
ving both choices on hand)
--
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/20141117/01d0880a/attachment.html>
ou're using.
--
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/20141117/4fa294fd/attachment.html>
+0900
radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
--
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/20141117/cc4f1
+0900
radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
--
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/20141117/07dda
On Sat, 15 Nov 2014, Nicholas Krause wrote:
> Changes the calls of mdelay to msleep in the driver file
> mdfld_dsi_pkg_sender.c
> in order to prevent CPU busy looping in order to save CPU cycles as this is
> considered bad form over sleeping the CPU for high resolution timer function
> calls as t
Hi Inki,
This patchset embed all remaining exynos_drm framework objects into driver
private
context, thanks to this global variables can be removed and the code can be
simplified.
It continues refactoring started by dsi related patchset [1].
I have tested it on trats and universal boards with f
The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --gi
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to vidi private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multi
The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multi
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multi
The patch replaces accesses to manager->ctx pointer by container_of
construct. As fimd was the last user of ctx the patch removes
this field as well.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 40 ++
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gp
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to hdmi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possib
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to vidi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possib
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/dr
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dp
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers
The patch replaces accesses to display->ctx pointer by container_of
construct. The field is removed as well as dpi was the last user of it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
2 files changed, 2 insert
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dpi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possibl
On Sun, 16 Nov 2014, Stefan Brüns wrote:
This needs a rationale for its existence here.
You could also use the function in drm_edid_block_valid to not duplicate
the code.
BR,
Jani.
> Signed-off-by: Stefan Brüns
> ---
> drivers/gpu/drm/drm_edid.c | 11 +++
> 1 file changed, 11 inser
On Sun, 16 Nov 2014, Stefan Brüns wrote:
> 4a638b4e38234233f5c7e6705662fbc0b58d80c2 disabled the checksumming
Please include the subject of the referenced commit, e.g.
4a638b4e3823 drm/edid: Allow non-fatal checksum errors in CEA blocks
or
commit 4a638b4e38234233f5c7e6705662fbc0b58d80c2
Autho
On Sun, 16 Nov 2014, Stefan Brüns wrote:
> drm_edid_block_valid will dump the whole EDID block. Shorten the log
> output to a single line stating the block is empty.
I'd think it would be better to teach drm_edid_block_valid to better
handle empty blocks.
BR,
Jani.
>
> Signed-off-by: Stefan Br
On 15.11.2014 07:21, Andy Lutomirski wrote:
> I have a Caicos card, like this:
>
> [3.077260] [drm] radeon kernel modesetting enabled.
> [3.077338] checking generic (e000 60) vs hw (e000 1000)
> [3.077339] fb: switching to radeondrmfb from EFI VGA
> [3.077377] Consol
-
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/20141117/617568d8/attachment.html>
Commit f9b9faf6d94dd29eab8c128905c7d091f955481d "drm: flip-work: change
drm_flip_work_init prototype" changed the drm_flip_work_init prototype
to a void function, which makes 'ret' an unused variable.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/omapdrm/omap_plane.c | 1 -
1 file changed,
https://bugzilla.kernel.org/show_bug.cgi?id=83461
--- Comment #21 from Christian König ---
(In reply to kb from comment #20)
> Hi, unfortunately supplied patch does not fix the issue. Do you need some
> more debug output?
dmesg output generated with drm.debug=0xE on the kernel command line woul
This function is valid only the SoC has SHADOWCON register
and it should be used together with fimd_enable_video_output()
to match the ENWIN_F bit in WINCON# and C#_EN_F bit in SHADOWCON.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_d
Hi,
This series modifies LCD I80 interface display for Exynos DRM driver
to make it similar with Video(RGB) interface.
Some patches in v1 are applied already and these are modified as Inki's
comments.
And Joonyoung's patches are also included for merge convenience.
This is based on exynos-drm-nex
From: Joonyoung Shim
It's better to be checking whether triggerring in fimd_trigger function.
Also it will return if in triggerring on fimd_te_handler, then it can't
execute remain codes.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
1 file cha
The C#_EN_F in SHADOWCON register is updated per frame.
So it should be protected by fimd_shadow_protect_win().
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
This bit is used for video output and logic signal control.
So it is better for readability.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
For the I80 interface, the video interrupt pending register(VIDINTCON1)
should be handled in fimd_irq_handler() and the video interrupt control
register(VIDINTCON0) should be handled in fimd_enable_vblank() and
fimd_disable_vblank() like RGB interface.
So this patch moves each set / unset routines
There is a case like set config which requires triggering
but vblank is not enabled yet.
So triggering unset routine is required to exit from
triggering mode.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 +++
1 file
From: Joonyoung Shim
The drm_handle_vblank should be called whenever be vsync, te interrupt
means vsync on i80 interface.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ex
The drm_helper_hpd_irq_event() does dpms control and
the panel is initialized and displayed on by it.
So the exynos_dsi_te_irq_handler() should be registered
beforehand.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +++--
The exynos_dsi_te_irq_handler() works only dsi(DPMS) is on.
So it is enough to enable and disable TE GPIO IRQ in
exynos_dsi_enable(disable)_irq() like DSI IRQ.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae a
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 +
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/1189521b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/057e2fc1/attachment.html>
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/f8b2b079/attachment.html>
560e0fad42aa982965fc2 hawaii_smc.bin
libclc: Git:master/7f6f5bff1f
DDX: 1:7.5.0-1
--
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/20141117/97a3a3c8/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/20141117/89f48245/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/fd14e642/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=85491
--- Comment #14 from Marek ---
I can try, but this will be the first time I am going to do this. I have read
this article: https://wiki.ubuntu.com/Kernel/KernelBisection and I am going to
proceed accordingly.
--
You are receiving this mail becau
On Monday, November 17, 2014 11:08:48 Jani Nikula wrote:
> On Sun, 16 Nov 2014, Stefan Brüns wrote:
> > 4a638b4e38234233f5c7e6705662fbc0b58d80c2 disabled the checksumming
>
> Please include the subject of the referenced commit, e.g.
>
> 4a638b4e3823 drm/edid: Allow non-fatal checksum errors in
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/eb474e3b/attachment.html>
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/20141117/d84c8064/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/9c2f6783/attachment-0001.html>
On 17.11.2014 16:57, Kevin Hilman wrote:
> FYI...
>
> Various new exynos5 boot failures starting next-20141117. Looking in
> the boot logs, the boot stops during DRM initialization.
>
> Note that the boot failures are only on exynos_defconfig, and not
> multi_v7_defconfig.
On Sat, Nov 15, 2014 at 6:59 PM, Kai Wasserbäch
wrote:
> Kai Wasserbäch wrote on 15.11.2014 22:22:
>> Kai Wasserbäch wrote on 15.11.2014 16:33:
>>> Is there anything besides a bisect you would need to debug this?
>>
>> Ok, I did a bisection, but that time was wasted for sure. My "first bad
>>
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/20141117/a73b73d4/attachment.html>
archives/dri-devel/attachments/20141117/b25962aa/attachment.html>
faces again.
[0] <http://thread.gmane.org/gmane.comp.video.dri.devel/118415>
--
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/20141117/b825e2a8/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/8d0b63db/attachment-0001.html>
The core clock rate depends on the hw configuration. Once we have
read the hardware revision, we can set the core clock to its
maximum value.
Before then, the clock is set at a rate supported by all MDP5
revisions.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 9
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/cf0f1eeb/attachment.html>
radeon driver
> so you end up with vesa or efifb or some other platform driver rather than
> the native driver.
Makes sense, thanks!
--
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/20141117/fb4f8032/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/27b3c3a3/attachment.html>
: Modeline "1280x1024"x0.0 108.00 1280 1328 1440
1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[This entire block is repeated more than 100 times]
--
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/20141117/72508547/attachment.html>
esa 10.2.9
Kernel 3.16.5, 3.17.2, 3.18-rc5
radeon-ucode-20140823
--
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/20141117/54ac53a3/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/20141117/c17da450/attachment.html>
For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the
mdp block. In order to decouple hdmi/eDP/etc, register an irq domain
in mdp5. When hdmi/dsi/etc are used with mdp4, they can directly setup
their irqs in their DT nodes as normal. When used with mdp5, instead
set the mdp devi
ng 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/20141117/24a086ea/attachment.html>
esktop.org/archives/dri-devel/attachments/20141117/5f381115/attachment.html>
put of a bad
configuration.
--
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/20141117/0fbc63d4/attachment.html>
On Mon, Nov 17, 2014 at 1:39 PM, Stephane Viau wrote:
> The core clock rate depends on the hw configuration. Once we have
> read the hardware revision, we can set the core clock to its
> maximum value.
> Before then, the clock is set at a rate supported by all MDP5
> revisions.
>
> Signed-off-by:
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/9a5c27ec/attachment.html>
cc78a66c54d684635f69a358fd54f65929 M src
--
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/20141117/6d9c2594/attachment-0001.html>
Dave, any objections to merging this?
Stéphane
On Wed, Oct 29, 2014 at 11:04 AM, Zach Reizner wrote:
> This patch allows framebuffers for cirrus to be created with
> 32bpp pixel formats provided that they do not violate certain
> restrictions of the cirrus hardware.
>
> v2: Use pci resource le
Before this patch, cirrus_device_init could have failed while
cirrus_mm_init succeeded and the driver would have reported overall
success on load. This patch causes cirrus_device_init to return on
the first error encountered.
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/cirrus/cirrus_mai
There are places where we want to perform vertical doubling for stereo
modes without the other adjustments (doublescan, vscan > 1, etc.) that
drm_mode_set_crtcinfo() performs. Refactor this logic into its own
function so that it can be called directly in such places.
Cc: dri-devel at lists.freede
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
Cc: dri-devel at lists.freedesktop.org
Suggested-by: Ville Syrjälä
Signed-off-by: Gustavo Padovan
Signed-
On 2014å¹´11æ15æ¥ 13:41, Daniel Kurtz wrote:
> On Fri, Nov 14, 2014 at 9:39 PM, Andy Yan wrote:
>> drm driver may probe before the i2c bus, so the driver should
>> defer probing until it is available
>>
>> Signed-off-by: Andy Yan
>>
>> ---
>>
>> Changes in v11: None
>> Changes in v10: None
>>
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 v12:
- refactor of_node_put(ddc_node)
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in
Hi all,
I am writing this email to ask for your advice.
On architectures where dma addresses are different from physical
addresses, it can be difficult to retrieve the physical address of a
page from its dma address.
Specifically this is the case for Xen on arm and arm64 but I think that
other ar
On Mon, Nov 17, 2014 at 3:40 AM, Jani Nikula
wrote:
> On Sat, 15 Nov 2014, Nicholas Krause wrote:
>> Changes the calls of mdelay to msleep in the driver file
>> mdfld_dsi_pkg_sender.c
>> in order to prevent CPU busy looping in order to save CPU cycles as this is
>> considered bad form over sleep
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
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
Signed-off-by: Andy Yan
---
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 in v6: None
Changes in v5: None
Changes in v4: None
Changes in
RK3288 HDMI will not work without the spare bit of
HDMI_PHY_CONF0 enable
Signed-off-by: Andy Yan
---
Changes in v12: None
Changes in v11:
- split from patch
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
Signed-off-by: Andy Yan
---
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
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../de
the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi driver out
to drm/bridge and rename imx-hdmi to dw_hdmi
handle encoder in dw_hdmi-imx.c, as most of the encoder
operation are platform specific such as crtc select and
panel format set
Signed-off
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 v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes
some platform may not support all the display mode,
add mode_valid interface check it
also add drm_connector_register which add a debugfs
interface for dump display modes and edid information
Signed-off-by: Andy Yan
---
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v
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
On 17/11/14 14:11, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
>
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
>
> Specifically this i
Dear gentlemen,
My first contribution to the Linux kernel is for you !
(yes, really)
I apologize for all the mistake I can make in a one liner fix !
My hardware :
CPU : Beaglebone black, with ARM TI AM3358 processor
Display : Densitron ripdraw 7" 1024x600 HDMI
Software :
Kernel Linux 3.17
Build
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
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/10/8/201
Signed-off-by: Andy Yan
---
Changes in v12:
- add comment for the depend on patch
Changes in v11: None
Changes in v10:
- add more
93 matches
Mail list logo
