[Bug 65822] [radeonsi] OpenCL is broken

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65822

--- Comment #6 from Aaron Watry  ---
Created attachment 81042
  --> https://bugs.freedesktop.org/attachment.cgi?id=81042=edit
code-in-else.ll

-- 
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/20130618/34ffed6a/attachment.html>

[Bug 65822] [radeonsi] OpenCL is broken

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65822

--- Comment #5 from Aaron Watry  ---
Ack!  You're right.  I'm so used to the output being arg 0 from every other
piglit test that I neglected to check these.

With that and the index multiplier changed, these tests also pass on Cedar.

All of the test cases currently pass on my pitcairn, except for the
code-in-else test, which fails with:

cl-program-tester:
/home/awatry/src/llvm/include/llvm/Target/TargetRegisterInfo.h:560: const
llvm::TargetRegisterClass* llvm::TargetRegisterInfo::getRegClass(unsigned int)
const: Assertion `i < getNumRegClasses() && "Register Class ID out of range"'
failed.
Stack dump:
0.Running pass 'Function Pass Manager' on module 'radeon'.
1.Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function
'@test4'

I'll attach the assembly in a follow-up

-- 
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/20130618/652ba763/attachment.html>

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #70 from vincent  ---
Created attachment 81040
  --> https://bugs.freedesktop.org/attachment.cgi?id=81040=edit
Add a cos/sin pattern

Andy, does current master work on your rv790 and Unigine ?

Marc, can you try the attached patch and Unigine Heaven ? I'm not sure it'll
work (the cos/sin pattern does not trunc anything, but it should at least not
crash)

-- 
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/20130618/0ff3f0f6/attachment.html>

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

Aaron Watry  changed:

   What|Removed |Added

  Attachment #80972|0   |1
is obsolete||

--- Comment #6 from Aaron Watry  ---
Created attachment 81038
  --> https://bugs.freedesktop.org/attachment.cgi?id=81038=edit
Output from llc -debug-only=isel --march=r600 --mcpu=verde < vload-int.ll

-- 
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/20130618/4d45d210/attachment.html>

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

Aaron Watry  changed:

   What|Removed |Added

  Attachment #80971|0   |1
is obsolete||

--- Comment #5 from Aaron Watry  ---
Created attachment 81037
  --> https://bugs.freedesktop.org/attachment.cgi?id=81037=edit
LLVM Assembly that is produced from vload-int.cl (after first patch)

-- 
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/20130618/cbf7a602/attachment.html>

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

--- Comment #4 from Aaron Watry  ---
The good news is that the store error is gone...

Now I get a load error :/

LLVM ERROR: Cannot select: 0x2c92af0: i64,ch = load 0x21fe0c8, 0x2c924f0,
0x2c921f0<LD4[undef](align=8), zext from i32> [ID=15]
  0x2c924f0: i64 = add 0x2c91ef0, 0x2c923f0 [ID=13]
0x2c91ef0: i64,ch = CopyFromReg 0x21fe0c8, 0x2c91df0 [ID=12]
  0x2c91df0: i64 = Register %vreg0 [ID=1]
0x2c923f0: i64 = Constant<44> [ID=4]
  0x2c921f0: i64 = undef [ID=3]

I'll attach the llvm assembly in a follow-up

-- 
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/20130618/3bcfce08/attachment.html>

[PATCH 1/1] gpu:drm:tilcdc: get preferred_bpp value from DT

[Rob Clark]

On Tue, Jun 18, 2013 at 6:18 PM, Benoit Parrot  wrote:
> The preferred_bpp value in currently hard-coded to 16.
> This causes color corruption on the am335x-evm lcd panel which
> requires 32 bpp instead. This changes attempts to use the configured
> bpp value from the DT or built-in panel-info struct.
>
> Signed-off-by: Benoit Parrot 

Acked-by: Rob Clark 

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c|   12 +++-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h|1 +
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  |2 ++
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c  |2 ++
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |2 ++
>  5 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 2b5461b..f2a6528 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -157,7 +157,9 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
> long flags)
> struct platform_device *pdev = dev->platformdev;
> struct device_node *node = pdev->dev.of_node;
> struct tilcdc_drm_private *priv;
> +   struct tilcdc_module *mod;
> struct resource *res;
> +   u32 bpp = 0;
> int ret;
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> @@ -256,7 +258,15 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
> long flags)
>
> platform_set_drvdata(pdev, dev);
>
> -   priv->fbdev = drm_fbdev_cma_init(dev, 16,
> +
> +   list_for_each_entry(mod, _list, list) {
> +   DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
> +   bpp = mod->preferred_bpp;
> +   if (bpp > 0)
> +   break;
> +   }
> +
> +   priv->fbdev = drm_fbdev_cma_init(dev, bpp,
> dev->mode_config.num_crtc,
> dev->mode_config.num_connector);
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index 8242b5a..0906843 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -89,6 +89,7 @@ struct tilcdc_module {
> const char *name;
> struct list_head list;
> const struct tilcdc_module_ops *funcs;
> +   unsigned int preferred_bpp;
>  };
>
>  void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 0917665..86c6732 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -393,6 +393,8 @@ static int panel_probe(struct platform_device *pdev)
> goto fail;
> }
>
> +   mod->preferred_bpp = panel_mod->info->bpp;
> +
> panel_mod->backlight = of_find_backlight_by_node(node);
> if (panel_mod->backlight)
> dev_info(>dev, "found backlight\n");
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> index db1d2fc..8bf4fd1 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> @@ -323,6 +323,8 @@ static int slave_probe(struct platform_device *pdev)
> goto fail;
> }
>
> +   mod->preferred_bpp = slave_info.bpp;
> +
> i2c_node = of_find_node_by_phandle(i2c_phandle);
> if (!i2c_node) {
> dev_err(>dev, "could not get i2c bus node\n");
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> index a36788f..925c7cd 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> @@ -354,6 +354,8 @@ static int tfp410_probe(struct platform_device *pdev)
> goto fail;
> }
>
> +   mod->preferred_bpp = dvi_info.bpp;
> +
> i2c_node = of_find_node_by_phandle(i2c_phandle);
> if (!i2c_node) {
> dev_err(>dev, "could not get i2c bus node\n");
> --
> 1.7.9.5
>

[PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider

[Rahul Sharma]

sclk_pixel is used to represent pixel clock divider on all exynos
SoCs not as a gate clock. It is queried in driver to pass as the
parent to hdmi clock while switching between parents. A new ID can
be asssigned Pixel gate clock which is currently not in use. Pixel
clock gate is default 'on'.

Signed-off-by: Rahul Sharma 
---
 drivers/clk/samsung/clk-exynos5420.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 59cf177..edd0696 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata = 
{
DIV(none, "dout_fimd1", "mout_fimd1", DIV_DISP10, 0, 4),
DIV(none, "dout_mipi1", "mout_mipi1", DIV_DISP10, 16, 8),
DIV(none, "dout_dp1", "mout_dp1", DIV_DISP10, 24, 4),
-   DIV(none, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
+   DIV(sclk_pixel, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),

/* Audio Block */
DIV(none, "dout_maudio0", "mout_maudio0", DIV_MAU, 20, 4),
@@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] __initdata 
= {
GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
GATE(sclk_hdmi, "sclk_hdmi", "mout_hdmi",
GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
-   GATE(sclk_pixel, "sclk_pixel", "dout_hdmi_pixel",
+   GATE(none, "sclk_pixel", "dout_hdmi_pixel",
GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
GATE(sclk_dp1, "sclk_dp1", "dout_dp1",
GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
-- 
1.7.10.4

[PATCH 4/5] clk/exynos5420: add hdmi mux to change parents in hdmi driver

[Rahul Sharma]

hdmi driver needs to change the parent of hdmi clock
to pixel clock or hdmiphy clock, based on the stability
of hdmiphy. This patch is exposing the mux for changing
the parent.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5420-clock.txt |5 +
 drivers/clk/samsung/clk-exynos5420.c |5 -
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index f0b1ce0..c7a319d 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -182,6 +182,11 @@ clock which they consume.
   g3d  501
   smmu_tv  502

+  Mux  ID
+  
+
+  mout_hdmi1024
+
 Example 1: An example of a clock controller node is listed below.

clock: clock-controller at 0x1001 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 193d25e..59cf177 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -111,6 +111,9 @@ enum exynos5420_clks {
aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,

+   /* mux clocks */
+   mout_hdmi = 1024,
+
nr_clks,
 };

@@ -371,7 +374,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata = 
{
MUX(none, "mout_mipi1", group2_p, SRC_DISP10, 16, 3),
MUX(none, "mout_dp1", group2_p, SRC_DISP10, 20, 3),
MUX(none, "mout_pixel", group2_p, SRC_DISP10, 24, 3),
-   MUX(none, "mout_hdmi", hdmi_p, SRC_DISP10, 28, 1),
+   MUX(mout_hdmi, "mout_hdmi", hdmi_p, SRC_DISP10, 28, 1),

/* MAU Block */
MUX(none, "mout_maudio0", maudio0_p, SRC_MAU, 28, 3),
-- 
1.7.10.4

[PATCH 3/5] clk/exynos5420: fix the order of parents of hdmi mux

[Rahul Sharma]

Listing sclk_hdmiphy at 0th position in the list of parents is
causing wrong configuration in reg SRC_DISP10.

Signed-off-by: Rahul Sharma 
---
 drivers/clk/samsung/clk-exynos5420.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index e8be481..193d25e 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -257,7 +257,7 @@ PNAME(audio2_p) = { "fin_pll", "cdclk2", "sclk_dpll", 
"sclk_mpll",
  "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
 PNAME(spdif_p) = { "fin_pll", "dout_audio0", "dout_audio1", "dout_audio2",
  "spdif_extclk", "sclk_ipll", "sclk_epll", "sclk_rpll" };
-PNAME(hdmi_p)  = { "sclk_hdmiphy", "dout_hdmi_pixel" };
+PNAME(hdmi_p)  = { "dout_hdmi_pixel", "sclk_hdmiphy" };
 PNAME(maudio0_p)   = { "fin_pll", "maudio_clk", "sclk_dpll", "sclk_mpll",
  "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };

-- 
1.7.10.4

[PATCH 2/5] clk/exynos5420: add gate clock for tv sysmmu

[Rahul Sharma]

Adding sysmmu clock for tv for exynos5420.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
 drivers/clk/samsung/clk-exynos5420.c |3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 596a368..f0b1ce0 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -180,6 +180,7 @@ clock which they consume.
   fimc_lite3   495
   aclk_g3d 500
   g3d  501
+  smmu_tv  502

 Example 1: An example of a clock controller node is listed below.

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 0945435..e8be481 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -109,7 +109,7 @@ enum exynos5420_clks {
aclk300_gscl = 460, smmu_gscl0, smmu_gscl1, gscl_wa, gscl_wb, gscl0,
gscl1, clk_3aa, aclk266_g2d = 470, sss, slim_sss, mdma0,
aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
-   smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d,
+   smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,

nr_clks,
 };
@@ -696,6 +696,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] __initdata 
= {
GATE(smmu_mscl0, "smmu_mscl0", "aclk400_mscl", GATE_IP_MSCL, 8, 0, 0),
GATE(smmu_mscl1, "smmu_mscl1", "aclk400_mscl", GATE_IP_MSCL, 9, 0, 0),
GATE(smmu_mscl2, "smmu_mscl2", "aclk400_mscl", GATE_IP_MSCL, 10, 0, 0),
+   GATE(smmu_tv, "smmu_tv", "aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
 };

 static __initdata struct of_device_id ext_clk_match[] = {
-- 
1.7.10.4

[PATCH 1/5] clk/exynos5420: add sclk_hdmiphy to the list of special clocks

[Rahul Sharma]

Add sclk_hdmiphy to the list of exposed clocks. This is required
by hdmi driver to change the parent of hdmi clock.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
 drivers/clk/samsung/clk-exynos5420.c |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 9bcc4b1..596a368 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -59,6 +59,7 @@ clock which they consume.
   sclk_pwm 155
   sclk_gscl_wa 156
   sclk_gscl_wb 157
+  sclk_hdmiphy 158

[Peripheral Clock Gates]

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 68a96cb..0945435 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -91,7 +91,7 @@ enum exynos5420_clks {
sclk_i2s2, sclk_pcm1, sclk_pcm2, sclk_spdif, sclk_hdmi, sclk_pixel,
sclk_dp1, sclk_mipi1, sclk_fimd1, sclk_maudio0, sclk_maupcm0,
sclk_usbd300, sclk_usbd301, sclk_usbphy300, sclk_usbphy301, sclk_unipro,
-   sclk_pwm, sclk_gscl_wa, sclk_gscl_wb,
+   sclk_pwm, sclk_gscl_wa, sclk_gscl_wb, sclk_hdmiphy,

/* gate clocks */
aclk66_peric = 256, uart0, uart1, uart2, uart3, i2c0, i2c1, i2c2, i2c3,
@@ -268,7 +268,7 @@ struct samsung_fixed_rate_clock 
exynos5420_fixed_rate_ext_clks[] __initdata = {

 /* fixed rate clocks generated inside the soc */
 struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
-   FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
+   FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_pwi", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_usbh20", NULL, CLK_IS_ROOT, 4800),
FRATE(none, "mphy_refclk_ixtal24", NULL, CLK_IS_ROOT, 4800),
-- 
1.7.10.4

[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem

[Rahul Sharma]

Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.

This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

This set dependents on the following patches which add support for Exynos5420
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19264.html

Rahul Sharma (5):
  clk/exynos5420: add sclk_hdmiphy to the list of special clocks
  clk/exynos5420: add gate clock for tv sysmmu
  clk/exynos5420: fix the order of parents of hdmi mux
  clk/exynos5420: add hdmi mux to change parents in hdmi driver
  clk/exynos5420: assign sclk_pixel id to pixel clock divider

 .../devicetree/bindings/clock/exynos5420-clock.txt   |7 +++
 drivers/clk/samsung/clk-exynos5420.c |   18 +++---
 2 files changed, 18 insertions(+), 7 deletions(-)

-- 
1.7.10.4

[PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider

[Rahul Sharma]

With this patch, it is at par with Exynos5250 and Exynos4 clocks
where sclk_pixel ID is assigned to a divider clock but in real,
sclk_pixel is listed under gate clocks (enum value).

Alternate to this, I can allocate a new ID, div_pixel, listed under
new category of Divider Clocks for Exyno4, 5250 and 5420.
div_pixel ID can be assigned to pixel clock dividers for all 3 SoCs.
This ID can be accessed by hdmi driver as usual. While sclk_pixel
ID can be left unused for Exyno4, 5250 as there are no pixel clock
gates. And, For 5420, sclk_pixel can optionally be used to
enable/disable the pixel clock gate.

Regards,
Rahul Sharma.

On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
wrote:
> sclk_pixel is used to represent pixel clock divider on all exynos
> SoCs not as a gate clock. It is queried in driver to pass as the
> parent to hdmi clock while switching between parents. A new ID can
> be asssigned Pixel gate clock which is currently not in use. Pixel
> clock gate is default 'on'.
>
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/clk/samsung/clk-exynos5420.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 59cf177..edd0696 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata 
> = {
> DIV(none, "dout_fimd1", "mout_fimd1", DIV_DISP10, 0, 4),
> DIV(none, "dout_mipi1", "mout_mipi1", DIV_DISP10, 16, 8),
> DIV(none, "dout_dp1", "mout_dp1", DIV_DISP10, 24, 4),
> -   DIV(none, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
> +   DIV(sclk_pixel, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
>
> /* Audio Block */
> DIV(none, "dout_maudio0", "mout_maudio0", DIV_MAU, 20, 4),
> @@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] 
> __initdata = {
> GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
> GATE(sclk_hdmi, "sclk_hdmi", "mout_hdmi",
> GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
> -   GATE(sclk_pixel, "sclk_pixel", "dout_hdmi_pixel",
> +   GATE(none, "sclk_pixel", "dout_hdmi_pixel",
> GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
> GATE(sclk_dp1, "sclk_dp1", "dout_dp1",
> GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
> --
> 1.7.10.4
>

[PATCH 4/4] ARM/dts: change compatible strings for hdmi subsystem

[Rahul Sharma]

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
 arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
 arch/arm/boot/dts/exynos5250.dtsi |4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq = <66000>;

hdmiddc at 50 {
-   compatible = "samsung,exynos5-hdmiddc";
+   compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq = <378000>;

hdmiphy at 38 {
-   compatible = "samsung,exynos5-hdmiphy";
+   compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq = <66000>;

hdmiddc at 50 {
-   compatible = "samsung,exynos5-hdmiddc";
+   compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq = <66000>;

hdmiphy at 38 {
-   compatible = "samsung,exynos5-hdmiphy";
+   compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};

hdmi {
-   compatible = "samsung,exynos5-hdmi";
+   compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x7>;
interrupts = <0 95 0>;
clocks = < 333>, < 136>, < 137>,
@@ -611,7 +611,7 @@
};

mixer {
-   compatible = "samsung,exynos5-mixer";
+   compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
-- 
1.7.10.4

[PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420

[Rahul Sharma]

Modified code for calculating hdmi IP register values from drm timing
values. The modification is based on the inputs from hw team and specifically
proposed for 1440x576i and 1440x480i. But same changes holds good for other
interlaced resolutions also.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8752171..2f807d5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
(m->vsync_start - m->vdisplay) / 2);
hdmi_set_reg(core->v2_blank, 2, m->vtotal / 2);
hdmi_set_reg(core->v1_blank, 2, (m->vtotal - m->vdisplay) / 2);
-   hdmi_set_reg(core->v_blank_f0, 2, (m->vtotal +
-   ((m->vsync_end - m->vsync_start) * 4) + 5) / 2);
+   hdmi_set_reg(core->v_blank_f0, 2, m->vtotal - m->vdisplay / 2);
hdmi_set_reg(core->v_blank_f1, 2, m->vtotal);
hdmi_set_reg(core->v_sync_line_aft_2, 2, (m->vtotal / 2) + 7);
hdmi_set_reg(core->v_sync_line_aft_1, 2, (m->vtotal / 2) + 2);
@@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
(m->htotal / 2) + (m->hsync_start - m->hdisplay));
hdmi_set_reg(tg->vact_st, 2, (m->vtotal - m->vdisplay) / 2);
hdmi_set_reg(tg->vact_sz, 2, m->vdisplay / 2);
-   hdmi_set_reg(tg->vact_st2, 2, 0x249);/* Reset value + 1*/
+   hdmi_set_reg(tg->vact_st2, 2, m->vtotal - m->vdisplay / 2);
+   hdmi_set_reg(tg->vsync2, 2, (m->vtotal / 2) + 1);
+   hdmi_set_reg(tg->vsync_bot_hdmi, 2, (m->vtotal / 2) + 1);
+   hdmi_set_reg(tg->field_bot_hdmi, 2, (m->vtotal / 2) + 1);
hdmi_set_reg(tg->vact_st3, 2, 0x0);
hdmi_set_reg(tg->vact_st4, 2, 0x0);
} else {
@@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdmi_set_reg(tg->vact_st2, 2, 0x248); /* Reset value */
hdmi_set_reg(tg->vact_st3, 2, 0x47b); /* Reset value */
hdmi_set_reg(tg->vact_st4, 2, 0x6ae); /* Reset value */
+   hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
+   hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
+   hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
}

/* Following values & calculations are same irrespective of mode type */
@@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdmi_set_reg(tg->hact_sz, 2, m->hdisplay);
hdmi_set_reg(tg->v_fsz, 2, m->vtotal);
hdmi_set_reg(tg->vsync, 2, 0x1);
-   hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
hdmi_set_reg(tg->field_chg, 2, 0x233); /* Reset value */
hdmi_set_reg(tg->vsync_top_hdmi, 2, 0x1); /* Reset value */
-   hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
hdmi_set_reg(tg->field_top_hdmi, 2, 0x1); /* Reset value */
-   hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
hdmi_set_reg(tg->tg_3d, 1, 0x0);
 }

-- 
1.7.10.4

[PATCH 2/4] drm/exynos: add support for exynos5420 mixer

[Rahul Sharma]

Add support for exynos5420 mixer IP in the drm mixer driver.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |   49 +
 drivers/gpu/drm/exynos/regs-mixer.h   |7 +
 2 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2fe6d33..d51ff36 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
 enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+   MXR_VER_128_0_0_184,
 };

 struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);

-   /* choosing between porper HD and SD mode */
-   if (height <= 480)
-   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height <= 576)
-   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height <= 720)
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height <= 1080)
-   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
-   else
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
+   /* choosing between proper HD and SD mode */
+   if (height <= 480)
+   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+   else if (height <= 576)
+   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+   else if (height <= 720)
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   else if (height <= 1080)
+   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+   else
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   }

mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
 }
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);

+   /* setup display size */
+   if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
+   win == MIXER_DEFAULT_WIN) {
+   val  = MXR_MXR_RES_HEIGHT(win_data->fb_height);
+   val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
+   mixer_reg_write(res, MXR_RESOLUTION, val);
+   }
+
val  = MXR_GRP_WH_WIDTH(win_data->crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
mixer_cfg_layer(ctx, win, true);

/* layer update mandatory for mixer 16.0.33.0 */
-   if (ctx->mxr_ver == MXR_VER_16_0_33_0)
+   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+   ctx->mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);

mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)

 static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
 {
+   struct mixer_context *mixer_ctx = ctx;
u32 w, h;

w = mode->hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
drm_display_mode *mode)
mode->hdisplay, mode->vdisplay, mode->vrefresh,
(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);

+   if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
+   mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
+   return 0;
+
if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
(w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
(w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
exynos_drm_hdmi_context *ctx,
return 0;
 }

+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+   .version = MXR_VER_128_0_0_184,
+   .is_vp_enabled = 0,
+};
+
 static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1139,6 +1161,9 @@ static struct platform_device_id mixer_driver_types[] = {

 static struct of_device_id mixer_match_types[] = {
{
+   .compatible = "samsung,exynos5420-mixer",
+   .data   = _mxr_drv_data,
+   }, {
.compatible = "samsung,exynos5250-mixer",
.data   = _mxr_drv_data,
}, {
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h 
b/drivers/gpu/drm/exynos/regs-mixer.h
index 5d8dbc0..4537026 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -44,6 +44,9 @@
 #define MXR_CM_COEFF_Y 0x0080
 #define MXR_CM_COEFF_CB  

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Rahul Sharma]

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
 Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
 Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
 Documentation/devicetree/bindings/video/exynos_mixer.txt   |7 +--
 drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |2 +-
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
 drivers/gpu/drm/exynos/exynos_mixer.c  |   12 ++--
 8 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..2ac01ca 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,9 @@
 Device-Tree bindings for drm hdmi driver

 Required properties:
-- compatible: value should be "samsung,exynos5-hdmi".
+- compatible: value should be one among the following:
+   1) "samsung,exynos4210-hdmi"
+   2) "samsung,exynos4212-hdmi"
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
@@ -15,7 +17,7 @@ Required properties:
 Example:

hdmi {
-   compatible = "samsung,exynos5-hdmi";
+   compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = < 7 0xf 1 3>;
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
index fa166d9..c1bd2ea 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -1,12 +1,12 @@
 Device-Tree bindings for hdmiddc driver

 Required properties:
-- compatible: value should be "samsung,exynos5-hdmiddc".
+- compatible: value should be "samsung,exynos4210-hdmiddc".
 - reg: I2C address of the hdmiddc device.

 Example:

hdmiddc {
-   compatible = "samsung,exynos5-hdmiddc";
+   compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
index 858f4f9..e59d793 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -1,12 +1,14 @@
 Device-Tree bindings for hdmiphy driver

 Required properties:
-- compatible: value should be "samsung,exynos5-hdmiphy".
+- compatible: value should be
+   1) "samsung,exynos4210-hdmiphy".
+   2) "samsung,exynos4212-hdmiphy".
 - reg: I2C address of the hdmiphy device.

 Example:

hdmiphy {
-   compatible = "samsung,exynos5-hdmiphy";
+   compatible = "samsung,exynos4210-hdmiphy";
reg = <0x38>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..a8b063f 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -1,7 +1,10 @@
 Device-Tree bindings for mixer driver

 Required properties:
-- compatible: value should be "samsung,exynos5-mixer".
+- compatible: value should be:
+   1) "samsung,exynos4210-mixer"
+   2) "samsung,exynos5250-mixer"
+
 - reg: physical base address of the mixer and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
@@ -9,7 +12,7 @@ Required properties:
 Example:

mixer {
-   compatible = "samsung,exynos5-mixer";
+   compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 4e9b5ba..1a0cca1 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -51,7 +51,7 @@ static struct i2c_device_id ddc_idtable[] = {
 #ifdef CONFIG_OF
 static struct of_device_id hdmiddc_match_types[] = {
{
-   .compatible = "samsung,exynos5-hdmiddc",
+   .compatible = "samsung,exynos4210-hdmiddc",
}, {
/* end node */
}
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 743059f..8752171 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ 

[PATCH 0/4] exynos5420/hdmi: add support for hdmi subsystem

[Rahul Sharma]

Add support for exynos5420 hdmi subsystem. It adds compatible strings
for exynos5420 mixer and Changes the drivers as per IP modifications.

This set doesn't have changes for hdmiphy, which will posted
independently.

This set is based on drm-next branch of Inki Dae's tree at
http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git.

Rahul Sharma (4):
  drm/exynos: rename compatible strings for hdmi subsystem
  drm/exynos: add support for exynos5420 mixer
  drm/exynos: fix interlace resolutions for exynos5420
  ARM/dts: change compatible strings for hdmi subsystem

 .../devicetree/bindings/video/exynos_hdmi.txt  |6 +-
 .../devicetree/bindings/video/exynos_hdmiddc.txt   |4 +-
 .../devicetree/bindings/video/exynos_hdmiphy.txt   |6 +-
 .../devicetree/bindings/video/exynos_mixer.txt |7 ++-
 arch/arm/boot/dts/cros5250-common.dtsi |4 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +-
 arch/arm/boot/dts/exynos5250.dtsi  |4 +-
 drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   16 ++---
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +-
 drivers/gpu/drm/exynos/exynos_mixer.c  |   61 ++--
 drivers/gpu/drm/exynos/regs-mixer.h|7 +++
 12 files changed, 84 insertions(+), 41 deletions(-)

-- 
1.7.10.4

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

> -Original Message-
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 5:43 PM
> To: Inki Dae
> Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
> list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
> linux-arm-kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
> 
> On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> > So I'd like to ask for other DRM maintainers. How do you think about it?
> it
> > seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained
> by
> > Rob) and GEM CMA helper also have same issue Russell pointed out. I
> think
> > not only the above approach but also the performance is very important.
> 
> CMA uses coherent memory to back their buffers, though that might not be
> true of memory obtained from other drivers via dma_buf.  Plus, there is
> no support in the CMA helper for exporting or importng these buffers.
> 

It's not so. Please see Dave's drm next. recently dmabuf support for the CMA
helper has been merged to there.

> I guess Intel i915 is only used on x86, which is a coherent platform and
> requires no cache maintanence for DMA.
> 
> OMAP DRM does not support importing non-DRM buffers buffers back into

Correct. TODO yet.

> DRM.  Moreover, it will suffer from the problems I described if any
> attempt is made to write to the buffer after it has been re-imported.
> 
> Lastly, I should point out that the dma_buf stuff is really only useful
> when you need to export a dma buffer from one driver and import it into
> another driver - for example to pass data from a camera device driver to

Most people know that.

> a display device driver.  It shouldn't be used within a single driver
> as a means of passing buffers between userspace and kernel space.

What I try to do is not really such ugly thing. What I try to do is to
notify that, when CPU tries to access a buffer , to kernel side through
dmabuf interface. So it's not really to send the buffer to kernel.

Thanks,
Inki Dae

[PATCH 7/9] drm/exynos: use of_get_named_gpio to get hdmi hpd gpio

[Rahul Sharma]

Thanks Mr. Dae,

Please discard the REST of the patches in this series. I am posting a
another patch-set which has all the patches independent of hdmiphy
related changes.

regards,
Rahul Sharma.

On Mon, Jun 17, 2013 at 8:22 AM, Inki Dae  wrote:
> Applied.
>
> Thanks,
> Inki Dae
>
>
> 2013/6/14 ??? 
>>
>> Hello Rahul,
>>
>> this patch is not related with others and it looks good to me.
>>
>> On 2013? 06? 11? 23:11, Rahul Sharma wrote:
>> > Cleanup by removing flags variable from drm_hdmi_dt_parse_pdata
>> > which is not used anywhere. Swtiching to of_get_named_gpio instead
>> > of of_get_named_gpio_flags solved this.
>> >
>> > Signed-off-by: Rahul Sharma 
>>
>> Acked-by: Seung-Woo Kim 
>>
>> > ---
>> >  drivers/gpu/drm/exynos/exynos_hdmi.c |3 +--
>> >  1 file changed, 1 insertion(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> > b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> > index 1eb5ffb..fc6a9b0 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> > @@ -2081,7 +2081,6 @@ static struct s5p_hdmi_platform_data
>> > *drm_hdmi_dt_parse_pdata
>> >  {
>> >   struct device_node *np = dev->of_node;
>> >   struct s5p_hdmi_platform_data *pd;
>> > - enum of_gpio_flags flags;
>> >   u32 value;
>> >
>> >   pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
>> > @@ -2095,7 +2094,7 @@ static struct s5p_hdmi_platform_data
>> > *drm_hdmi_dt_parse_pdata
>> >   goto err_data;
>> >   }
>> >
>> > - pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, );
>> > + pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
>> >
>> >   return pd;
>> >
>> >
>>
>> --
>> Seung-Woo Kim
>> Samsung Software R Center
>> --
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 65822] [radeonsi] OpenCL is broken

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65822

Tom Stellard  changed:

   What|Removed |Added

  Attachment #80967|0   |1
is obsolete||
  Attachment #80969|0   |1
is obsolete||

--- Comment #4 from Tom Stellard  ---
Created attachment 81026
  --> https://bugs.freedesktop.org/attachment.cgi?id=81026=edit
Updated piglit tests

Thanks for writing the piglit tests, I noticed a few bugs in them though. 
First, the output argument for all of the tests should be index 2 and not index
0 and second, in test #2 the buffer index should be multiplied by 8 instead of
10.  I've fixed the piglit tests in the attached patch and also replaced the
'_' with '-' in the filename.  The updated tests pass on my Llano APU.

-- 
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/20130618/ea77b44f/attachment.html>

[PATCH v3 1/3] drm: add prime helpers

[Aaron Plattner]

On 06/18/2013 04:37 PM, Laurent Pinchart wrote:
> Hi Aaron,
>
> On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
>> On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
>>> Hi Aaron,
>>>
>>> A bit late, but here's a small question.
>>>
>>> On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
 Instead of reimplementing all of the dma_buf functionality in every
 driver, create helpers drm_prime_import and drm_prime_export that
 implement them in terms of new, lower-level hook functions:
 gem_prime_pin: callback when a buffer is created, used to pin buffers
 into
 GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
 export gem_prime_import_sg_table: convert an sg_table into a
 drm_gem_object
 gem_prime_vmap, gem_prime_vunmap: map and unmap an object

 These hooks are optional; drivers can opt in by using
 drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import
 and .gem_prime_export fields of struct drm_driver.

 v2:
 - Drop .begin_cpu_access.  None of the drivers this code replaces
 implemented it.  Having it here was a leftover from when I was trying to
 include i915 in this rework.
 - Use mutex_lock instead of mutex_lock_interruptible, as these three
 drivers did.  This patch series shouldn't change that behavior.
 - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.

 Rename struct sg_table* variables to 'sgt' for clarity.

 - Update drm.tmpl for these new hooks.

 v3:
 - Pass the vaddr down to the driver.  This lets drivers that just call
 vunmap on the pointer avoid having to store the pointer in their GEM
 private structures. - Move documentation into a /** DOC */ comment in
 drm_prime.c and include it in drm.tmpl with a !P line.  I tried to use !F
 lines to include documentation of the individual functions from drmP.h,
 but
 the docproc / kernel-doc scripts barf on that file, so hopefully this is
 good enough for now.
 - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec

 ("drm/prime: drop reference on imported dma-buf come from gem")

 Signed-off-by: Aaron Plattner 
 Cc: Daniel Vetter 
 Cc: David Airlie 
 ---

Documentation/DocBook/drm.tmpl |   4 +
drivers/gpu/drm/drm_prime.c| 186
+-
include/drm/drmP.h |  12 +++
3 files changed, 201 insertions(+), 1 deletion(-)
>>>
>>> [snip]
>>>
 diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
 index 7f12573..366910d 100644
 --- a/drivers/gpu/drm/drm_prime.c
 +++ b/drivers/gpu/drm/drm_prime.c
>>>
>>> [snip]
>>>
 +/**
 + * DOC: PRIME Helpers
 + *
 + * Drivers can implement @gem_prime_export and @gem_prime_import in
 terms
 of + * simpler APIs by using the helper functions @drm_gem_prime_export
 and
 + * @drm_gem_prime_import.  These functions implement dma-buf support in
 terms of + * five lower-level driver callbacks:
 + *
 + * Export callbacks:
 + *
 + *  - @gem_prime_pin (optional): prepare a GEM object for exporting
 + *
 + *  - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
 pages + *
 + *  - @gem_prime_vmap: vmap a buffer exported by your driver
 + *
 + *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
 + *
 + * Import callback:
 + *
 + *  - @gem_prime_import_sg_table (import): produce a GEM object from
 another + *driver's scatter/gather table
 + */
 +
 +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 +   struct drm_gem_object *obj, int flags)
 +{
 +  if (dev->driver->gem_prime_pin) {
 +  int ret = dev->driver->gem_prime_pin(obj);
 +  if (ret)
 +  return ERR_PTR(ret);
 +  }
 +  return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
 +0600);
>>>
>>> Why do you use 0600 instead of the flags passed by the caller ?
>>
>> Because I copied & pasted it from i915_gem_prime_export prior to commit
>> 5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
>> pointed it out just now.
>
> That's a pretty valid reason I guess :-) Should I submit a patch or are you
> already working on one ?

:)  Sorry!

I'm not working on this right now, but I can put it on my queue if you 
like.  You'll probably be able to fix and test it sooner than I will, 
though.

 +}
 +EXPORT_SYMBOL(drm_gem_prime_export);

-- 
Aaron

[PATCH 1/1] gpu:drm:tilcdc: get preferred_bpp value from DT

[Benoit Parrot]

The preferred_bpp value in currently hard-coded to 16.
This causes color corruption on the am335x-evm lcd panel which
requires 32 bpp instead. This changes attempts to use the configured
bpp value from the DT or built-in panel-info struct.

Signed-off-by: Benoit Parrot 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   12 +++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|1 +
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  |2 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  |2 ++
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |2 ++
 5 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 2b5461b..f2a6528 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -157,7 +157,9 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
struct platform_device *pdev = dev->platformdev;
struct device_node *node = pdev->dev.of_node;
struct tilcdc_drm_private *priv;
+   struct tilcdc_module *mod;
struct resource *res;
+   u32 bpp = 0;
int ret;

priv = kzalloc(sizeof(*priv), GFP_KERNEL);
@@ -256,7 +258,15 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)

platform_set_drvdata(pdev, dev);

-   priv->fbdev = drm_fbdev_cma_init(dev, 16,
+
+   list_for_each_entry(mod, _list, list) {
+   DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
+   bpp = mod->preferred_bpp;
+   if (bpp > 0)
+   break;
+   }
+
+   priv->fbdev = drm_fbdev_cma_init(dev, bpp,
dev->mode_config.num_crtc,
dev->mode_config.num_connector);

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 8242b5a..0906843 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -89,6 +89,7 @@ struct tilcdc_module {
const char *name;
struct list_head list;
const struct tilcdc_module_ops *funcs;
+   unsigned int preferred_bpp;
 };

 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 0917665..86c6732 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -393,6 +393,8 @@ static int panel_probe(struct platform_device *pdev)
goto fail;
}

+   mod->preferred_bpp = panel_mod->info->bpp;
+
panel_mod->backlight = of_find_backlight_by_node(node);
if (panel_mod->backlight)
dev_info(>dev, "found backlight\n");
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index db1d2fc..8bf4fd1 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -323,6 +323,8 @@ static int slave_probe(struct platform_device *pdev)
goto fail;
}

+   mod->preferred_bpp = slave_info.bpp;
+
i2c_node = of_find_node_by_phandle(i2c_phandle);
if (!i2c_node) {
dev_err(>dev, "could not get i2c bus node\n");
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index a36788f..925c7cd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -354,6 +354,8 @@ static int tfp410_probe(struct platform_device *pdev)
goto fail;
}

+   mod->preferred_bpp = dvi_info.bpp;
+
i2c_node = of_find_node_by_phandle(i2c_phandle);
if (!i2c_node) {
dev_err(>dev, "could not get i2c bus node\n");
-- 
1.7.9.5

[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Kishon Vijay Abraham I]

Hi,

On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> Thanks all,
> 
> On Fri, Jun 14, 2013 at 11:39 AM, ???  wrote:
>> Hello Kishon,
>>
>> On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:


> -Original Message-
> From: Sylwester Nawrocki [mailto:s.nawrocki at samsung.com]
> Sent: Thursday, June 13, 2013 5:56 PM
> To: Rahul Sharma
> Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org;
> devicetree-
> discuss at lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim;
> Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
> grant.likely at linaro.org
> Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with
> pmu reg control
>
> Hi,
>
> On 06/13/2013 06:26 AM, Rahul Sharma wrote:
>> Mr. Dae,
>>
>> Thanks for your valuable inputs.
>>
>> I posted it as RFC because, I also have received comments to register
>> hdmiphy as a clock controller. As we always configure it for specific
>> frequency, hdmi-phy looks similar to a PLL. But it really doesn't
>> belong to that class. Secondly prior to exynos5420, it was a i2c
>> device. I am not sure we can register a I2C device as a clock
>> controller. I wanted to discuss and explore this option here.
>
> Have you considered using the generic PHY framework for those HDMI
> PHY devices [1] ? I guess we could add a dedicated group of ops for
> video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
> configuring things like the carrier/pixel clock frequency or anything
> what's common across the video PHYs.
>
> Perhaps you could have a look and see if this framework would be
> useful for HDMI and possibly point out anything what might be missing ?
>
> I'm not sure it it really solves the issues specific to the Exynos
> HDMI but at least with a generic PHY driver the PHY module would be
> separate from the PHY controller, as often same HDMI DPHY can be used
> with various types of a HDMI controller. So this would allow to not
> duplicate the HDMI PHY drivers in the long-term perspective.

 Yeah, at least, it seems that we could use PHY module to control PMU
 register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off
 callbacks. As you may know, HDMIPHY needs i2c interfaces to control
 HDMIPHY
 clock. So with PHY module, HDMIPHY driver could enable PMU more
 generically,
 but also has to use existing i2c stuff to control HDMIPHY clock. I had a
 quick review to Generic PHY Framework[v6] but I didn't see that the PHY
 module could generically support more features such as i2c stuff.
>>>
>>> I don't think PHY framework needs to provide i2c interfaces to program
>>> certain configurations. Instead in one of the callbacks (init/on/off)
>>> PHY driver can program whatever it wants using any of the interfaces it
>>> needs. IMO PHY framework should work independent of the interfaces.
>>
>> In exnoys hdmi case, i2c interface is not the exact issue. In exynos
>> hdmi, hdmiphy should send i2c configuration about video clock
>> information as the video mode information including resolution, bit per
>> pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
>> of phy framework are not enough for exynos hdmiphy and it should have a
>> callback to set video mode.
>>
>> Do you have plan to add driver specific extend callback pointers to phy
>> framework?
>>
>> Currently, hdmi directly calls phy operations, but Rahul's another patch
>> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is
>> connected with exynos hdmi own sub driver callback operations.
>>
>> IMHO, if phy framework can support extend callback feature, then this
>> own sub driver callbacks can be replaced with phy framework at long term
>> view.
> 
> Extended callbacks are always welcome. I can also use phy device
> private data to pass on private ops like get_pixelclk and set_pixelclk.

I would recommend creating a wrapper to the existing PHY framework
for HDMI PHY. That way, we can have other HDMI phys added
easily. We need to figure out all the ops that might be needed by the
HDMI PHY to be added to the wrapper.
IMO extended callbacks can lead to abuse of the system and should be
used only when absolutely necessary.

Thanks
Kishon

[PATCH 10/10] idr: Rework idr_preload()

[Kent Overstreet]

The old idr_preload() used percpu buffers - since the
bitmap/radix/whatever tree only grew by fixed sized nodes, it only had
to ensure there was a node available in the percpu buffer and disable
preemption. This conveniently meant that you didn't have to pass the idr
you were going to allocate from to it.

With the new ida implementation, that doesn't work anymore - the new ida
code grows its bitmap tree by reallocating the entire thing in power of
two increments. Doh.

So we need a slightly different trick. Note that if all allocations from
an idr start by calling idr_prealloc() and disabling premption, at
most nr_cpus() allocations can happen before someone calls
idr_prealloc() again.

So, we just change idr_prealloc() to resize the ida bitmap tree if
there's less than num_possible_cpus() ids available - conveniently, we
already track the number of allocated ids, and the total number of ids
we can have allocated is just nr_leaf_nodes * BITS_PER_LONG. Easy.

This does require a fairly trivial interface change - we now have to
pass the idr we're going to allocate from (and the starting id we're
going to pass to idr_allocate_range()) to idr_prealloc(), so this patch
updates all the callers.

Signed-off-by: Kent Overstreet 
Cc: Andrew Morton 
Cc: Tejun Heo 
Cc: Stefan Richter 
Cc: David Airlie 
Cc: Roland Dreier 
Cc: Sean Hefty 
Cc: Hal Rosenstock 
Cc: Steve Wise 
Cc: Hoang-Nam Nguyen 
Cc: Christoph Raisch 
Cc: Mike Marciniszyn 
Cc: Doug Gilbert 
Cc: "James E.J. Bottomley" 
Cc: Christine Caulfield 
Cc: David Teigland 
Cc: Trond Myklebust 
Cc: John McCutchan 
Cc: Robert Love 
Cc: Eric Paris 
Cc: Dave Airlie 
Cc: Thomas Hellstrom 
Cc: Brian Paul 
Cc: Maarten Lankhorst 
Cc: Dmitry Torokhov 
Cc: Erez Shitrit 
Cc: Al Viro 
Cc: Haggai Eran 
Cc: Jack Morgenstein 
Cc: Wolfram Sang 
Cc: Greg Kroah-Hartman 
Cc: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Michel Lespinasse 
Cc: linux1394-devel at lists.sourceforge.net
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-rdma at vger.kernel.org
Cc: linux-scsi at vger.kernel.org
Cc: cluster-devel at redhat.com
Cc: linux-nfs at vger.kernel.org
---
 drivers/firewire/core-cdev.c   |  2 +-
 drivers/gpu/drm/drm_gem.c  |  4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  2 +-
 drivers/infiniband/core/cm.c   |  7 +---
 drivers/infiniband/core/sa_query.c |  2 +-
 drivers/infiniband/core/uverbs_cmd.c   |  2 +-
 drivers/infiniband/hw/cxgb3/iwch.h |  2 +-
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h |  2 +-
 drivers/infiniband/hw/ehca/ehca_cq.c   |  2 +-
 drivers/infiniband/hw/ehca/ehca_qp.c   |  2 +-
 drivers/infiniband/hw/ipath/ipath_driver.c |  2 +-
 drivers/infiniband/hw/mlx4/cm.c|  2 +-
 drivers/infiniband/hw/qib/qib_init.c   |  2 +-
 drivers/scsi/sg.c  |  2 +-
 fs/dlm/lock.c  |  2 +-
 fs/dlm/recover.c   |  2 +-
 fs/nfs/nfs4client.c|  2 +-
 fs/notify/inotify/inotify_user.c   |  2 +-
 include/linux/idr.h| 37 +
 ipc/util.c |  4 +-
 lib/idr.c  | 66 ++
 21 files changed, 91 insertions(+), 59 deletions(-)

diff --git a/drivers/firewire/core-cdev.c b/drivers/firewire/core-cdev.c
index 436debf..3c70fbc 100644
--- a/drivers/firewire/core-cdev.c
+++ b/drivers/firewire/core-cdev.c
@@ -490,7 +490,7 @@ static int add_client_resource(struct client *client,
int ret;

if (preload)
-   idr_preload(gfp_mask);
+   idr_preload(>resource_idr, 0, gfp_mask);
spin_lock_irqsave(>lock, flags);

if (client->in_shutdown)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1c897b9..cf50894 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -273,7 +273,7 @@ drm_gem_handle_create(struct drm_file *file_priv,
 * Get the user-visible handle using idr.  Preload and perform
 * allocation under our spinlock.
 */
-   idr_preload(GFP_KERNEL);
+   idr_preload(_priv->object_idr, 1, GFP_KERNEL);
spin_lock(_priv->table_lock);

ret = idr_alloc_range(_priv->object_idr, obj, 1, 0, GFP_NOWAIT);
@@ -449,7 +449,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
if (obj == NULL)
return -ENOENT;

-   idr_preload(GFP_KERNEL);
+   idr_preload(>object_name_idr, 1, GFP_KERNEL);
spin_lock(>object_name_lock);
if (!obj->name) {
ret = idr_alloc_range(>object_name_idr, obj, 1, 0, 
GFP_NOWAIT);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index ccbaed1..9f00706 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -177,7 +177,7 @@ int vmw_resource_alloc_id(struct 

[PATCH 09/10] idr: Remove unneeded idr locking, idr_preload() usage

[Kent Overstreet]

Our new idr implementation does its own locking, instead of forcing it
onto the callers like the old implementation.

Many of the existing idr users need locking for more than just
idr_alloc()/idr_remove()/idr_find() - they're taking refcounts and such
under their locks and we can't touch those.

But a significant number of users had locks that protected nothing more
than the idr data structures itself - those we can get rid of.

Note that we have to be careful when removing locks; in some places,
locks appear to only be protecting idr_alloc()/idr_remove() calls but
they're also used by other code that needs to ensure the idr isn't
modified while it's doing something else - so ideally we want to delete
the lock that protected the idr, or else we have to carefully audit all
the other places it's used.

There's also a fair number of places where things were being done under
the idr lock unnecessarily; drivers/dca/dca-sysfs.c is a good example.
dca->id is set to the id idr_alloc() returns under the lock - but
there's no idr_find() calls under the lock, and dca->id isn't touched in
the idr_remove() paths. So the lock can be safely deleted.

The really nice thing about deleting this unnecessary locking is that it
lets us trivially delete a lot of now unnecessary idr_preload() - with
idr doing its own locking, we can pass GFP_KERNEL to idr_alloc() just
fine.

Signed-off-by: Kent Overstreet 
Cc: Andrew Morton 
Cc: Tejun Heo 
Cc: David Airlie 
Cc: Tom Tucker 
Cc: Steve Wise 
Cc: Roland Dreier 
Cc: Sean Hefty 
Cc: Hal Rosenstock 
Cc: Alasdair Kergon 
Cc: dm-devel at redhat.com
Cc: Samuel Ortiz 
Cc: Alex Dubov 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Chris Ball 
Cc: "James E.J. Bottomley" 
Cc: Willem Riede 
Cc: "Kai M?kisara" 
Cc: "Nicholas A. Bellinger" 
Cc: Li Zefan 
Cc: Vlad Yasevich 
Cc: Neil Horman 
Cc: "David S. Miller" 
Cc: Dave Airlie 
Cc: Alon Levy 
Cc: Guennadi Liakhovetski 
Cc: Christoph Hellwig 
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-rdma at vger.kernel.org
Cc: linux-mmc at vger.kernel.org
Cc: linux-scsi at vger.kernel.org
Cc: osst-users at lists.sourceforge.net
Cc: target-devel at vger.kernel.org
Cc: containers at lists.linux-foundation.org
Cc: cgroups at vger.kernel.org
Cc: linux-sctp at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 drivers/dca/dca-sysfs.c   | 18 +++---
 drivers/gpu/drm/qxl/qxl_cmd.c |  4 +---
 drivers/gpu/drm/qxl/qxl_drv.h |  1 -
 drivers/gpu/drm/qxl/qxl_kms.c |  1 -
 drivers/gpu/drm/qxl/qxl_release.c | 19 +--
 drivers/infiniband/hw/amso1100/c2.h   |  1 -
 drivers/infiniband/hw/amso1100/c2_qp.c| 20 ++--
 drivers/md/dm.c   | 22 --
 drivers/memstick/core/memstick.c  | 17 +++--
 drivers/mfd/rtsx_pcr.c| 13 +++--
 drivers/misc/c2port/core.c| 11 +--
 drivers/misc/tifm_core.c  | 15 +++
 drivers/mmc/core/host.c   | 13 ++---
 drivers/scsi/ch.c | 14 ++
 drivers/scsi/st.c | 13 +
 drivers/target/iscsi/iscsi_target.c   | 17 -
 drivers/target/iscsi/iscsi_target.h   |  1 -
 drivers/target/iscsi/iscsi_target_login.c | 12 ++--
 include/linux/cgroup.h|  1 -
 include/net/sctp/sctp.h   |  1 -
 kernel/cgroup.c   |  9 +
 kernel/workqueue.c| 15 ++-
 net/9p/util.c | 15 +--
 net/sctp/associola.c  | 14 ++
 net/sctp/protocol.c   |  1 -
 net/sctp/socket.c |  2 --
 26 files changed, 42 insertions(+), 228 deletions(-)

diff --git a/drivers/dca/dca-sysfs.c b/drivers/dca/dca-sysfs.c
index effda66..6be5fbd 100644
--- a/drivers/dca/dca-sysfs.c
+++ b/drivers/dca/dca-sysfs.c
@@ -31,7 +31,6 @@

 static struct class *dca_class;
 static struct idr dca_idr;
-static spinlock_t dca_idr_lock;

 int dca_sysfs_add_req(struct dca_provider *dca, struct device *dev, int slot)
 {
@@ -55,23 +54,15 @@ int dca_sysfs_add_provider(struct dca_provider *dca, struct 
device *dev)
struct device *cd;
int ret;

-   idr_preload(GFP_KERNEL);
-   spin_lock(_idr_lock);
-
-   ret = idr_alloc(_idr, dca, GFP_NOWAIT);
-   if (ret >= 0)
-   dca->id = ret;
-
-   spin_unlock(_idr_lock);
-   idr_preload_end();
+   ret = idr_alloc(_idr, dca, GFP_KERNEL);
if (ret < 0)
return ret;

+   dca->id = ret;
+
cd = device_create(dca_class, dev, MKDEV(0, 0), NULL, "dca%d", dca->id);
if (IS_ERR(cd)) {
-   spin_lock(_idr_lock);
idr_remove(_idr, dca->id);
-   spin_unlock(_idr_lock);

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

--- Comment #3 from Tom Stellard  ---
These patches should fix the issue:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130617/178156.html

The first patch is unrelated to the bug, but it is required in order to prevent
the test case in the second patch from crashing on Cayman.  I've tested this on
llc, can you verify it works on real hardware.

-- 
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/20130618/9c67558e/attachment.html>

[PATCH v3 1/3] drm: add prime helpers

[Aaron Plattner]

On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
> Hi Aaron,
>
> A bit late, but here's a small question.
>
> On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
>> Instead of reimplementing all of the dma_buf functionality in every driver,
>> create helpers drm_prime_import and drm_prime_export that implement them in
>> terms of new, lower-level hook functions:
>>
>>gem_prime_pin: callback when a buffer is created, used to pin buffers into
>> GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
>> export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
>> gem_prime_vmap, gem_prime_vunmap: map and unmap an object
>>
>> These hooks are optional; drivers can opt in by using drm_gem_prime_import
>> and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export
>> fields of struct drm_driver.
>>
>> v2:
>> - Drop .begin_cpu_access.  None of the drivers this code replaces
>> implemented it.  Having it here was a leftover from when I was trying to
>> include i915 in this rework.
>> - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
>> did.  This patch series shouldn't change that behavior.
>> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
>>Rename struct sg_table* variables to 'sgt' for clarity.
>> - Update drm.tmpl for these new hooks.
>>
>> v3:
>> - Pass the vaddr down to the driver.  This lets drivers that just call
>> vunmap on the pointer avoid having to store the pointer in their GEM
>> private structures. - Move documentation into a /** DOC */ comment in
>> drm_prime.c and include it in drm.tmpl with a !P line.  I tried to use !F
>> lines to include documentation of the individual functions from drmP.h, but
>> the docproc / kernel-doc scripts barf on that file, so hopefully this is
>> good enough for now.
>> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
>>("drm/prime: drop reference on imported dma-buf come from gem")
>>
>> Signed-off-by: Aaron Plattner 
>> Cc: Daniel Vetter 
>> Cc: David Airlie 
>> ---
>>   Documentation/DocBook/drm.tmpl |   4 +
>>   drivers/gpu/drm/drm_prime.c| 186 +-
>>   include/drm/drmP.h |  12 +++
>>   3 files changed, 201 insertions(+), 1 deletion(-)
>
> [snip]
>
>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>> index 7f12573..366910d 100644
>> --- a/drivers/gpu/drm/drm_prime.c
>> +++ b/drivers/gpu/drm/drm_prime.c
>
> [snip]
>
>> +/**
>> + * DOC: PRIME Helpers
>> + *
>> + * Drivers can implement @gem_prime_export and @gem_prime_import in terms
>> of + * simpler APIs by using the helper functions @drm_gem_prime_export and
>> + * @drm_gem_prime_import.  These functions implement dma-buf support in
>> terms of + * five lower-level driver callbacks:
>> + *
>> + * Export callbacks:
>> + *
>> + *  - @gem_prime_pin (optional): prepare a GEM object for exporting
>> + *
>> + *  - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
>> pages + *
>> + *  - @gem_prime_vmap: vmap a buffer exported by your driver
>> + *
>> + *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
>> + *
>> + * Import callback:
>> + *
>> + *  - @gem_prime_import_sg_table (import): produce a GEM object from
>> another + *driver's scatter/gather table
>> + */
>> +
>> +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
>> + struct drm_gem_object *obj, int flags)
>> +{
>> +if (dev->driver->gem_prime_pin) {
>> +int ret = dev->driver->gem_prime_pin(obj);
>> +if (ret)
>> +return ERR_PTR(ret);
>> +}
>> +return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
>> +  0600);
>
> Why do you use 0600 instead of the flags passed by the caller ?

Because I copied & pasted it from i915_gem_prime_export prior to commit 
5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you 
pointed it out just now.

>> +}
>> +EXPORT_SYMBOL(drm_gem_prime_export);


-- 
Aaron

[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Rahul Sharma]

Thanks all,

On Fri, Jun 14, 2013 at 11:39 AM, ???  wrote:
> Hello Kishon,
>
> On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
>>>
>>>
 -Original Message-
 From: Sylwester Nawrocki [mailto:s.nawrocki at samsung.com]
 Sent: Thursday, June 13, 2013 5:56 PM
 To: Rahul Sharma
 Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org;
 devicetree-
 discuss at lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim;
 Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
 grant.likely at linaro.org
 Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with
 pmu reg control

 Hi,

 On 06/13/2013 06:26 AM, Rahul Sharma wrote:
> Mr. Dae,
>
> Thanks for your valuable inputs.
>
> I posted it as RFC because, I also have received comments to register
> hdmiphy as a clock controller. As we always configure it for specific
> frequency, hdmi-phy looks similar to a PLL. But it really doesn't
> belong to that class. Secondly prior to exynos5420, it was a i2c
> device. I am not sure we can register a I2C device as a clock
> controller. I wanted to discuss and explore this option here.

 Have you considered using the generic PHY framework for those HDMI
 PHY devices [1] ? I guess we could add a dedicated group of ops for
 video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
 configuring things like the carrier/pixel clock frequency or anything
 what's common across the video PHYs.

 Perhaps you could have a look and see if this framework would be
 useful for HDMI and possibly point out anything what might be missing ?

 I'm not sure it it really solves the issues specific to the Exynos
 HDMI but at least with a generic PHY driver the PHY module would be
 separate from the PHY controller, as often same HDMI DPHY can be used
 with various types of a HDMI controller. So this would allow to not
 duplicate the HDMI PHY drivers in the long-term perspective.
>>>
>>> Yeah, at least, it seems that we could use PHY module to control PMU
>>> register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off
>>> callbacks. As you may know, HDMIPHY needs i2c interfaces to control
>>> HDMIPHY
>>> clock. So with PHY module, HDMIPHY driver could enable PMU more
>>> generically,
>>> but also has to use existing i2c stuff to control HDMIPHY clock. I had a
>>> quick review to Generic PHY Framework[v6] but I didn't see that the PHY
>>> module could generically support more features such as i2c stuff.
>>
>> I don't think PHY framework needs to provide i2c interfaces to program
>> certain configurations. Instead in one of the callbacks (init/on/off)
>> PHY driver can program whatever it wants using any of the interfaces it
>> needs. IMO PHY framework should work independent of the interfaces.
>
> In exnoys hdmi case, i2c interface is not the exact issue. In exynos
> hdmi, hdmiphy should send i2c configuration about video clock
> information as the video mode information including resolution, bit per
> pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
> of phy framework are not enough for exynos hdmiphy and it should have a
> callback to set video mode.
>
> Do you have plan to add driver specific extend callback pointers to phy
> framework?
>
> Currently, hdmi directly calls phy operations, but Rahul's another patch
> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is
> connected with exynos hdmi own sub driver callback operations.
>
> IMHO, if phy framework can support extend callback feature, then this
> own sub driver callbacks can be replaced with phy framework at long term
> view.

Extended callbacks are always welcome. I can also use phy device
private data to pass on private ops like get_pixelclk and set_pixelclk.
Similar logic has been used to pass struct omap_usb to usb phy
controller. I can add these changes for migration of hdmiphy to
generic phy framwork to my hdmiphy separation patch set.

regards,
Rahul Sharma.

>
> Thanks and Regards,
> - Seung-Woo Kim
>
>>
>> For example, twl4030 phy driver actually uses i2c to program its
>> registers but still it uses the PHY framework [1].
>>
>> [1] --> http://www.gossamer-threads.com/lists/linux/kernel/1729414
>>
>> Thanks
>> Kishon
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> Seung-Woo Kim
> Samsung Software R Center
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

exynos-drm-next todo work.

[Inki Dae]

Hi all,

I'd like to discuss Exynos DRM TODO work.

There are features we have to solve and implement. The purpose of this email
is to share what we have to do so that other guys can be involved without
duplicated work.

1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler
device instead of VP device. And now exynos drm driver has gscaler module as
a sub module of IPP framework. However, this gscaler module is very specific
to IPP framework so it's not easy to reuse this module. So maybe we need so
many works for it.

Video play back path using post process (AS IS):
MFCIPPKMS-FIMD or HDMI

Ideal video play back path using post process (TO BE):
MFCKMSFIMD or HDMI

The above scenario is to send decoded image data (YUV format) to display
device via post process. However, we don't really need to use IPP framework
in case of using gscaler as VP. All we have to do is to call kms interface
(setplane) for it like we did before.

2. More features for HDMI sound support - we need to implement Exynos ALSA
SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit
rate, and so on from user side should be sent to drm hdmi driver via ALSA
interface and the ALSA SoC DAI driver. As of now, it seems like that we
should implement this driver like OMAP does because there is no common
framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver:
in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces
of DSS driver directly. I think we could implement ALSA SoC DAI driver in
more generic way if we first implement common framework for it.

Welcome to any volunteer and other opinions.

Thanks,
Inki Dae

exynos-drm-next todo work.

[Rahul Sharma]

Hi Mr. Dae,

Related to HDMI sound support in Alsa, I have posted a working RFC
"exynos-hdmi to CDF complaint display driver". It registers a separate
sound card by registering hdmi audio codec dai and cpu-dai, as you
mentioned. But there is a problem with this approach that I2S being the
single cpu dai for HDMI and Speaker sound card, only one card can
support playback at a time.

I would like to work on this to provide a more refined solution.

regards,
Rahul Sharma.

On Tue, Jun 18, 2013 at 12:03 PM, Inki Dae  wrote:
> Hi all,
>
> I'd like to discuss Exynos DRM TODO work.
>
> There are features we have to solve and implement. The purpose of this email
> is to share what we have to do so that other guys can be involved without
> duplicated work.
>
> 1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler
> device instead of VP device. And now exynos drm driver has gscaler module as
> a sub module of IPP framework. However, this gscaler module is very specific
> to IPP framework so it's not easy to reuse this module. So maybe we need so
> many works for it.
>
> Video play back path using post process (AS IS):
> MFCIPPKMS-FIMD or HDMI
>
> Ideal video play back path using post process (TO BE):
> MFCKMSFIMD or HDMI
>
> The above scenario is to send decoded image data (YUV format) to display
> device via post process. However, we don't really need to use IPP framework
> in case of using gscaler as VP. All we have to do is to call kms interface
> (setplane) for it like we did before.
>
> 2. More features for HDMI sound support - we need to implement Exynos ALSA
> SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit
> rate, and so on from user side should be sent to drm hdmi driver via ALSA
> interface and the ALSA SoC DAI driver. As of now, it seems like that we
> should implement this driver like OMAP does because there is no common
> framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver:
> in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces
> of DSS driver directly. I think we could implement ALSA SoC DAI driver in
> more generic way if we first implement common framework for it.
>
> Welcome to any volunteer and other opinions.
>
> Thanks,
> Inki Dae
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

> -Original Message-
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 3:21 AM
> To: Inki Dae
> Cc: Maarten Lankhorst; linux-fbdev; Kyungmin Park; DRI mailing list; Rob
> Clark; myungjoo.ham; YoungJun Cho; Daniel Vetter; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
> 
> On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> > It seems like that all pages of the scatterlist should be mapped with
> > DMA every time DMA operation  is started (or drm_xxx_set_src_dma_buffer
> > function call), and the pages should be unmapped from DMA again every
> > time DMA operation is completed: internally, including each cache
> > operation.
> 
> Correct.
> 
> > Isn't that big overhead?
> 
> Yes, if you _have_ to do a cache operation to ensure that the DMA agent
> can see the data the CPU has written.
> 
> > And If there is no problem, we should accept such overhead?
> 
> If there is no problem then why are we discussing this and why do we need
> this API extension? :)

Ok, another issue regardless of dmabuf-sync. Reasonable to me even though
big overhead. Besides, it seems like that most DRM drivers have same issue.
Therefore, we may need to solve this issue like below:
- do not map a dmabuf with DMA. And just create/update buffer object
of importer.
- map the buffer with DMA every time DMA start or iommu page fault
occurs.
- unmap the buffer from DMA every time DMA operation is completed

With the above approach, cache operation portion of my approach,
dmabuf-sync, can be removed. However, I'm not sure that we really have to
use the above approach with a big overhead. Of course, if we don't use the
above approach then user processes would need to do each cache operation
before DMA operation is started and also after DMA operation is completed in
some cases; user space mapped with physical memory as cachable, and CPU and
DMA share the same buffer.

So I'd like to ask for other DRM maintainers. How do you think about it? it
seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
Rob) and GEM CMA helper also have same issue Russell pointed out. I think
not only the above approach but also the performance is very important.

Thanks,
Inki Dae

> 
> > Actually, drm_gem_fd_to_handle() includes to map a
> > given dmabuf with iommu table (just logical data) of the DMA. And then,
> the
> > device address (or iova) already mapped will be set to buffer register
> of
> > the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.
> 
> Consider this with a PIPT cache:
> 
>   dma_map_sg()- at this point, the kernel addresses of these
>   buffers are cleaned and invalidated for the DMA
> 
>   userspace writes to the buffer, the data sits in the CPU cache
>   Because the cache is PIPT, this data becomes visible to the
>   kernel as well.
> 
>   DMA is started, and it writes to the buffer
> 
> Now, at this point, which is the correct data?  The data physically in the
> RAM which the DMA has written, or the data in the CPU cache.  It may
> the answer is - they both are, and the loss of either can be a potential
> data corruption issue - there is no way to tell which data should be
> kept but the system is in an inconsistent state and _one_ of them will
> have to be discarded.
> 
>   dma_unmap_sg()  - at this point, the kernel addresses of the
>   buffers are _invalidated_ and any data in those
>   cache lines is discarded
> 
> Which also means that the data in userspace will also be discarded with
> PIPT caches.
> 
> This is precisely why we have buffer rules associated with the DMA API,
> which are these:
> 
>   dma_map_sg()
>   - the buffer transfers ownership from the CPU to the DMA agent.
>   - the CPU may not alter the buffer in any way.
>   while (cpu_wants_access) {
>   dma_sync_sg_for_cpu()
>   - the buffer transfers ownership from the DMA to the CPU.
>   - the DMA may not alter the buffer in any way.
>   dma_sync_sg_for_device()
>   - the buffer transfers ownership from the CPU to the DMA
>   - the CPU may not alter the buffer in any way.
>   }
>   dma_unmap_sg()
>   - the buffer transfers ownership from the DMA to the CPU.
>   - the DMA may not alter the buffer in any way.
> 
> Any violation of that is likely to lead to data corruption.  Now, some
> may say that the DMA API is only about the kernel mapping.  Yes it is,
> because it takes no regard what so ever about what happens with the
> userspace mappings.  This is absolutely true when you have VIVT or
> aliasing VIPT caches.
> 
> Now consider that with a PIPT cache, or a non-aliasing VIPT cache (which
> is exactly the same behaviourally from this aspect) any 

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #69 from Marc Dietrich  ---
I mean it cannot find the intrinsic at all:

# ./Release/bin/llc < test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=r600
LLVM ERROR: Cannot select: 0x8a5570: f32 = fsin 0x8a5670 [ORD=2] [ID=3]
  0x8a5670: f32,ch = CopyFromReg 0x871928, 0x8a5970 [ID=2]
0x8a5970: f32 = Register %T0_X [ID=1]
In function: test

litte different with eg. -mcpu=hainan: 

# ./Release/bin/llc < test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=hainan
LLVM ERROR: Cannot select: target intrinsic %llvm.AMDGPU.store.output

-- 
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/20130618/64c9ab90/attachment-0001.html>

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Ville Syrjälä]

On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
> ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l? 
> >
> > Having both modes can be beneficial for video playback cases. If you can
> > match the video framerate exactly, and the audio and video clocks come
> > from the same source, you should be able to avoid dropped/repeated
> > frames without expensive operations such as resampling the audio to
> > match video output rate.
> >
> > Rather than add both variants based on the CEA extension short video
> > descriptors in do_cea_modes(), add only one variant there. Once all
> > the EDID has been fully probed, do a loop over the entire probed mode
> > list, during which we add the other variants for all modes that match
> > CEA modes. This allows us to match modes that didn't come via the CEA
> > short video descriptors. For example one Samsung TV here doesn't have
> > the 640x480-60 mode as a SVD, but instead it's specified via a detailed
> > timing descriptor.
> >
> > Signed-off-by: Ville Syrj?l? 
> > ---
> > A few people requested this. Originally I was a bit opposed to it, but
> > when I thought about it a bit more I figured if the audio and video
> > clocks come from the same source (or happen to be close enough w/o
> > significant drift), this could provide a better A/V sync w/o resampling
> > tricks.
> 
> I see this has gone in now, one thing I notice is that xorg/apps/xrandr 
> only prints Hz to 1dp so you can't see which mode is which for the 24p 
> and 30i cases.
> 
> Maybe someone reading has commit access for xorg?

Not sure if you noticed but I posted some relevant xrandr patches to
xorg-devel. Unfortunately I got no response, and I've been too lazy
to figure out who I need to pester.

-- 
Ville Syrj?l?
Intel OTC

linux-next: manual merge of the drm-intel tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_fb.c between commit b72447cdf129 ("drm/i915:
Drop bogus fbdev sprite disable code") from the drm tree and commit
b51b32cde175 ("drm/i915: s/drm_i915_private_t/struct drm_i915_private/")
from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_fb.c
index 3b03c3c,244060a..000
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@@ -291,7 -292,9 +292,7 @@@ void intel_fb_output_poll_changed(struc
  void intel_fb_restore_mode(struct drm_device *dev)
  {
int ret;
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
 -  struct drm_mode_config *config = >mode_config;
 -  struct drm_plane *plane;

if (INTEL_INFO(dev)->num_pipes == 0)
return;
-- 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/20130618/88fd9c3b/attachment-0001.pgp>

[PATCH] drm/tegra: Include linux/types.h

[Thierry Reding]

On Mon, Jun 17, 2013 at 11:04:59PM +0200, Paul Bolle wrote:
> On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote:
> > That has already been fixed in linux-next.
> 
> This header was added in v3.10-rc1. The fix in linux-next will ship in
> v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10
> release candidate(s)?

It's not really a bug and it can easily be worked around by including
linux/types.h explicitly. But you're right, there's still a chance of
getting this in before the final release of 3.10 and I can prepare a
pull request for Dave.

Thierry
-- 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/20130618/767bb829/attachment.pgp>

[PATCH v4 0/2] Enhance EDID quirks to allow forcing a mode

[Dylan Semler]

Checking up on this patch from a few months back that I'd like to get
included..  Acked by Daniel Vetter[1] and Reviewed by Jani Nikula[2].
 However ajax has not yet provided comments.  Is this SOL without feedback
from ajax?

[1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html
[2] http://lists.freedesktop.org/archives/dri-devel/2013-April/036829.html


On Mon, Mar 25, 2013 at 5:58 PM, Dylan Semler wrote:

> Changes in this version
>  * rename do_force_quirk_modes() -> do_force_quirk_mode()
>  * use list_for_each_entry() instead of list_for_each_entry_safe() in
>do_force_quirk_mode()
>  * remove num_modes from do_force_quirk_mode(), just return 1 or 0 as
>appropriate
>  * remove unused quirks argument from add_force_quirk_modes()
>  * fixes to allow cases of forcing multiple modes
>  * adjusted comments to adhere closer to style guides
>
> Changes in version 3
>  * Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline
>  * Adds bool to specify reduced blanking to edid_quirk_force_mode
>  * Removes preferred bit from all other modes
>
> Changes in version 2
>  * none
>
> There is at least one monitor that doesn't report its native resolution
> in its EDID block.  This enhancement extends the EDID quirk logic to
> make monitors like this "just work".
>
> The first patch in this series sets up a new quirk list where monitors'
> correct width, height, refresh rate, and reduced blanking parameters are
> specified.  When a matching monitor is attached the full mode is
> calculated with drm_cvt_mode() and added to the connector.  The
> DRM_MODE_TYPE_PREFERRED bit is set on the new mode and unset from all
> other modes.
>
> The first patch also defines a new quirk bit: EDID_QUIRK_FORCE_MODE.
> This bit needs to be set for the new quirk list described above to be
> checked.
>
> The second patch adds the offending monitor to the quirk lists.
>
> Dylan Semler (2):
>   drm: Enhance EDID quirks to explicitly set a mode
>   drm: Add EDID force quirk for MMT Monitor2Go HD+
>
>  drivers/gpu/drm/drm_edid.c | 89
> ++
>  1 file changed, 89 insertions(+)
>
> --
> 1.7.11.7
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/f791e077/attachment.html>

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #68 from Alex Deucher  ---
Trig functions need slightly different setup on r6xx and r7xx+.  See
tgsi_setup_trig() in r600_shader.c:

/*
 * r600 - trunc to -PI..PI range
 * r700 - normalize by dividing by 2PI
 * see fdo bug 27901
 */

-- 
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/20130618/1c3bd184/attachment.html>

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
[...]
> 
> > a display device driver.  It shouldn't be used within a single driver
> > as a means of passing buffers between userspace and kernel space.
> 
> What I try to do is not really such ugly thing. What I try to do is to
> notify that, when CPU tries to access a buffer , to kernel side through
> dmabuf interface. So it's not really to send the buffer to kernel.
> 
> Thanks,
> Inki Dae
> 
The most basic question about why you are trying to implement this sort
of thing in the dma_buf framework still stands.

Once you imported a dma_buf into your DRM driver it's a GEM object and
you can and should use the native DRM ioctls to prepare/end a CPU access
to this BO. Then internally to your driver you can use the dma_buf
reservation/fence stuff to provide the necessary cross-device sync.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Tue, Jun 18, 2013 at 09:00:16AM +0200, Daniel Vetter wrote:
> On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> > What we need is something along the lines of:
> > (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> > or
> > (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
> 
> I strongly vote for (b) (plus adding a dma_buf_map_sync interface to allow
> syncing to other devices/cpu whithout dropping the dma mappings). At least
> that's been the idea behind things, but currently all (x86-based) drm
> drivers cut corners here massively.
> 
> Aside: The entire reason behind hiding the dma map step in the dma-buf
> attachment is to allow drivers to expose crazy iommus (e.g. the tiler unit
> on omap) to other devices. So imo (a) isn't the right choice.

That's why I also talk below about adding the dma_buf_map/sync callbacks
below, so that a dma_buf implementation can do whatever is necessary with
the sg at the point of use.

However, you are correct that this should be unnecessary, as DRM should
only be calling dma_buf_map_attachment() when it needs to know about the
memory behind the object.  The problem is that people will cache that
information - it also may be expensive to setup for the dma_buf - as it
involves counting the number of pages, memory allocation, and maybe
obtaining the set of pages from shmem.

With (a) plus the callbacks below, it means that step is only performed
once, and then the DMA API part is entirely separate - we can have our
cake and eat it in that regard.

> > Note: the existing stuff does have the nice side effect of being able
> > to pass buffers which do not have a struct page * associated with them
> > through the dma_buf API - I think we can still preserve that by having
> > dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
> > but in any case we need to fix the existing API so that:
> >
> > dma_buf_map_attachment() becomes dma_buf_get_sg()
> > dma_buf_unmap_attachment() becomes dma_buf_put_sg()
> >
> > both getting rid of the DMA direction argument, and then we have four
> > new dma_buf calls:
> >
> > dma_buf_map_sg()
> > dma_buf_unmap_sg()
> > dma_buf_sync_sg_for_cpu()
> > dma_buf_sync_sg_for_device()
> >
> > which do the actual sg map/unmap via the DMA API *at the appropriate
> > time for DMA*.
> 
> Hm, my idea was to just add a dma_buf_sync_attchment for the device side
> syncing, since the cpu access stuff is already bracketed with the
> begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap,
> but imo mmap support for dma_buf is a bit insane anyway, so I don't care
> too much about it.
> 
> Since such dma mappings would be really longstanding in most cases anyway
> drivers could just map with BIDIRECTIONAL and do all the real flushing
> with the new sync stuff.

Note that the DMA API debug doesn't allow you to change the direction
argument on an existing mapping (neither should it, again this is
documented in the DMA API stuff in Documentation/).  This is where you
would need the complete set of four functions I mention above which
reflect the functionality of the DMA API.

The dma_buf implementation doesn't _have_ to implement them if they
are no-ops - for example, your dma_buf sg array contains DMA pointers,
and the memory is already coherent in some way (for example, it's a
separate chunk of memory which isn't part of system RAM.)

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Ville Syrj?l? wrote:
> On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
>> ville.syrjala at linux.intel.com wrote:
>>> From: Ville Syrj?l? 
>>>
>>> Having both modes can be beneficial for video playback cases. If you can
>>> match the video framerate exactly, and the audio and video clocks come
>>> from the same source, you should be able to avoid dropped/repeated
>>> frames without expensive operations such as resampling the audio to
>>> match video output rate.
>>>
>>> Rather than add both variants based on the CEA extension short video
>>> descriptors in do_cea_modes(), add only one variant there. Once all
>>> the EDID has been fully probed, do a loop over the entire probed mode
>>> list, during which we add the other variants for all modes that match
>>> CEA modes. This allows us to match modes that didn't come via the CEA
>>> short video descriptors. For example one Samsung TV here doesn't have
>>> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
>>> timing descriptor.
>>>
>>> Signed-off-by: Ville Syrj?l? 
>>> ---
>>> A few people requested this. Originally I was a bit opposed to it, but
>>> when I thought about it a bit more I figured if the audio and video
>>> clocks come from the same source (or happen to be close enough w/o
>>> significant drift), this could provide a better A/V sync w/o resampling
>>> tricks.
>>
>> I see this has gone in now, one thing I notice is that xorg/apps/xrandr
>> only prints Hz to 1dp so you can't see which mode is which for the 24p
>> and 30i cases.
>>
>> Maybe someone reading has commit access for xorg?
>
> Not sure if you noticed but I posted some relevant xrandr patches to
> xorg-devel. Unfortunately I got no response, and I've been too lazy
> to figure out who I need to pester.
>

Ahh, sorry I didn't see those, I just has a look at the current code to 
check it was still the same.

[patch] drm/i915: remove a superflous semi-colon

[Daniel Vetter]

On Tue, Jun 18, 2013 at 10:29:58AM +0300, Dan Carpenter wrote:
> This macro doesn't need a semi-colon.
>
> Signed-off-by: Dan Carpenter 
Queued for -next, thanks for the patch.
-Daniel

>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e5cc7c0..592b0eb9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1773,7 +1773,7 @@ int __i915_add_request(struct intel_ring_buffer *ring,
> struct drm_i915_gem_object *batch_obj,
> u32 *seqno);
>  #define i915_add_request(ring, seqno) \
> - __i915_add_request(ring, NULL, NULL, seqno);
> + __i915_add_request(ring, NULL, NULL, seqno)
>  int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
>   uint32_t seqno);
>  int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] radeon: Fix a false positive lockup after 10s of inactivity

[Andy Lutomirski]

On Thu, Jun 13, 2013 at 2:22 PM, Andy Lutomirski  wrote:
> On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse  wrote:
>> Andy can you test (without your patch) and see if it helps with your issue :
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-update-lockup-tracking-when-scheduling-in.patch
>
> Testing now.  I'll report back in a couple of days.
>

3.9.4 plus this patch has been completely stable for several days now.

Tested-by: Andy Lutomirski 

Can you send this to Linux and -stable?

Thanks,
Andy

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
>
> Having both modes can be beneficial for video playback cases. If you can
> match the video framerate exactly, and the audio and video clocks come
> from the same source, you should be able to avoid dropped/repeated
> frames without expensive operations such as resampling the audio to
> match video output rate.
>
> Rather than add both variants based on the CEA extension short video
> descriptors in do_cea_modes(), add only one variant there. Once all
> the EDID has been fully probed, do a loop over the entire probed mode
> list, during which we add the other variants for all modes that match
> CEA modes. This allows us to match modes that didn't come via the CEA
> short video descriptors. For example one Samsung TV here doesn't have
> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
> timing descriptor.
>
> Signed-off-by: Ville Syrj?l? 
> ---
> A few people requested this. Originally I was a bit opposed to it, but
> when I thought about it a bit more I figured if the audio and video
> clocks come from the same source (or happen to be close enough w/o
> significant drift), this could provide a better A/V sync w/o resampling
> tricks.

I see this has gone in now, one thing I notice is that xorg/apps/xrandr 
only prints Hz to 1dp so you can't see which mode is which for the 24p 
and 30i cases.

Maybe someone reading has commit access for xorg?

[PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem

[Rahul Sharma]

Hi Mr. Kukjin,

Kindly consider the following patches for review and integration.

regards,
Rahul Sharma.

On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K  
wrote:
> Hi,
> Tested this series on snow board and is working fine.
>
> Tested-by: Arun Kumar K 
>
> Regards
> Arun
>
> On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma  
> wrote:
>> Add clock changes for hdmi subsystem for exynos5250 SoC. These
>> include addition of new clocks like mout_hdmi and smmu_tv, associating
>> ID to clk_hdmiphy and some essential corrections.
>>
>> This set is based on kukjin's for-next branch at
>> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.
>>
>> Arun Kumar K (1):
>>   clk/exynos5250: Fix HDMI clock number in documentation
>>
>> Rahul Sharma (4):
>>   clk/exynos5250: add mout_hdmi mux clock for hdmi
>>   clk/exynos5250: add sclk_hdmiphy in the list of special clocks
>>   clk/exynos5250: add clock for tv sysmmu
>>   clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem
>>
>>  .../devicetree/bindings/clock/exynos5250-clock.txt   |   12 +++-
>>  drivers/clk/samsung/clk-exynos5250.c |   18 
>> +-
>>  2 files changed, 24 insertions(+), 6 deletions(-)
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Tue, Jun 18, 2013 at 06:04:44PM +0900, Inki Dae wrote:
> 
> 
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Tuesday, June 18, 2013 5:43 PM
> > To: Inki Dae
> > Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
> > list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
> > linux-arm-kernel at lists.infradead.org; linux-media at vger.kernel.org
> > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> > framework
> > 
> > On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> > > So I'd like to ask for other DRM maintainers. How do you think about it?
> > it
> > > seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained
> > by
> > > Rob) and GEM CMA helper also have same issue Russell pointed out. I
> > think
> > > not only the above approach but also the performance is very important.
> > 
> > CMA uses coherent memory to back their buffers, though that might not be
> > true of memory obtained from other drivers via dma_buf.  Plus, there is
> > no support in the CMA helper for exporting or importng these buffers.
> > 
> 
> It's not so. Please see Dave's drm next. recently dmabuf support for the CMA
> helper has been merged to there.

The point stands: CMA is DMA coherent memory.  It doesn't need and must
never be dma-map-sg'd or dma-sync'd or dma-unmap'd.

[patch] drm/i915: remove a superflous semi-colon

[Dan Carpenter]

This macro doesn't need a semi-colon.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e5cc7c0..592b0eb9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1773,7 +1773,7 @@ int __i915_add_request(struct intel_ring_buffer *ring,
   struct drm_i915_gem_object *batch_obj,
   u32 *seqno);
 #define i915_add_request(ring, seqno) \
-   __i915_add_request(ring, NULL, NULL, seqno);
+   __i915_add_request(ring, NULL, NULL, seqno)
 int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
 uint32_t seqno);
 int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);

[PATCH] drm/nouveau: remove limit on gart

[Ben Skeggs]

On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
 wrote:
> Most graphics cards nowadays have a multiple of this limit as their vram, so
> limiting GART doesn't seem to make much sense.
Pushed, thanks :)

>
> Signed-off-by: Maarten >Lnkhorst 
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 3a5e19a..41ddecd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -168,9 +168,6 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
> struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_mem *node;
>
> -   if (unlikely((mem->num_pages << PAGE_SHIFT) >= 512 * 1024 * 1024))
> -   return -ENOMEM;
> -
> node = kzalloc(sizeof(*node), GFP_KERNEL);
> if (!node)
> return -ENOMEM;
> @@ -406,8 +403,6 @@ nouveau_ttm_init(struct nouveau_drm *drm)
> /* GART init */
> if (drm->agp.stat != ENABLED) {
> drm->gem.gart_available = nouveau_vmmgr(drm->device)->limit;
> -   if (drm->gem.gart_available > 512 * 1024 * 1024)
> -   drm->gem.gart_available = 512 * 1024 * 1024;
> } else {
> drm->gem.gart_available = drm->agp.size;
> }
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> So I'd like to ask for other DRM maintainers. How do you think about it? it
> seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
> Rob) and GEM CMA helper also have same issue Russell pointed out. I think
> not only the above approach but also the performance is very important.

CMA uses coherent memory to back their buffers, though that might not be
true of memory obtained from other drivers via dma_buf.  Plus, there is
no support in the CMA helper for exporting or importng these buffers.

I guess Intel i915 is only used on x86, which is a coherent platform and
requires no cache maintanence for DMA.

OMAP DRM does not support importing non-DRM buffers buffers back into
DRM.  Moreover, it will suffer from the problems I described if any
attempt is made to write to the buffer after it has been re-imported.

Lastly, I should point out that the dma_buf stuff is really only useful
when you need to export a dma buffer from one driver and import it into
another driver - for example to pass data from a camera device driver to
a display device driver.  It shouldn't be used within a single driver
as a means of passing buffers between userspace and kernel space.

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Daniel Vetter]

On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux 
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> > space as cachable)
> >
> > handle1 = drm_gem_fd_to_handle(a dmabuf fd);  > 1
> >  ...
> > va1 = drm_gem_mmap(handle1);
> > va2 = drm_gem_mmap(handle2);
> > va3 = malloc(size);
> >  ...
> >
> > while (conditions) {
> >  memcpy(va1, some data, size);
>
> No!
>
> Well, the first thing to say here is that under the requirements of the
> DMA API, the above is immediately invalid, because you're writing to a
> buffer which under the terms of the DMA API is currently owned by the
> DMA agent, *not* by the CPU.  You're supposed to call dma_sync_sg_for_cpu()
> before you do that - but how is userspace supposed to know that requirement?
> Why should userspace even _have_ to know these requirements of the DMA
> API?
>
> It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
> causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
> into userspace is a bug too, as it has the potential to touch caches or
> stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
> going to make too big a deal about that, because I don't think we have
> anything that picky.
>
> However, the first point above is the most important one, and exposing
> the quirks of the DMA API to userland is certainly not a nice thing to be
> doing.  This needs to be fixed - we can't go and enforce an API which is
> deeply embedded within the kernel all the way out to userland.
>
> What we need is something along the lines of:
> (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> or
> (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.

I strongly vote for (b) (plus adding a dma_buf_map_sync interface to allow
syncing to other devices/cpu whithout dropping the dma mappings). At least
that's been the idea behind things, but currently all (x86-based) drm
drivers cut corners here massively.

Aside: The entire reason behind hiding the dma map step in the dma-buf
attachment is to allow drivers to expose crazy iommus (e.g. the tiler unit
on omap) to other devices. So imo (a) isn't the right choice.
>
> and for the scatterlist to be mapped for DMA at the point where the DMA
> operation is initiated, and unmapped at the point where the DMA operation
> is complete.
>
> So no, the problem is not that we need more APIs and code - we need the
> existing kernel API fixed so that we don't go exposing userspace to the
> requirements of the DMA API.  Unless we do that, we're going to end
> up with a huge world of pain, where kernel architecture people need to
> audit every damned DRM userspace implementation that happens to be run
> on their platform, and that's not something arch people really can
> afford to do.
>
> Basically, I think the dma_buf stuff needs to be rewritten with the
> requirements of the DMA API in the forefront of whosever mind is doing
> the rewriting.
>
> Note: the existing stuff does have the nice side effect of being able
> to pass buffers which do not have a struct page * associated with them
> through the dma_buf API - I think we can still preserve that by having
> dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
> but in any case we need to fix the existing API so that:
>
> dma_buf_map_attachment() becomes dma_buf_get_sg()
> dma_buf_unmap_attachment() becomes dma_buf_put_sg()
>
> both getting rid of the DMA direction argument, and then we have four
> new dma_buf calls:
>
> dma_buf_map_sg()
> dma_buf_unmap_sg()
> dma_buf_sync_sg_for_cpu()
> dma_buf_sync_sg_for_device()
>
> which do the actual sg map/unmap via the DMA API *at the appropriate
> time for DMA*.

Hm, my idea was to just add a dma_buf_sync_attchment for the device side
syncing, since the cpu access stuff is already bracketed with the
begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap,
but imo mmap support for dma_buf is a bit insane anyway, so I don't care
too much about it.

Since such dma mappings would be really longstanding in most cases anyway
drivers could just map with BIDIRECTIONAL and do all the real flushing
with the new sync stuff.

Another piece of fun will be integration with the fencing stuff Maarten is
doing. I'm not sure whether we should integrate that into the dma-buf
interface (for simple users who don't want to deal with the full
complexity at least).

>
> So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
> to be utterly broken in design for architectures such as ARM where the
> requirements of the DMA API have to be 

[PATCH 0/3] fbdev no more!

[Daniel Vetter]

On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk
 wrote:
> On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> So I've taken a look again at the locking mess in our fbdev support and 
>> cried.
>> Fixing up the console_lock mess around the fbdev notifier will be real work,
>> semanatically the fbdev layer does lots of stupid things (like the radeon 
>> resume
>> issue I've just debugged) and the panic notifier is pretty much a lost cause.
>>
>> So I've decided to instead rip it all out. It seems to work \o/
>
>
> When you say 'locking mess in our fbdev support' you mean the general
> core fbdev driver? Not neccessarily the i915 driver?
>
> I am asking b/c that would imply that the other fbdev drivers still hit
> the locking mess?

Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon
locking proliferates console_lock protected sections like mad. Which
means that the initial modeset (for fbcon) is all done with the
console_lock held. Which makes debugging things in that rather tricky
code a mess. So nothing i915-specifc.
-Daniel

>
> Thanks!
>>
>> Of course a general purpose distro propably wants David's kmscon for any
>> fallbacks needs and a system compositor to ditch the VT subsystem - atm my
>> machine here runs with the dummy console so that VT switching between 
>> different
>> X sessions still works ;-)
>>
>> Oh and: At least fedora's boot splash seems to be unhappy about the lack of 
>> an
>> fbdev (it doesn't seem to do anything), which breaks early disk encryption a
>> bit. The black screen itself shouldn't be a big issue at least for i915, 
>> since
>> with all the fastboot work we can just hang onto the current config and
>> framebuffer (one missing patch from Chris for the fb preservartion). So as 
>> long
>> as the bios/grub put up something nice, it'll look ok.
>>
>> So just a small step here really, but imo into the right direction. Now, 
>> please
>> bring on the flames!
>>
>> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd
>> like to wait for a bit of feedback first. And one more: This also removes the
>> console_lock completely from our critical path in suspend/resume!
>>
>> One thing I haven't wasted a single thought about is kgdb and panic notifier
>> support. But since the current code is pretty decently broken already (we 
>> have
>> _tons_ of mutex grabbing and waits in there) I don't think people care that 
>> much
>> about it anyway. Using a sprite to smash the kgdb/panic output on top of
>> whatever's currently displaying might be an approach.
>>
>> Cheers, Daniel
>>
>> Daniel Vetter (3):
>>   drm: Add separate Kconfig option for fbdev helpers
>>   drm/i915: Kconfig option to disable the legacy fbdev support
>>   drm/i915: rename intel_fb.c to intel_fbdev.c
>>
>>  drivers/gpu/drm/Kconfig  |  57 ++-
>>  drivers/gpu/drm/Makefile |   3 +-
>>  drivers/gpu/drm/ast/Kconfig  |   1 +
>>  drivers/gpu/drm/cirrus/Kconfig   |   1 +
>>  drivers/gpu/drm/exynos/Kconfig   |   1 +
>>  drivers/gpu/drm/gma500/Kconfig   |   1 +
>>  drivers/gpu/drm/i915/Kconfig |  56 +++
>>  drivers/gpu/drm/i915/Makefile|   3 +-
>>  drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
>>  drivers/gpu/drm/i915/i915_dma.c  |   8 +-
>>  drivers/gpu/drm/i915/i915_drv.h  |   2 +
>>  drivers/gpu/drm/i915/intel_display.c |  12 +-
>>  drivers/gpu/drm/i915/intel_drv.h |  39 -
>>  drivers/gpu/drm/i915/intel_fb.c  | 314 
>> ---
>>  drivers/gpu/drm/i915/intel_fbdev.c   | 314 
>> +++
>>  drivers/gpu/drm/mgag200/Kconfig  |   1 +
>>  drivers/gpu/drm/nouveau/Kconfig  |   1 +
>>  drivers/gpu/drm/omapdrm/Kconfig  |   1 +
>>  drivers/gpu/drm/qxl/Kconfig  |   1 +
>>  drivers/gpu/drm/shmobile/Kconfig |   1 +
>>  drivers/gpu/drm/tilcdc/Kconfig   |   1 +
>>  drivers/gpu/drm/udl/Kconfig  |   1 +
>>  drivers/gpu/host1x/drm/Kconfig   |   1 +
>>  drivers/staging/imx-drm/Kconfig  |   1 +
>>  24 files changed, 452 insertions(+), 373 deletions(-)
>>  create mode 100644 drivers/gpu/drm/i915/Kconfig
>>  delete mode 100644 drivers/gpu/drm/i915/intel_fb.c
>>  create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c
>>
>> --
>> 1.7.11.7
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 0/3] fbdev no more!

[David Herrmann]

Hi

On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski  
wrote:
> On 06/16/2013 07:57 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> So I've taken a look again at the locking mess in our fbdev support and 
>> cried.
>> Fixing up the console_lock mess around the fbdev notifier will be real work,
>> semanatically the fbdev layer does lots of stupid things (like the radeon 
>> resume
>> issue I've just debugged) and the panic notifier is pretty much a lost cause.
>>
>> So I've decided to instead rip it all out. It seems to work \o/
>
> I wonder how badly this breaks on EFI systems.  Currently, efifb is an
> fbdev driver.  When i915 calls register_framebuffer, the fbdev core
> removes efifb's framebuffer.  (This is scary already -- what if i915 has
> reused that memory for something else beforehand?)  But now, if i915
> doesn't call register_framebuffer, the efifb "framebuffer" might stick
> around forever.

See the i915 Patch (2/3). It still calls
remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will
kick out efifb regardless whether i915-fbdev support is enabled or
not.

> Presumably, efifb ought to become a framebuffer-only drm driver and
> there should be a saner way to hand control from efifb (or vesa?) to a
> real driver.

Already working on it.

Regards
David

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

2013/6/18 Russell King - ARM Linux 

> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux 
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that CPU and DMA share a buffer and the buffer is mapped with
> user
> > space as cachable)
> >
> > handle1 = drm_gem_fd_to_handle(a dmabuf fd);  > 1
> >  ...
> > va1 = drm_gem_mmap(handle1);
> > va2 = drm_gem_mmap(handle2);
> > va3 = malloc(size);
> >  ...
> >
> > while (conditions) {
> >  memcpy(va1, some data, size);
>
> No!
>
> Well, the first thing to say here is that under the requirements of the
> DMA API, the above is immediately invalid, because you're writing to a
> buffer which under the terms of the DMA API is currently owned by the
> DMA agent, *not* by the CPU.  You're supposed to call dma_sync_sg_for_cpu()
> before you do that - but how is userspace supposed to know that
> requirement?
> Why should userspace even _have_ to know these requirements of the DMA
> API?
>
> It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
> causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
> into userspace is a bug too, as it has the potential to touch caches or
> stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
> going to make too big a deal about that, because I don't think we have
> anything that picky.
>
> However, the first point above is the most important one, and exposing
> the quirks of the DMA API to userland is certainly not a nice thing to be
> doing.  This needs to be fixed - we can't go and enforce an API which is
> deeply embedded within the kernel all the way out to userland.
>
> What we need is something along the lines of:
> (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> or
> (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
>
> and for the scatterlist to be mapped for DMA at the point where the DMA
> operation is initiated, and unmapped at the point where the DMA operation
> is complete.
>

It seems like that all pages of the scatterlist should be mapped with
DMA every time DMA operation  is started (or drm_xxx_set_src_dma_buffer
function call), and the pages should be unmapped from DMA again every
time DMA operation is completed: internally, including each cache
operation. Isn't that big overhead? And If there is no problem, we should
accept such overhead? Actually, drm_gem_fd_to_handle() includes to map a
given dmabuf with iommu table (just logical data) of the DMA. And then, the
device address (or iova) already mapped will be set to buffer register of
the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.

Thanks,
Inki Dae


>
> So no, the problem is not that we need more APIs and code - we need the
> existing kernel API fixed so that we don't go exposing userspace to the
> requirements of the DMA API.  Unless we do that, we're going to end
> up with a huge world of pain, where kernel architecture people need to
> audit every damned DRM userspace implementation that happens to be run
> on their platform, and that's not something arch people really can
> afford to do.
>
> Basically, I think the dma_buf stuff needs to be rewritten with the
> requirements of the DMA API in the forefront of whosever mind is doing
> the rewriting.
>
> Note: the existing stuff does have the nice side effect of being able
> to pass buffers which do not have a struct page * associated with them
> through the dma_buf API - I think we can still preserve that by having
> dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
> but in any case we need to fix the existing API so that:
>
> dma_buf_map_attachment() becomes dma_buf_get_sg()
> dma_buf_unmap_attachment() becomes dma_buf_put_sg()
>
> both getting rid of the DMA direction argument, and then we have four
> new dma_buf calls:
>
> dma_buf_map_sg()
> dma_buf_unmap_sg()
> dma_buf_sync_sg_for_cpu()
> dma_buf_sync_sg_for_device()
>
> which do the actual sg map/unmap via the DMA API *at the appropriate
> time for DMA*.
>
> So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
> to be utterly broken in design for architectures such as ARM where the
> requirements of the DMA API have to be followed if you're going to have
> a happy life.
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/7711fdf9/attachment.html>

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

een CPU and DMA.
> Making sure caching works correctly can be handled entirely in the
> begin_cpu_access/end_cpu_access callbacks, without requiring such..
> framework


Cache work will be handled by the begin_cpu_access/end_cpu_access
callbacks, actually by dmabuf exporter side. Could you give me your
comments again after reading my answer to Ressell? I'd like to make you
understand what I try to do.


> >> I'm not going into a full review, you may wish to rethink the design
> > first.
> >> All the criticisms I had with the original design approach still apply.
> >>
> > Isn't that enough if what I try to do is similar to android sync driver?
> > It's very simple and that's all I try to do.:)
> From what I can tell you should be able to make it work with just the use
> of fences, you don't need to keep the buffers locked for the entire
> duration,
> just plug in the last fence in the correct slots and  you're done..
>

I'm afraid that I don't understand what you say. My approach doesn't use
dma fence stuff anymore. Maybe it seems missing something. Could you show
me simple example? A little summary is ok. Otherwise, where I can refer
to example codes?

Thanks,
Inki Dae


>



I'm not sure if the android sync api is compatible enough, but you
> shouldn't need to write code in this way to make it work..
> >>
> >> A few things that stand out from a casual glance:
> >>
> >> bool is_dmabuf_sync_supported(void)
> >> -> any code that needs CONFIG_DMABUF_SYNC should select it in their
> >> kconfig
> >> runtime enabling/disabling of synchronization is a recipe for disaster,
> >> remove the !CONFIG_DMABUF_SYNC fallbacks.
> >> NEVER add a runtime way to influence locking behavior.
> >>
> > Not enabling/disabling synchronization feature in runtime. That is
> > determined at build time.
> >
> >> Considering you're also holding dmaobj->lock for the entire duration, is
> >> there any point to not simply call begin_cpu_access/end_cpu_access, and
> >> forget this ugly code ever existed?
> > You mean mutex_lock(>lock)? Yeah, it seems unnecessary in that
> case.
> >
> >> I still don't see the problem you're trying to solve..
> >>
> > It's just to implement a thin sync framework coupling cache operation.
> This
> > approach is based on dma-buf for more generic implementation against
> android
> > sync driver or KDS.
> >
> > The described steps may be summarized as:
> >   lock -> cache operation -> CPU or DMA access to a buffer/s ->
> unlock
> >
> > I think that there is no need to get complicated for such approach at
> least
> > for most devices sharing system memory. Simple is best.
> >
> >
> > Thanks,
> > Inki Dae
> >
> >> ~Maarten
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/59086e46/attachment-0001.html>

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

--- Comment #2 from Aaron Watry  ---
Created attachment 80972
  --> https://bugs.freedesktop.org/attachment.cgi?id=80972=edit
Output from llc -debug-only=isel --march=r600 --mcpu=verde < vload-int.ll

-- 
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/20130618/3bbf381a/attachment.html>

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

--- Comment #1 from Aaron Watry  ---
Created attachment 80971
  --> https://bugs.freedesktop.org/attachment.cgi?id=80971=edit
LLVM assembly that is produced from the vload-int.cl test case

-- 
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/20130618/27a59044/attachment.html>

[Bug 65873] New: R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

  Priority: medium
Bug ID: 65873
  Assignee: dri-devel at lists.freedesktop.org
   Summary: R600/SI: Cannot select store with truncate to 32-bit
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: awatry at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 80970
  --> https://bugs.freedesktop.org/attachment.cgi?id=80970=edit
Piglit test that triggers the error on SI

Running the attached piglit CL test, I'm getting the following on R600/SI
(Pitcairn, 7850):

LLVM ERROR: Cannot select: 0x2add8b0: ch = store 0x2add7b0, 0x2adcfb0,
0x2adc640, 0x2adbd40<ST4[%out+4], trunc to i32> [ORD=4] [ID=17]
  0x2adcfb0: i64,ch = load 0x20468b8, 0x2add1b0, 0x2adbd40<LD4[%mem+4], zext
from i32> [ORD=1] [ID=14]
0x2add1b0: i64 = add 0x2adc140, 0x2adc540 [ORD=1] [ID=11]
  0x2adc140: i64,ch = load 0x20468b8, 0x2adc040, 0x2adbd40<LD8[undef]>
[ID=9]
0x2adc040: i64 = add 0x2adba40, 0x2adbf40 [ID=7]
  0x2adba40: i64,ch = CopyFromReg 0x20468b8, 0x2adb940 [ID=6]
0x2adb940: i64 = Register %vreg0 [ID=1]
  0x2adbf40: i64 = Constant<44> [ID=4]
0x2adbd40: i64 = undef [ID=3]
  0x2adc540: i64 = Constant<4> [ID=5]
0x2adbd40: i64 = undef [ID=3]
  0x2adc640: i64 = add 0x2adbe40, 0x2adc540 [ORD=4] [ID=13]
0x2adbe40: i64,ch = load 0x20468b8, 0x2adbc40, 0x2adbd40<LD8[undef]>
[ID=10]
  0x2adbc40: i64 = add 0x2adba40, 0x2adbb40 [ID=8]
0x2adba40: i64,ch = CopyFromReg 0x20468b8, 0x2adb940 [ID=6]
  0x2adb940: i64 = Register %vreg0 [ID=1]
0x2adbb40: i64 = Constant<36> [ID=2]
  0x2adbd40: i64 = undef [ID=3]
0x2adc540: i64 = Constant<4> [ID=5]
  0x2adbd40: i64 = undef [ID=3]


I'll attach a dump from llc -debug-only=isel in a minute.

-- 
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/20130618/8bd6117d/attachment.html>

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

2013/6/17 Russell King - ARM Linux 

> On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote:
> > It's just to implement a thin sync framework coupling cache operation.
> This
> > approach is based on dma-buf for more generic implementation against
> android
> > sync driver or KDS.
> >
> > The described steps may be summarized as:
> >   lock -> cache operation -> CPU or DMA access to a buffer/s ->
> unlock
> >
> > I think that there is no need to get complicated for such approach at
> least
> > for most devices sharing system memory. Simple is best.
>
> But hang on, doesn't the dmabuf API already provide that?
>
> The dmabuf API already uses dma_map_sg() and dma_unmap_sg() by providers,
> and the rules around the DMA API are that:
>
> dma_map_sg()
> /* DMA _ONLY_ has access, CPU should not access */
> dma_unmap_sg()
> /* DMA may not access, CPU can access */
>
> It's a little more than that if you include the sync_sg_for_cpu and
> sync_sg_for_device APIs too - but the above is the general idea.  What
> this means from the dmabuf API point of view is that once you attach to
> a dma_buf, and call dma_buf_map_attachment() to get the SG list, the CPU
> doesn't have ownership of the buffer and _must_ _not_ access it via any
> other means - including using the other dma_buf methods, until either
> the appropriate dma_sync_sg_for_cpu() call has been made or the DMA
> mapping has been removed via dma_buf_unmap_attachment().
>
> So, the sequence should be:
>
> dma_buf_map_attachment()
> /* do DMA */
> dma_buf_unmap_attachment()
> /* CPU can now access the buffer */
>

Exactly right. But that is not definitely my point. Could you please see
the below simple example?:
(Presume that CPU and DMA share a buffer and the buffer is mapped with user
space as cachable)

handle1 = drm_gem_fd_to_handle(a dmabuf fd);  > 1
 ...
va1 = drm_gem_mmap(handle1);
va2 = drm_gem_mmap(handle2);
va3 = malloc(size);
 ...

while (conditions) {
 memcpy(va1, some data, size);
 ...
 drm_xxx_set_src_dma_buffer(handle1, ...);
 ...
 drm_xxx_set_dst_dma_buffer(handle2, ...);
 ...
 /* user need to request cache clean at here. */   > 2
 ...
 /* blocked until dma operation is completed. */
drm_xxx_start_dma(...);
 ...
 /* user need to request cache invalidate at here. */ >
3
memcpy(va3, va2, size);
}

gem_close(handle1); -> 4



dma_buf_map_attachment() is called by number 1 and
dma_buf_unmap_attachement() is called by number 4. However, how about
number 2 and number 3? My point is those. As I already mentioned through a
document file, user prcesses would need to request repeatedly cache
operation, number 2 and 3 as long as the conditions is true because kernel
side cannot be aware of when cpu accesses a shard buffer in this case. And
such codes could be used by user app here and there. However, we cannot
prevent such app from requesting excessive cache operations although such
app are overusing cache operations unnecessarily. So my approach is just
initial idea to prevent the overuse of cache operation: with this approach,
all cache operations are done in kernel side and that is why I try to
coulpe cache operation and buffer synchronization between CPU and DMA.

Thanks,
Inki Dae


> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/b0467ba3/attachment.html>

[PATCH] drm/tegra: Include linux/types.h

[Paul Bolle]

On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote:
> That has already been fixed in linux-next.

This header was added in v3.10-rc1. The fix in linux-next will ship in
v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10
release candidate(s)?

Thanks,


Paul Bolle

[Bug 65822] [radeonsi] OpenCL is broken

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65822

--- Comment #3 from Aaron Watry  ---
Created attachment 80969
  --> https://bugs.freedesktop.org/attachment.cgi?id=80969=edit
Shader dumps from a radeon 7850 for test cases in attachment 80967

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [PATCH 0/3] fbdev no more!

[David Herrmann]

Hi

On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski l...@amacapital.net wrote:
 On 06/16/2013 07:57 AM, Daniel Vetter wrote:
 Hi all,

 So I've taken a look again at the locking mess in our fbdev support and 
 cried.
 Fixing up the console_lock mess around the fbdev notifier will be real work,
 semanatically the fbdev layer does lots of stupid things (like the radeon 
 resume
 issue I've just debugged) and the panic notifier is pretty much a lost cause.

 So I've decided to instead rip it all out. It seems to work \o/

 I wonder how badly this breaks on EFI systems.  Currently, efifb is an
 fbdev driver.  When i915 calls register_framebuffer, the fbdev core
 removes efifb's framebuffer.  (This is scary already -- what if i915 has
 reused that memory for something else beforehand?)  But now, if i915
 doesn't call register_framebuffer, the efifb framebuffer might stick
 around forever.

See the i915 Patch (2/3). It still calls
remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will
kick out efifb regardless whether i915-fbdev support is enabled or
not.

 Presumably, efifb ought to become a framebuffer-only drm driver and
 there should be a saner way to hand control from efifb (or vesa?) to a
 real driver.

Already working on it.

Regards
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

exynos-drm-next todo work.

[Inki Dae]

Hi all,

I'd like to discuss Exynos DRM TODO work.

There are features we have to solve and implement. The purpose of this email
is to share what we have to do so that other guys can be involved without
duplicated work.

1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler
device instead of VP device. And now exynos drm driver has gscaler module as
a sub module of IPP framework. However, this gscaler module is very specific
to IPP framework so it's not easy to reuse this module. So maybe we need so
many works for it.

Video play back path using post process (AS IS):
MFCIPPKMS-FIMD or HDMI

Ideal video play back path using post process (TO BE):
MFCKMSFIMD or HDMI

The above scenario is to send decoded image data (YUV format) to display
device via post process. However, we don't really need to use IPP framework
in case of using gscaler as VP. All we have to do is to call kms interface
(setplane) for it like we did before.

2. More features for HDMI sound support - we need to implement Exynos ALSA
SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit
rate, and so on from user side should be sent to drm hdmi driver via ALSA
interface and the ALSA SoC DAI driver. As of now, it seems like that we
should implement this driver like OMAP does because there is no common
framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver:
in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces
of DSS driver directly. I think we could implement ALSA SoC DAI driver in
more generic way if we first implement common framework for it.

Welcome to any volunteer and other opinions.

Thanks,
Inki Dae

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] fbdev no more!

[Daniel Vetter]

On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
 On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
 Hi all,

 So I've taken a look again at the locking mess in our fbdev support and 
 cried.
 Fixing up the console_lock mess around the fbdev notifier will be real work,
 semanatically the fbdev layer does lots of stupid things (like the radeon 
 resume
 issue I've just debugged) and the panic notifier is pretty much a lost cause.

 So I've decided to instead rip it all out. It seems to work \o/


 When you say 'locking mess in our fbdev support' you mean the general
 core fbdev driver? Not neccessarily the i915 driver?

 I am asking b/c that would imply that the other fbdev drivers still hit
 the locking mess?

Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon
locking proliferates console_lock protected sections like mad. Which
means that the initial modeset (for fbcon) is all done with the
console_lock held. Which makes debugging things in that rather tricky
code a mess. So nothing i915-specifc.
-Daniel


 Thanks!

 Of course a general purpose distro propably wants David's kmscon for any
 fallbacks needs and a system compositor to ditch the VT subsystem - atm my
 machine here runs with the dummy console so that VT switching between 
 different
 X sessions still works ;-)

 Oh and: At least fedora's boot splash seems to be unhappy about the lack of 
 an
 fbdev (it doesn't seem to do anything), which breaks early disk encryption a
 bit. The black screen itself shouldn't be a big issue at least for i915, 
 since
 with all the fastboot work we can just hang onto the current config and
 framebuffer (one missing patch from Chris for the fb preservartion). So as 
 long
 as the bios/grub put up something nice, it'll look ok.

 So just a small step here really, but imo into the right direction. Now, 
 please
 bring on the flames!

 Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd
 like to wait for a bit of feedback first. And one more: This also removes the
 console_lock completely from our critical path in suspend/resume!

 One thing I haven't wasted a single thought about is kgdb and panic notifier
 support. But since the current code is pretty decently broken already (we 
 have
 _tons_ of mutex grabbing and waits in there) I don't think people care that 
 much
 about it anyway. Using a sprite to smash the kgdb/panic output on top of
 whatever's currently displaying might be an approach.

 Cheers, Daniel

 Daniel Vetter (3):
   drm: Add separate Kconfig option for fbdev helpers
   drm/i915: Kconfig option to disable the legacy fbdev support
   drm/i915: rename intel_fb.c to intel_fbdev.c

  drivers/gpu/drm/Kconfig  |  57 ++-
  drivers/gpu/drm/Makefile |   3 +-
  drivers/gpu/drm/ast/Kconfig  |   1 +
  drivers/gpu/drm/cirrus/Kconfig   |   1 +
  drivers/gpu/drm/exynos/Kconfig   |   1 +
  drivers/gpu/drm/gma500/Kconfig   |   1 +
  drivers/gpu/drm/i915/Kconfig |  56 +++
  drivers/gpu/drm/i915/Makefile|   3 +-
  drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
  drivers/gpu/drm/i915/i915_dma.c  |   8 +-
  drivers/gpu/drm/i915/i915_drv.h  |   2 +
  drivers/gpu/drm/i915/intel_display.c |  12 +-
  drivers/gpu/drm/i915/intel_drv.h |  39 -
  drivers/gpu/drm/i915/intel_fb.c  | 314 
 ---
  drivers/gpu/drm/i915/intel_fbdev.c   | 314 
 +++
  drivers/gpu/drm/mgag200/Kconfig  |   1 +
  drivers/gpu/drm/nouveau/Kconfig  |   1 +
  drivers/gpu/drm/omapdrm/Kconfig  |   1 +
  drivers/gpu/drm/qxl/Kconfig  |   1 +
  drivers/gpu/drm/shmobile/Kconfig |   1 +
  drivers/gpu/drm/tilcdc/Kconfig   |   1 +
  drivers/gpu/drm/udl/Kconfig  |   1 +
  drivers/gpu/host1x/drm/Kconfig   |   1 +
  drivers/staging/imx-drm/Kconfig  |   1 +
  24 files changed, 452 insertions(+), 373 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/Kconfig
  delete mode 100644 drivers/gpu/drm/i915/intel_fb.c
  create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c

 --
 1.7.11.7

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Daniel Vetter]

On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
 On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
  2013/6/17 Russell King - ARM Linux li...@arm.linux.org.uk
  Exactly right. But that is not definitely my point. Could you please see
  the below simple example?:
  (Presume that CPU and DMA share a buffer and the buffer is mapped with user
  space as cachable)
 
  handle1 = drm_gem_fd_to_handle(a dmabuf fd);   1
   ...
  va1 = drm_gem_mmap(handle1);
  va2 = drm_gem_mmap(handle2);
  va3 = malloc(size);
   ...
 
  while (conditions) {
   memcpy(va1, some data, size);

 No!

 Well, the first thing to say here is that under the requirements of the
 DMA API, the above is immediately invalid, because you're writing to a
 buffer which under the terms of the DMA API is currently owned by the
 DMA agent, *not* by the CPU.  You're supposed to call dma_sync_sg_for_cpu()
 before you do that - but how is userspace supposed to know that requirement?
 Why should userspace even _have_ to know these requirements of the DMA
 API?

 It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
 causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
 into userspace is a bug too, as it has the potential to touch caches or
 stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
 going to make too big a deal about that, because I don't think we have
 anything that picky.

 However, the first point above is the most important one, and exposing
 the quirks of the DMA API to userland is certainly not a nice thing to be
 doing.  This needs to be fixed - we can't go and enforce an API which is
 deeply embedded within the kernel all the way out to userland.

 What we need is something along the lines of:
 (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
 or
 (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.

I strongly vote for (b) (plus adding a dma_buf_map_sync interface to allow
syncing to other devices/cpu whithout dropping the dma mappings). At least
that's been the idea behind things, but currently all (x86-based) drm
drivers cut corners here massively.

Aside: The entire reason behind hiding the dma map step in the dma-buf
attachment is to allow drivers to expose crazy iommus (e.g. the tiler unit
on omap) to other devices. So imo (a) isn't the right choice.

 and for the scatterlist to be mapped for DMA at the point where the DMA
 operation is initiated, and unmapped at the point where the DMA operation
 is complete.

 So no, the problem is not that we need more APIs and code - we need the
 existing kernel API fixed so that we don't go exposing userspace to the
 requirements of the DMA API.  Unless we do that, we're going to end
 up with a huge world of pain, where kernel architecture people need to
 audit every damned DRM userspace implementation that happens to be run
 on their platform, and that's not something arch people really can
 afford to do.

 Basically, I think the dma_buf stuff needs to be rewritten with the
 requirements of the DMA API in the forefront of whosever mind is doing
 the rewriting.

 Note: the existing stuff does have the nice side effect of being able
 to pass buffers which do not have a struct page * associated with them
 through the dma_buf API - I think we can still preserve that by having
 dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
 but in any case we need to fix the existing API so that:

 dma_buf_map_attachment() becomes dma_buf_get_sg()
 dma_buf_unmap_attachment() becomes dma_buf_put_sg()

 both getting rid of the DMA direction argument, and then we have four
 new dma_buf calls:

 dma_buf_map_sg()
 dma_buf_unmap_sg()
 dma_buf_sync_sg_for_cpu()
 dma_buf_sync_sg_for_device()

 which do the actual sg map/unmap via the DMA API *at the appropriate
 time for DMA*.

Hm, my idea was to just add a dma_buf_sync_attchment for the device side
syncing, since the cpu access stuff is already bracketed with the
begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap,
but imo mmap support for dma_buf is a bit insane anyway, so I don't care
too much about it.

Since such dma mappings would be really longstanding in most cases anyway
drivers could just map with BIDIRECTIONAL and do all the real flushing
with the new sync stuff.

Another piece of fun will be integration with the fencing stuff Maarten is
doing. I'm not sure whether we should integrate that into the dma-buf
interface (for simple users who don't want to deal with the full
complexity at least).


 So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
 to be utterly broken in design for architectures such as ARM where the
 requirements of the DMA API have to be followed if you're going to have
 a happy life.

Agreed. Unfortunately there are 

[patch] drm/i915: remove a superflous semi-colon

[Dan Carpenter]

This macro doesn't need a semi-colon.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e5cc7c0..592b0eb9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1773,7 +1773,7 @@ int __i915_add_request(struct intel_ring_buffer *ring,
   struct drm_i915_gem_object *batch_obj,
   u32 *seqno);
 #define i915_add_request(ring, seqno) \
-   __i915_add_request(ring, NULL, NULL, seqno);
+   __i915_add_request(ring, NULL, NULL, seqno)
 int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
 uint32_t seqno);
 int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

 -Original Message-
 From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
 Sent: Tuesday, June 18, 2013 5:43 PM
 To: Inki Dae
 Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
 list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
 linux-arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org
 Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
 framework
 
 On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
  So I'd like to ask for other DRM maintainers. How do you think about it?
 it
  seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained
 by
  Rob) and GEM CMA helper also have same issue Russell pointed out. I
 think
  not only the above approach but also the performance is very important.
 
 CMA uses coherent memory to back their buffers, though that might not be
 true of memory obtained from other drivers via dma_buf.  Plus, there is
 no support in the CMA helper for exporting or importng these buffers.
 

It's not so. Please see Dave's drm next. recently dmabuf support for the CMA
helper has been merged to there.

 I guess Intel i915 is only used on x86, which is a coherent platform and
 requires no cache maintanence for DMA.
 
 OMAP DRM does not support importing non-DRM buffers buffers back into

Correct. TODO yet.

 DRM.  Moreover, it will suffer from the problems I described if any
 attempt is made to write to the buffer after it has been re-imported.
 
 Lastly, I should point out that the dma_buf stuff is really only useful
 when you need to export a dma buffer from one driver and import it into
 another driver - for example to pass data from a camera device driver to

Most people know that.

 a display device driver.  It shouldn't be used within a single driver
 as a means of passing buffers between userspace and kernel space.

What I try to do is not really such ugly thing. What I try to do is to
notify that, when CPU tries to access a buffer , to kernel side through
dmabuf interface. So it's not really to send the buffer to kernel.

Thanks,
Inki Dae

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] drm/i915: remove a superflous semi-colon

[Daniel Vetter]

On Tue, Jun 18, 2013 at 10:29:58AM +0300, Dan Carpenter wrote:
 This macro doesn't need a semi-colon.

 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Queued for -next, thanks for the patch.
-Daniel


 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index e5cc7c0..592b0eb9 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1773,7 +1773,7 @@ int __i915_add_request(struct intel_ring_buffer *ring,
 struct drm_i915_gem_object *batch_obj,
 u32 *seqno);
  #define i915_add_request(ring, seqno) \
 - __i915_add_request(ring, NULL, NULL, seqno);
 + __i915_add_request(ring, NULL, NULL, seqno)
  int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
   uint32_t seqno);
  int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: exynos-drm-next todo work.

[Rahul Sharma]

Hi Mr. Dae,

Related to HDMI sound support in Alsa, I have posted a working RFC
exynos-hdmi to CDF complaint display driver. It registers a separate
sound card by registering hdmi audio codec dai and cpu-dai, as you
mentioned. But there is a problem with this approach that I2S being the
single cpu dai for HDMI and Speaker sound card, only one card can
support playback at a time.

I would like to work on this to provide a more refined solution.

regards,
Rahul Sharma.

On Tue, Jun 18, 2013 at 12:03 PM, Inki Dae inki@samsung.com wrote:
 Hi all,

 I'd like to discuss Exynos DRM TODO work.

 There are features we have to solve and implement. The purpose of this email
 is to share what we have to do so that other guys can be involved without
 duplicated work.

 1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler
 device instead of VP device. And now exynos drm driver has gscaler module as
 a sub module of IPP framework. However, this gscaler module is very specific
 to IPP framework so it's not easy to reuse this module. So maybe we need so
 many works for it.

 Video play back path using post process (AS IS):
 MFCIPPKMS-FIMD or HDMI

 Ideal video play back path using post process (TO BE):
 MFCKMSFIMD or HDMI

 The above scenario is to send decoded image data (YUV format) to display
 device via post process. However, we don't really need to use IPP framework
 in case of using gscaler as VP. All we have to do is to call kms interface
 (setplane) for it like we did before.

 2. More features for HDMI sound support - we need to implement Exynos ALSA
 SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit
 rate, and so on from user side should be sent to drm hdmi driver via ALSA
 interface and the ALSA SoC DAI driver. As of now, it seems like that we
 should implement this driver like OMAP does because there is no common
 framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver:
 in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces
 of DSS driver directly. I think we could implement ALSA SoC DAI driver in
 more generic way if we first implement common framework for it.

 Welcome to any volunteer and other opinions.

 Thanks,
 Inki Dae

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
[...]
 
  a display device driver.  It shouldn't be used within a single driver
  as a means of passing buffers between userspace and kernel space.
 
 What I try to do is not really such ugly thing. What I try to do is to
 notify that, when CPU tries to access a buffer , to kernel side through
 dmabuf interface. So it's not really to send the buffer to kernel.
 
 Thanks,
 Inki Dae
 
The most basic question about why you are trying to implement this sort
of thing in the dma_buf framework still stands.

Once you imported a dma_buf into your DRM driver it's a GEM object and
you can and should use the native DRM ioctls to prepare/end a CPU access
to this BO. Then internally to your driver you can use the dma_buf
reservation/fence stuff to provide the necessary cross-device sync.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Rahul Sharma]

Thanks all,

On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com wrote:
 Hello Kishon,

 On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
 Hi,

 On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:


 -Original Message-
 From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com]
 Sent: Thursday, June 13, 2013 5:56 PM
 To: Rahul Sharma
 Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org;
 devicetree-
 disc...@lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim;
 Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
 grant.lik...@linaro.org
 Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with
 pmu reg control

 Hi,

 On 06/13/2013 06:26 AM, Rahul Sharma wrote:
 Mr. Dae,

 Thanks for your valuable inputs.

 I posted it as RFC because, I also have received comments to register
 hdmiphy as a clock controller. As we always configure it for specific
 frequency, hdmi-phy looks similar to a PLL. But it really doesn't
 belong to that class. Secondly prior to exynos5420, it was a i2c
 device. I am not sure we can register a I2C device as a clock
 controller. I wanted to discuss and explore this option here.

 Have you considered using the generic PHY framework for those HDMI
 PHY devices [1] ? I guess we could add a dedicated group of ops for
 video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
 configuring things like the carrier/pixel clock frequency or anything
 what's common across the video PHYs.

 Perhaps you could have a look and see if this framework would be
 useful for HDMI and possibly point out anything what might be missing ?

 I'm not sure it it really solves the issues specific to the Exynos
 HDMI but at least with a generic PHY driver the PHY module would be
 separate from the PHY controller, as often same HDMI DPHY can be used
 with various types of a HDMI controller. So this would allow to not
 duplicate the HDMI PHY drivers in the long-term perspective.

 Yeah, at least, it seems that we could use PHY module to control PMU
 register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off
 callbacks. As you may know, HDMIPHY needs i2c interfaces to control
 HDMIPHY
 clock. So with PHY module, HDMIPHY driver could enable PMU more
 generically,
 but also has to use existing i2c stuff to control HDMIPHY clock. I had a
 quick review to Generic PHY Framework[v6] but I didn't see that the PHY
 module could generically support more features such as i2c stuff.

 I don't think PHY framework needs to provide i2c interfaces to program
 certain configurations. Instead in one of the callbacks (init/on/off)
 PHY driver can program whatever it wants using any of the interfaces it
 needs. IMO PHY framework should work independent of the interfaces.

 In exnoys hdmi case, i2c interface is not the exact issue. In exynos
 hdmi, hdmiphy should send i2c configuration about video clock
 information as the video mode information including resolution, bit per
 pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
 of phy framework are not enough for exynos hdmiphy and it should have a
 callback to set video mode.

 Do you have plan to add driver specific extend callback pointers to phy
 framework?

 Currently, hdmi directly calls phy operations, but Rahul's another patch
 set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is
 connected with exynos hdmi own sub driver callback operations.

 IMHO, if phy framework can support extend callback feature, then this
 own sub driver callbacks can be replaced with phy framework at long term
 view.

Extended callbacks are always welcome. I can also use phy device
private data to pass on private ops like get_pixelclk and set_pixelclk.
Similar logic has been used to pass struct omap_usb to usb phy
controller. I can add these changes for migration of hdmiphy to
generic phy framwork to my hdmiphy separation patch set.

regards,
Rahul Sharma.


 Thanks and Regards,
 - Seung-Woo Kim


 For example, twl4030 phy driver actually uses i2c to program its
 registers but still it uses the PHY framework [1].

 [1] -- http://www.gossamer-threads.com/lists/linux/kernel/1729414

 Thanks
 Kishon
 --
 To unsubscribe from this list: send the line unsubscribe
 linux-samsung-soc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


 --
 Seung-Woo Kim
 Samsung Software RD Center
 --

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
A few people requested this. Originally I was a bit opposed to it, but
when I thought about it a bit more I figured if the audio and video
clocks come from the same source (or happen to be close enough w/o
significant drift), this could provide a better A/V sync w/o resampling
tricks.


I see this has gone in now, one thing I notice is that xorg/apps/xrandr 
only prints Hz to 1dp so you can't see which mode is which for the 24p 
and 30i cases.


Maybe someone reading has commit access for xorg?



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Ville Syrjälä]

On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
 ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
 
  Having both modes can be beneficial for video playback cases. If you can
  match the video framerate exactly, and the audio and video clocks come
  from the same source, you should be able to avoid dropped/repeated
  frames without expensive operations such as resampling the audio to
  match video output rate.
 
  Rather than add both variants based on the CEA extension short video
  descriptors in do_cea_modes(), add only one variant there. Once all
  the EDID has been fully probed, do a loop over the entire probed mode
  list, during which we add the other variants for all modes that match
  CEA modes. This allows us to match modes that didn't come via the CEA
  short video descriptors. For example one Samsung TV here doesn't have
  the 640x480-60 mode as a SVD, but instead it's specified via a detailed
  timing descriptor.
 
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
  A few people requested this. Originally I was a bit opposed to it, but
  when I thought about it a bit more I figured if the audio and video
  clocks come from the same source (or happen to be close enough w/o
  significant drift), this could provide a better A/V sync w/o resampling
  tricks.
 
 I see this has gone in now, one thing I notice is that xorg/apps/xrandr 
 only prints Hz to 1dp so you can't see which mode is which for the 24p 
 and 30i cases.
 
 Maybe someone reading has commit access for xorg?

Not sure if you noticed but I posted some relevant xrandr patches to
xorg-devel. Unfortunately I got no response, and I've been too lazy
to figure out who I need to pester.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Ville Syrjälä wrote:

On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:

ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
A few people requested this. Originally I was a bit opposed to it, but
when I thought about it a bit more I figured if the audio and video
clocks come from the same source (or happen to be close enough w/o
significant drift), this could provide a better A/V sync w/o resampling
tricks.


I see this has gone in now, one thing I notice is that xorg/apps/xrandr
only prints Hz to 1dp so you can't see which mode is which for the 24p
and 30i cases.

Maybe someone reading has commit access for xorg?


Not sure if you noticed but I posted some relevant xrandr patches to
xorg-devel. Unfortunately I got no response, and I've been too lazy
to figure out who I need to pester.



Ahh, sorry I didn't see those, I just has a look at the current code to 
check it was still the same.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tegra: Include linux/types.h

[Thierry Reding]

On Mon, Jun 17, 2013 at 11:04:59PM +0200, Paul Bolle wrote:
 On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote:
  That has already been fixed in linux-next.
 
 This header was added in v3.10-rc1. The fix in linux-next will ship in
 v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10
 release candidate(s)?

It's not really a bug and it can easily be worked around by including
linux/types.h explicitly. But you're right, there's still a chance of
getting this in before the final release of 3.10 and I can prepare a
pull request for Dave.

Thierry


pgpaajq6D5HTg.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
 So I'd like to ask for other DRM maintainers. How do you think about it? it
 seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
 Rob) and GEM CMA helper also have same issue Russell pointed out. I think
 not only the above approach but also the performance is very important.

CMA uses coherent memory to back their buffers, though that might not be
true of memory obtained from other drivers via dma_buf.  Plus, there is
no support in the CMA helper for exporting or importng these buffers.

I guess Intel i915 is only used on x86, which is a coherent platform and
requires no cache maintanence for DMA.

OMAP DRM does not support importing non-DRM buffers buffers back into
DRM.  Moreover, it will suffer from the problems I described if any
attempt is made to write to the buffer after it has been re-imported.

Lastly, I should point out that the dma_buf stuff is really only useful
when you need to export a dma buffer from one driver and import it into
another driver - for example to pass data from a camera device driver to
a display device driver.  It shouldn't be used within a single driver
as a means of passing buffers between userspace and kernel space.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Tue, Jun 18, 2013 at 06:04:44PM +0900, Inki Dae wrote:
 
 
  -Original Message-
  From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
  Sent: Tuesday, June 18, 2013 5:43 PM
  To: Inki Dae
  Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
  list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
  linux-arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org
  Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
  framework
  
  On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
   So I'd like to ask for other DRM maintainers. How do you think about it?
  it
   seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained
  by
   Rob) and GEM CMA helper also have same issue Russell pointed out. I
  think
   not only the above approach but also the performance is very important.
  
  CMA uses coherent memory to back their buffers, though that might not be
  true of memory obtained from other drivers via dma_buf.  Plus, there is
  no support in the CMA helper for exporting or importng these buffers.
  
 
 It's not so. Please see Dave's drm next. recently dmabuf support for the CMA
 helper has been merged to there.

The point stands: CMA is DMA coherent memory.  It doesn't need and must
never be dma-map-sg'd or dma-sync'd or dma-unmap'd.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Tue, Jun 18, 2013 at 09:00:16AM +0200, Daniel Vetter wrote:
 On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
  What we need is something along the lines of:
  (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
  or
  (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
 
 I strongly vote for (b) (plus adding a dma_buf_map_sync interface to allow
 syncing to other devices/cpu whithout dropping the dma mappings). At least
 that's been the idea behind things, but currently all (x86-based) drm
 drivers cut corners here massively.
 
 Aside: The entire reason behind hiding the dma map step in the dma-buf
 attachment is to allow drivers to expose crazy iommus (e.g. the tiler unit
 on omap) to other devices. So imo (a) isn't the right choice.

That's why I also talk below about adding the dma_buf_map/sync callbacks
below, so that a dma_buf implementation can do whatever is necessary with
the sg at the point of use.

However, you are correct that this should be unnecessary, as DRM should
only be calling dma_buf_map_attachment() when it needs to know about the
memory behind the object.  The problem is that people will cache that
information - it also may be expensive to setup for the dma_buf - as it
involves counting the number of pages, memory allocation, and maybe
obtaining the set of pages from shmem.

With (a) plus the callbacks below, it means that step is only performed
once, and then the DMA API part is entirely separate - we can have our
cake and eat it in that regard.

  Note: the existing stuff does have the nice side effect of being able
  to pass buffers which do not have a struct page * associated with them
  through the dma_buf API - I think we can still preserve that by having
  dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
  but in any case we need to fix the existing API so that:
 
  dma_buf_map_attachment() becomes dma_buf_get_sg()
  dma_buf_unmap_attachment() becomes dma_buf_put_sg()
 
  both getting rid of the DMA direction argument, and then we have four
  new dma_buf calls:
 
  dma_buf_map_sg()
  dma_buf_unmap_sg()
  dma_buf_sync_sg_for_cpu()
  dma_buf_sync_sg_for_device()
 
  which do the actual sg map/unmap via the DMA API *at the appropriate
  time for DMA*.
 
 Hm, my idea was to just add a dma_buf_sync_attchment for the device side
 syncing, since the cpu access stuff is already bracketed with the
 begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap,
 but imo mmap support for dma_buf is a bit insane anyway, so I don't care
 too much about it.
 
 Since such dma mappings would be really longstanding in most cases anyway
 drivers could just map with BIDIRECTIONAL and do all the real flushing
 with the new sync stuff.

Note that the DMA API debug doesn't allow you to change the direction
argument on an existing mapping (neither should it, again this is
documented in the DMA API stuff in Documentation/).  This is where you
would need the complete set of four functions I mention above which
reflect the functionality of the DMA API.

The dma_buf implementation doesn't _have_ to implement them if they
are no-ops - for example, your dma_buf sg array contains DMA pointers,
and the memory is already coherent in some way (for example, it's a
separate chunk of memory which isn't part of system RAM.)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/9] drm/exynos: use of_get_named_gpio to get hdmi hpd gpio

[Rahul Sharma]

Thanks Mr. Dae,

Please discard the REST of the patches in this series. I am posting a
another patch-set which has all the patches independent of hdmiphy
related changes.

regards,
Rahul Sharma.

On Mon, Jun 17, 2013 at 8:22 AM, Inki Dae inki@samsung.com wrote:
 Applied.

 Thanks,
 Inki Dae


 2013/6/14 김승우 sw0312@samsung.com

 Hello Rahul,

 this patch is not related with others and it looks good to me.

 On 2013년 06월 11일 23:11, Rahul Sharma wrote:
  Cleanup by removing flags variable from drm_hdmi_dt_parse_pdata
  which is not used anywhere. Swtiching to of_get_named_gpio instead
  of of_get_named_gpio_flags solved this.
 
  Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

 Acked-by: Seung-Woo Kim sw0312@samsung.com

  ---
   drivers/gpu/drm/exynos/exynos_hdmi.c |3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
  b/drivers/gpu/drm/exynos/exynos_hdmi.c
  index 1eb5ffb..fc6a9b0 100644
  --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
  +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
  @@ -2081,7 +2081,6 @@ static struct s5p_hdmi_platform_data
  *drm_hdmi_dt_parse_pdata
   {
struct device_node *np = dev-of_node;
struct s5p_hdmi_platform_data *pd;
  - enum of_gpio_flags flags;
u32 value;
 
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
  @@ -2095,7 +2094,7 @@ static struct s5p_hdmi_platform_data
  *drm_hdmi_dt_parse_pdata
goto err_data;
}
 
  - pd-hpd_gpio = of_get_named_gpio_flags(np, hpd-gpio, 0, flags);
  + pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
 
return pd;
 
 

 --
 Seung-Woo Kim
 Samsung Software RD Center
 --

 --
 To unsubscribe from this list: send the line unsubscribe
 linux-samsung-soc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #68 from Alex Deucher ag...@yahoo.com ---
Trig functions need slightly different setup on r6xx and r7xx+.  See
tgsi_setup_trig() in r600_shader.c:

/*
 * r600 - trunc to -PI..PI range
 * r700 - normalize by dividing by 2PI
 * see fdo bug 27901
 */

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Kishon Vijay Abraham I]

Hi,

On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
 Thanks all,
 
 On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com wrote:
 Hello Kishon,

 On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
 Hi,

 On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:


 -Original Message-
 From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com]
 Sent: Thursday, June 13, 2013 5:56 PM
 To: Rahul Sharma
 Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org;
 devicetree-
 disc...@lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim;
 Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
 grant.lik...@linaro.org
 Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with
 pmu reg control

 Hi,

 On 06/13/2013 06:26 AM, Rahul Sharma wrote:
 Mr. Dae,

 Thanks for your valuable inputs.

 I posted it as RFC because, I also have received comments to register
 hdmiphy as a clock controller. As we always configure it for specific
 frequency, hdmi-phy looks similar to a PLL. But it really doesn't
 belong to that class. Secondly prior to exynos5420, it was a i2c
 device. I am not sure we can register a I2C device as a clock
 controller. I wanted to discuss and explore this option here.

 Have you considered using the generic PHY framework for those HDMI
 PHY devices [1] ? I guess we could add a dedicated group of ops for
 video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
 configuring things like the carrier/pixel clock frequency or anything
 what's common across the video PHYs.

 Perhaps you could have a look and see if this framework would be
 useful for HDMI and possibly point out anything what might be missing ?

 I'm not sure it it really solves the issues specific to the Exynos
 HDMI but at least with a generic PHY driver the PHY module would be
 separate from the PHY controller, as often same HDMI DPHY can be used
 with various types of a HDMI controller. So this would allow to not
 duplicate the HDMI PHY drivers in the long-term perspective.

 Yeah, at least, it seems that we could use PHY module to control PMU
 register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off
 callbacks. As you may know, HDMIPHY needs i2c interfaces to control
 HDMIPHY
 clock. So with PHY module, HDMIPHY driver could enable PMU more
 generically,
 but also has to use existing i2c stuff to control HDMIPHY clock. I had a
 quick review to Generic PHY Framework[v6] but I didn't see that the PHY
 module could generically support more features such as i2c stuff.

 I don't think PHY framework needs to provide i2c interfaces to program
 certain configurations. Instead in one of the callbacks (init/on/off)
 PHY driver can program whatever it wants using any of the interfaces it
 needs. IMO PHY framework should work independent of the interfaces.

 In exnoys hdmi case, i2c interface is not the exact issue. In exynos
 hdmi, hdmiphy should send i2c configuration about video clock
 information as the video mode information including resolution, bit per
 pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
 of phy framework are not enough for exynos hdmiphy and it should have a
 callback to set video mode.

 Do you have plan to add driver specific extend callback pointers to phy
 framework?

 Currently, hdmi directly calls phy operations, but Rahul's another patch
 set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is
 connected with exynos hdmi own sub driver callback operations.

 IMHO, if phy framework can support extend callback feature, then this
 own sub driver callbacks can be replaced with phy framework at long term
 view.
 
 Extended callbacks are always welcome. I can also use phy device
 private data to pass on private ops like get_pixelclk and set_pixelclk.

I would recommend creating a wrapper to the existing PHY framework
for HDMI PHY. That way, we can have other HDMI phys added
easily. We need to figure out all the ops that might be needed by the
HDMI PHY to be added to the wrapper.
IMO extended callbacks can lead to abuse of the system and should be
used only when absolutely necessary.

Thanks
Kishon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] exynos5420/hdmi: add support for hdmi subsystem

[Rahul Sharma]

Add support for exynos5420 hdmi subsystem. It adds compatible strings
for exynos5420 mixer and Changes the drivers as per IP modifications.

This set doesn't have changes for hdmiphy, which will posted
independently.

This set is based on drm-next branch of Inki Dae's tree at
http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git.

Rahul Sharma (4):
  drm/exynos: rename compatible strings for hdmi subsystem
  drm/exynos: add support for exynos5420 mixer
  drm/exynos: fix interlace resolutions for exynos5420
  ARM/dts: change compatible strings for hdmi subsystem

 .../devicetree/bindings/video/exynos_hdmi.txt  |6 +-
 .../devicetree/bindings/video/exynos_hdmiddc.txt   |4 +-
 .../devicetree/bindings/video/exynos_hdmiphy.txt   |6 +-
 .../devicetree/bindings/video/exynos_mixer.txt |7 ++-
 arch/arm/boot/dts/cros5250-common.dtsi |4 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +-
 arch/arm/boot/dts/exynos5250.dtsi  |4 +-
 drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   16 ++---
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +-
 drivers/gpu/drm/exynos/exynos_mixer.c  |   61 ++--
 drivers/gpu/drm/exynos/regs-mixer.h|7 +++
 12 files changed, 84 insertions(+), 41 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Rahul Sharma]

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
 Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
 Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
 Documentation/devicetree/bindings/video/exynos_mixer.txt   |7 +--
 drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |2 +-
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
 drivers/gpu/drm/exynos/exynos_mixer.c  |   12 ++--
 8 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..2ac01ca 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,9 @@
 Device-Tree bindings for drm hdmi driver
 
 Required properties:
-- compatible: value should be samsung,exynos5-hdmi.
+- compatible: value should be one among the following:
+   1) samsung,exynos4210-hdmi
+   2) samsung,exynos4212-hdmi
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
@@ -15,7 +17,7 @@ Required properties:
 Example:
 
hdmi {
-   compatible = samsung,exynos5-hdmi;
+   compatible = samsung,exynos4212-hdmi;
reg = 0x1453 0x10;
interrupts = 0 95 0;
hpd-gpio = gpx3 7 0xf 1 3;
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
index fa166d9..c1bd2ea 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -1,12 +1,12 @@
 Device-Tree bindings for hdmiddc driver
 
 Required properties:
-- compatible: value should be samsung,exynos5-hdmiddc.
+- compatible: value should be samsung,exynos4210-hdmiddc.
 - reg: I2C address of the hdmiddc device.
 
 Example:
 
hdmiddc {
-   compatible = samsung,exynos5-hdmiddc;
+   compatible = samsung,exynos4210-hdmiddc;
reg = 0x50;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
index 858f4f9..e59d793 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -1,12 +1,14 @@
 Device-Tree bindings for hdmiphy driver
 
 Required properties:
-- compatible: value should be samsung,exynos5-hdmiphy.
+- compatible: value should be
+   1) samsung,exynos4210-hdmiphy.
+   2) samsung,exynos4212-hdmiphy.
 - reg: I2C address of the hdmiphy device.
 
 Example:
 
hdmiphy {
-   compatible = samsung,exynos5-hdmiphy;
+   compatible = samsung,exynos4210-hdmiphy;
reg = 0x38;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..a8b063f 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -1,7 +1,10 @@
 Device-Tree bindings for mixer driver
 
 Required properties:
-- compatible: value should be samsung,exynos5-mixer.
+- compatible: value should be:
+   1) samsung,exynos4210-mixer
+   2) samsung,exynos5250-mixer
+
 - reg: physical base address of the mixer and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
@@ -9,7 +12,7 @@ Required properties:
 Example:
 
mixer {
-   compatible = samsung,exynos5-mixer;
+   compatible = samsung,exynos5250-mixer;
reg = 0x1445 0x1;
interrupts = 0 94 0;
};
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 4e9b5ba..1a0cca1 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -51,7 +51,7 @@ static struct i2c_device_id ddc_idtable[] = {
 #ifdef CONFIG_OF
 static struct of_device_id hdmiddc_match_types[] = {
{
-   .compatible = samsung,exynos5-hdmiddc,
+   .compatible = samsung,exynos4210-hdmiddc,
}, {
/* end node */
}
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 743059f..8752171 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ 

[PATCH 2/4] drm/exynos: add support for exynos5420 mixer

[Rahul Sharma]

Add support for exynos5420 mixer IP in the drm mixer driver.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_mixer.c |   49 +
 drivers/gpu/drm/exynos/regs-mixer.h   |7 +
 2 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2fe6d33..d51ff36 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
 enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+   MXR_VER_128_0_0_184,
 };
 
 struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
val = (ctx-interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);
 
-   /* choosing between porper HD and SD mode */
-   if (height = 480)
-   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height = 576)
-   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height = 720)
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height = 1080)
-   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
-   else
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   if (ctx-mxr_ver != MXR_VER_128_0_0_184) {
+   /* choosing between proper HD and SD mode */
+   if (height = 480)
+   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+   else if (height = 576)
+   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+   else if (height = 720)
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   else if (height = 1080)
+   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+   else
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   }
 
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
 }
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data-fb_width);
 
+   /* setup display size */
+   if (ctx-mxr_ver == MXR_VER_128_0_0_184 
+   win == MIXER_DEFAULT_WIN) {
+   val  = MXR_MXR_RES_HEIGHT(win_data-fb_height);
+   val |= MXR_MXR_RES_WIDTH(win_data-fb_width);
+   mixer_reg_write(res, MXR_RESOLUTION, val);
+   }
+
val  = MXR_GRP_WH_WIDTH(win_data-crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data-crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
mixer_cfg_layer(ctx, win, true);
 
/* layer update mandatory for mixer 16.0.33.0 */
-   if (ctx-mxr_ver == MXR_VER_16_0_33_0)
+   if (ctx-mxr_ver == MXR_VER_16_0_33_0 ||
+   ctx-mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);
 
mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
 
 static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
 {
+   struct mixer_context *mixer_ctx = ctx;
u32 w, h;
 
w = mode-hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
drm_display_mode *mode)
mode-hdisplay, mode-vdisplay, mode-vrefresh,
(mode-flags  DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
 
+   if (mixer_ctx-mxr_ver == MXR_VER_0_0_0_16 ||
+   mixer_ctx-mxr_ver == MXR_VER_128_0_0_184)
+   return 0;
+
if ((w = 464  w = 720  h = 261  h = 576) ||
(w = 1024  w = 1280  h = 576  h = 720) ||
(w = 1664  w = 1920  h = 936  h = 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
exynos_drm_hdmi_context *ctx,
return 0;
 }
 
+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+   .version = MXR_VER_128_0_0_184,
+   .is_vp_enabled = 0,
+};
+
 static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1139,6 +1161,9 @@ static struct platform_device_id mixer_driver_types[] = {
 
 static struct of_device_id mixer_match_types[] = {
{
+   .compatible = samsung,exynos5420-mixer,
+   .data   = exynos5420_mxr_drv_data,
+   }, {
.compatible = samsung,exynos5250-mixer,
.data   = exynos5250_mxr_drv_data,
}, {
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h 
b/drivers/gpu/drm/exynos/regs-mixer.h
index 5d8dbc0..4537026 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -44,6 +44,9 @@
 #define MXR_CM_COEFF_Y 0x0080
 #define MXR_CM_COEFF_CB  

[PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420

[Rahul Sharma]

Modified code for calculating hdmi IP register values from drm timing
values. The modification is based on the inputs from hw team and specifically
proposed for 1440x576i and 1440x480i. But same changes holds good for other
interlaced resolutions also.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8752171..2f807d5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
(m-vsync_start - m-vdisplay) / 2);
hdmi_set_reg(core-v2_blank, 2, m-vtotal / 2);
hdmi_set_reg(core-v1_blank, 2, (m-vtotal - m-vdisplay) / 2);
-   hdmi_set_reg(core-v_blank_f0, 2, (m-vtotal +
-   ((m-vsync_end - m-vsync_start) * 4) + 5) / 2);
+   hdmi_set_reg(core-v_blank_f0, 2, m-vtotal - m-vdisplay / 2);
hdmi_set_reg(core-v_blank_f1, 2, m-vtotal);
hdmi_set_reg(core-v_sync_line_aft_2, 2, (m-vtotal / 2) + 7);
hdmi_set_reg(core-v_sync_line_aft_1, 2, (m-vtotal / 2) + 2);
@@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
(m-htotal / 2) + (m-hsync_start - m-hdisplay));
hdmi_set_reg(tg-vact_st, 2, (m-vtotal - m-vdisplay) / 2);
hdmi_set_reg(tg-vact_sz, 2, m-vdisplay / 2);
-   hdmi_set_reg(tg-vact_st2, 2, 0x249);/* Reset value + 1*/
+   hdmi_set_reg(tg-vact_st2, 2, m-vtotal - m-vdisplay / 2);
+   hdmi_set_reg(tg-vsync2, 2, (m-vtotal / 2) + 1);
+   hdmi_set_reg(tg-vsync_bot_hdmi, 2, (m-vtotal / 2) + 1);
+   hdmi_set_reg(tg-field_bot_hdmi, 2, (m-vtotal / 2) + 1);
hdmi_set_reg(tg-vact_st3, 2, 0x0);
hdmi_set_reg(tg-vact_st4, 2, 0x0);
} else {
@@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdmi_set_reg(tg-vact_st2, 2, 0x248); /* Reset value */
hdmi_set_reg(tg-vact_st3, 2, 0x47b); /* Reset value */
hdmi_set_reg(tg-vact_st4, 2, 0x6ae); /* Reset value */
+   hdmi_set_reg(tg-vsync2, 2, 0x233); /* Reset value */
+   hdmi_set_reg(tg-vsync_bot_hdmi, 2, 0x233); /* Reset value */
+   hdmi_set_reg(tg-field_bot_hdmi, 2, 0x233); /* Reset value */
}
 
/* Following values  calculations are same irrespective of mode type */
@@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdmi_set_reg(tg-hact_sz, 2, m-hdisplay);
hdmi_set_reg(tg-v_fsz, 2, m-vtotal);
hdmi_set_reg(tg-vsync, 2, 0x1);
-   hdmi_set_reg(tg-vsync2, 2, 0x233); /* Reset value */
hdmi_set_reg(tg-field_chg, 2, 0x233); /* Reset value */
hdmi_set_reg(tg-vsync_top_hdmi, 2, 0x1); /* Reset value */
-   hdmi_set_reg(tg-vsync_bot_hdmi, 2, 0x233); /* Reset value */
hdmi_set_reg(tg-field_top_hdmi, 2, 0x1); /* Reset value */
-   hdmi_set_reg(tg-field_bot_hdmi, 2, 0x233); /* Reset value */
hdmi_set_reg(tg-tg_3d, 1, 0x0);
 }
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] ARM/dts: change compatible strings for hdmi subsystem

[Rahul Sharma]

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
 arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
 arch/arm/boot/dts/exynos5250.dtsi |4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq = 66000;
 
hdmiddc@50 {
-   compatible = samsung,exynos5-hdmiddc;
+   compatible = samsung,exynos4210-hdmiddc;
reg = 0x50;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq = 378000;
 
hdmiphy@38 {
-   compatible = samsung,exynos5-hdmiphy;
+   compatible = samsung,exynos4212-hdmiphy;
reg = 0x38;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq = 66000;
 
hdmiddc@50 {
-   compatible = samsung,exynos5-hdmiddc;
+   compatible = samsung,exynos4210-hdmiddc;
reg = 0x50;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq = 66000;
 
hdmiphy@38 {
-   compatible = samsung,exynos5-hdmiphy;
+   compatible = samsung,exynos4212-hdmiphy;
reg = 0x38;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};
 
hdmi {
-   compatible = samsung,exynos5-hdmi;
+   compatible = samsung,exynos4212-hdmi;
reg = 0x1453 0x7;
interrupts = 0 95 0;
clocks = clock 333, clock 136, clock 137,
@@ -611,7 +611,7 @@
};
 
mixer {
-   compatible = samsung,exynos5-mixer;
+   compatible = samsung,exynos5250-mixer;
reg = 0x1445 0x1;
interrupts = 0 94 0;
};
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider

[Rahul Sharma]

With this patch, it is at par with Exynos5250 and Exynos4 clocks
where sclk_pixel ID is assigned to a divider clock but in real,
sclk_pixel is listed under gate clocks (enum value).

Alternate to this, I can allocate a new ID, div_pixel, listed under
new category of Divider Clocks for Exyno4, 5250 and 5420.
div_pixel ID can be assigned to pixel clock dividers for all 3 SoCs.
This ID can be accessed by hdmi driver as usual. While sclk_pixel
ID can be left unused for Exyno4, 5250 as there are no pixel clock
gates. And, For 5420, sclk_pixel can optionally be used to
enable/disable the pixel clock gate.

Regards,
Rahul Sharma.

On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma rahul.sha...@samsung.com wrote:
 sclk_pixel is used to represent pixel clock divider on all exynos
 SoCs not as a gate clock. It is queried in driver to pass as the
 parent to hdmi clock while switching between parents. A new ID can
 be asssigned Pixel gate clock which is currently not in use. Pixel
 clock gate is default 'on'.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  drivers/clk/samsung/clk-exynos5420.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/clk/samsung/clk-exynos5420.c 
 b/drivers/clk/samsung/clk-exynos5420.c
 index 59cf177..edd0696 100644
 --- a/drivers/clk/samsung/clk-exynos5420.c
 +++ b/drivers/clk/samsung/clk-exynos5420.c
 @@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata 
 = {
 DIV(none, dout_fimd1, mout_fimd1, DIV_DISP10, 0, 4),
 DIV(none, dout_mipi1, mout_mipi1, DIV_DISP10, 16, 8),
 DIV(none, dout_dp1, mout_dp1, DIV_DISP10, 24, 4),
 -   DIV(none, dout_hdmi_pixel, mout_pixel, DIV_DISP10, 28, 4),
 +   DIV(sclk_pixel, dout_hdmi_pixel, mout_pixel, DIV_DISP10, 28, 4),

 /* Audio Block */
 DIV(none, dout_maudio0, mout_maudio0, DIV_MAU, 20, 4),
 @@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] 
 __initdata = {
 GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
 GATE(sclk_hdmi, sclk_hdmi, mout_hdmi,
 GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
 -   GATE(sclk_pixel, sclk_pixel, dout_hdmi_pixel,
 +   GATE(none, sclk_pixel, dout_hdmi_pixel,
 GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
 GATE(sclk_dp1, sclk_dp1, dout_dp1,
 GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
 --
 1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #69 from Marc Dietrich marvi...@gmx.de ---
I mean it cannot find the intrinsic at all:

# ./Release/bin/llc  test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=r600
LLVM ERROR: Cannot select: 0x8a5570: f32 = fsin 0x8a5670 [ORD=2] [ID=3]
  0x8a5670: f32,ch = CopyFromReg 0x871928, 0x8a5970 [ID=2]
0x8a5970: f32 = Register %T0_X [ID=1]
In function: test

litte different with eg. -mcpu=hainan: 

# ./Release/bin/llc  test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=hainan
LLVM ERROR: Cannot select: target intrinsic %llvm.AMDGPU.store.output

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

--- Comment #3 from Tom Stellard tstel...@gmail.com ---
These patches should fix the issue:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130617/178156.html

The first patch is unrelated to the bug, but it is required in order to prevent
the test case in the second patch from crashing on Cayman.  I've tested this on
llc, can you verify it works on real hardware.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/2] Enhance EDID quirks to allow forcing a mode

[Dylan Semler]

Checking up on this patch from a few months back that I'd like to get
included..  Acked by Daniel Vetter[1] and Reviewed by Jani Nikula[2].
 However ajax has not yet provided comments.  Is this SOL without feedback
from ajax?

[1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html
[2] http://lists.freedesktop.org/archives/dri-devel/2013-April/036829.html


On Mon, Mar 25, 2013 at 5:58 PM, Dylan Semler dylan.sem...@gmail.comwrote:

 Changes in this version
  * rename do_force_quirk_modes() - do_force_quirk_mode()
  * use list_for_each_entry() instead of list_for_each_entry_safe() in
do_force_quirk_mode()
  * remove num_modes from do_force_quirk_mode(), just return 1 or 0 as
appropriate
  * remove unused quirks argument from add_force_quirk_modes()
  * fixes to allow cases of forcing multiple modes
  * adjusted comments to adhere closer to style guides

 Changes in version 3
  * Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline
  * Adds bool to specify reduced blanking to edid_quirk_force_mode
  * Removes preferred bit from all other modes

 Changes in version 2
  * none

 There is at least one monitor that doesn't report its native resolution
 in its EDID block.  This enhancement extends the EDID quirk logic to
 make monitors like this just work.

 The first patch in this series sets up a new quirk list where monitors'
 correct width, height, refresh rate, and reduced blanking parameters are
 specified.  When a matching monitor is attached the full mode is
 calculated with drm_cvt_mode() and added to the connector.  The
 DRM_MODE_TYPE_PREFERRED bit is set on the new mode and unset from all
 other modes.

 The first patch also defines a new quirk bit: EDID_QUIRK_FORCE_MODE.
 This bit needs to be set for the new quirk list described above to be
 checked.

 The second patch adds the offending monitor to the quirk lists.

 Dylan Semler (2):
   drm: Enhance EDID quirks to explicitly set a mode
   drm: Add EDID force quirk for MMT Monitor2Go HD+

  drivers/gpu/drm/drm_edid.c | 89
 ++
  1 file changed, 89 insertions(+)

 --
 1.7.11.7


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65822] [radeonsi] OpenCL is broken

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65822

Tom Stellard tstel...@gmail.com changed:

   What|Removed |Added

  Attachment #80967|0   |1
is obsolete||
  Attachment #80969|0   |1
is obsolete||

--- Comment #4 from Tom Stellard tstel...@gmail.com ---
Created attachment 81026
  -- https://bugs.freedesktop.org/attachment.cgi?id=81026action=edit
Updated piglit tests

Thanks for writing the piglit tests, I noticed a few bugs in them though. 
First, the output argument for all of the tests should be index 2 and not index
0 and second, in test #2 the buffer index should be multiplied by 8 instead of
10.  I've fixed the piglit tests in the attached patch and also replaced the
'_' with '-' in the filename.  The updated tests pass on my Llano APU.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

--- Comment #4 from Aaron Watry awa...@gmail.com ---
The good news is that the store error is gone...

Now I get a load error :/

LLVM ERROR: Cannot select: 0x2c92af0: i64,ch = load 0x21fe0c8, 0x2c924f0,
0x2c921f0LD4[undef](align=8), zext from i32 [ID=15]
  0x2c924f0: i64 = add 0x2c91ef0, 0x2c923f0 [ID=13]
0x2c91ef0: i64,ch = CopyFromReg 0x21fe0c8, 0x2c91df0 [ID=12]
  0x2c91df0: i64 = Register %vreg0 [ID=1]
0x2c923f0: i64 = Constant44 [ID=4]
  0x2c921f0: i64 = undef [ID=3]

I'll attach the llvm assembly in a follow-up

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

Aaron Watry awa...@gmail.com changed:

   What|Removed |Added

  Attachment #80971|0   |1
is obsolete||

--- Comment #5 from Aaron Watry awa...@gmail.com ---
Created attachment 81037
  -- https://bugs.freedesktop.org/attachment.cgi?id=81037action=edit
LLVM Assembly that is produced from vload-int.cl (after first patch)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65873

Aaron Watry awa...@gmail.com changed:

   What|Removed |Added

  Attachment #80972|0   |1
is obsolete||

--- Comment #6 from Aaron Watry awa...@gmail.com ---
Created attachment 81038
  -- https://bugs.freedesktop.org/attachment.cgi?id=81038action=edit
Output from llc -debug-only=isel --march=r600 --mcpu=verde  vload-int.ll

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #70 from vincent v...@ovi.com ---
Created attachment 81040
  -- https://bugs.freedesktop.org/attachment.cgi?id=81040action=edit
Add a cos/sin pattern

Andy, does current master work on your rv790 and Unigine ?

Marc, can you try the attached patch and Unigine Heaven ? I'm not sure it'll
work (the cos/sin pattern does not trunc anything, but it should at least not
crash)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65822] [radeonsi] OpenCL is broken

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65822

--- Comment #5 from Aaron Watry awa...@gmail.com ---
Ack!  You're right.  I'm so used to the output being arg 0 from every other
piglit test that I neglected to check these.

With that and the index multiplier changed, these tests also pass on Cedar.

All of the test cases currently pass on my pitcairn, except for the
code-in-else test, which fails with:

cl-program-tester:
/home/awatry/src/llvm/include/llvm/Target/TargetRegisterInfo.h:560: const
llvm::TargetRegisterClass* llvm::TargetRegisterInfo::getRegClass(unsigned int)
const: Assertion `i  getNumRegClasses()  Register Class ID out of range'
failed.
Stack dump:
0.Running pass 'Function Pass Manager' on module 'radeon'.
1.Running pass 'AMDGPU DAG-DAG Pattern Instruction Selection' on function
'@test4'

I'll attach the assembly in a follow-up

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] drm/cma: use prim helpers instead GEM CMA specific dma_buf functionality

[Laurent Pinchart]

Hi Joonyoung,

On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote:
 Hi,
 
 GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
 dma_buf. We can use prime helpers for dma_buf by commit
 89177644a7b6306e6084a89eab7e290f4bfef397 drm: add prime helpers, so
 this patchset is to replace from using GEM CMA specific functions to
 using prime helpers.

Overall this looks good to me, except the that prime helpers don't cache 
mappings, unlike the current implementation in the GEM CMA helpers. Could that 
be fixed in the prime helpers first ?

 Thanks.
 
 Joonyoung Shim (3):
drm: add mmap function to prime helpers
drm/cma: add low-level hook functions to use prime helpers
drm/cma: remove GEM CMA specific dma_buf functionality
 
   drivers/gpu/drm/drm_gem_cma_helper.c | 291 ---
   drivers/gpu/drm/drm_prime.c  |   5 +-
   include/drm/drmP.h   |   2 +
   include/drm/drm_gem_cma_helper.h |  13 +-
   4 files changed, 56 insertions(+), 255 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] drm: add prime helpers

[Laurent Pinchart]

Hi Aaron,

A bit late, but here's a small question.

On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
 Instead of reimplementing all of the dma_buf functionality in every driver,
 create helpers drm_prime_import and drm_prime_export that implement them in
 terms of new, lower-level hook functions:
 
   gem_prime_pin: callback when a buffer is created, used to pin buffers into
 GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
 export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
 gem_prime_vmap, gem_prime_vunmap: map and unmap an object
 
 These hooks are optional; drivers can opt in by using drm_gem_prime_import
 and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export
 fields of struct drm_driver.
 
 v2:
 - Drop .begin_cpu_access.  None of the drivers this code replaces
 implemented it.  Having it here was a leftover from when I was trying to
 include i915 in this rework.
 - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
 did.  This patch series shouldn't change that behavior.
 - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
   Rename struct sg_table* variables to 'sgt' for clarity.
 - Update drm.tmpl for these new hooks.
 
 v3:
 - Pass the vaddr down to the driver.  This lets drivers that just call
 vunmap on the pointer avoid having to store the pointer in their GEM
 private structures. - Move documentation into a /** DOC */ comment in
 drm_prime.c and include it in drm.tmpl with a !P line.  I tried to use !F
 lines to include documentation of the individual functions from drmP.h, but
 the docproc / kernel-doc scripts barf on that file, so hopefully this is
 good enough for now.
 - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
   (drm/prime: drop reference on imported dma-buf come from gem)
 
 Signed-off-by: Aaron Plattner aplatt...@nvidia.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: David Airlie airl...@linux.ie
 ---
  Documentation/DocBook/drm.tmpl |   4 +
  drivers/gpu/drm/drm_prime.c| 186 +-
  include/drm/drmP.h |  12 +++
  3 files changed, 201 insertions(+), 1 deletion(-)

[snip]

 diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
 index 7f12573..366910d 100644
 --- a/drivers/gpu/drm/drm_prime.c
 +++ b/drivers/gpu/drm/drm_prime.c

[snip]

 +/**
 + * DOC: PRIME Helpers
 + *
 + * Drivers can implement @gem_prime_export and @gem_prime_import in terms
 of + * simpler APIs by using the helper functions @drm_gem_prime_export and
 + * @drm_gem_prime_import.  These functions implement dma-buf support in
 terms of + * five lower-level driver callbacks:
 + *
 + * Export callbacks:
 + *
 + *  - @gem_prime_pin (optional): prepare a GEM object for exporting
 + *
 + *  - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
 pages + *
 + *  - @gem_prime_vmap: vmap a buffer exported by your driver
 + *
 + *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
 + *
 + * Import callback:
 + *
 + *  - @gem_prime_import_sg_table (import): produce a GEM object from
 another + *driver's scatter/gather table
 + */
 +
 +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 +  struct drm_gem_object *obj, int flags)
 +{
 + if (dev-driver-gem_prime_pin) {
 + int ret = dev-driver-gem_prime_pin(obj);
 + if (ret)
 + return ERR_PTR(ret);
 + }
 + return dma_buf_export(obj, drm_gem_prime_dmabuf_ops, obj-size,
 +   0600);

Why do you use 0600 instead of the flags passed by the caller ?

 +}
 +EXPORT_SYMBOL(drm_gem_prime_export);

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] drm: add prime helpers

[Aaron Plattner]

On 06/18/2013 04:08 PM, Laurent Pinchart wrote:

Hi Aaron,

A bit late, but here's a small question.

On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:

Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook functions:

   gem_prime_pin: callback when a buffer is created, used to pin buffers into
GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
gem_prime_vmap, gem_prime_vunmap: map and unmap an object

These hooks are optional; drivers can opt in by using drm_gem_prime_import
and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export
fields of struct drm_driver.

v2:
- Drop .begin_cpu_access.  None of the drivers this code replaces
implemented it.  Having it here was a leftover from when I was trying to
include i915 in this rework.
- Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
did.  This patch series shouldn't change that behavior.
- Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
   Rename struct sg_table* variables to 'sgt' for clarity.
- Update drm.tmpl for these new hooks.

v3:
- Pass the vaddr down to the driver.  This lets drivers that just call
vunmap on the pointer avoid having to store the pointer in their GEM
private structures. - Move documentation into a /** DOC */ comment in
drm_prime.c and include it in drm.tmpl with a !P line.  I tried to use !F
lines to include documentation of the individual functions from drmP.h, but
the docproc / kernel-doc scripts barf on that file, so hopefully this is
good enough for now.
- apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
   (drm/prime: drop reference on imported dma-buf come from gem)

Signed-off-by: Aaron Plattner aplatt...@nvidia.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: David Airlie airl...@linux.ie
---
  Documentation/DocBook/drm.tmpl |   4 +
  drivers/gpu/drm/drm_prime.c| 186 +-
  include/drm/drmP.h |  12 +++
  3 files changed, 201 insertions(+), 1 deletion(-)


[snip]


diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..366910d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c


[snip]


+/**
+ * DOC: PRIME Helpers
+ *
+ * Drivers can implement @gem_prime_export and @gem_prime_import in terms
of + * simpler APIs by using the helper functions @drm_gem_prime_export and
+ * @drm_gem_prime_import.  These functions implement dma-buf support in
terms of + * five lower-level driver callbacks:
+ *
+ * Export callbacks:
+ *
+ *  - @gem_prime_pin (optional): prepare a GEM object for exporting
+ *
+ *  - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
pages + *
+ *  - @gem_prime_vmap: vmap a buffer exported by your driver
+ *
+ *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
+ *
+ * Import callback:
+ *
+ *  - @gem_prime_import_sg_table (import): produce a GEM object from
another + *driver's scatter/gather table
+ */
+
+struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
+struct drm_gem_object *obj, int flags)
+{
+   if (dev-driver-gem_prime_pin) {
+   int ret = dev-driver-gem_prime_pin(obj);
+   if (ret)
+   return ERR_PTR(ret);
+   }
+   return dma_buf_export(obj, drm_gem_prime_dmabuf_ops, obj-size,
+ 0600);


Why do you use 0600 instead of the flags passed by the caller ?


Because I copied  pasted it from i915_gem_prime_export prior to commit 
5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you 
pointed it out just now.



+}
+EXPORT_SYMBOL(drm_gem_prime_export);



--
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] drm: add prime helpers

[Laurent Pinchart]

Hi Aaron,

On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
 On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
  Hi Aaron,
  
  A bit late, but here's a small question.
  
  On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
  Instead of reimplementing all of the dma_buf functionality in every
  driver, create helpers drm_prime_import and drm_prime_export that
  implement them in terms of new, lower-level hook functions:
  gem_prime_pin: callback when a buffer is created, used to pin buffers
  into 
  GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
  export gem_prime_import_sg_table: convert an sg_table into a
  drm_gem_object
  gem_prime_vmap, gem_prime_vunmap: map and unmap an object
  
  These hooks are optional; drivers can opt in by using
  drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import
  and .gem_prime_export fields of struct drm_driver.
  
  v2:
  - Drop .begin_cpu_access.  None of the drivers this code replaces
  implemented it.  Having it here was a leftover from when I was trying to
  include i915 in this rework.
  - Use mutex_lock instead of mutex_lock_interruptible, as these three
  drivers did.  This patch series shouldn't change that behavior.
  - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
  
 Rename struct sg_table* variables to 'sgt' for clarity.
  
  - Update drm.tmpl for these new hooks.
  
  v3:
  - Pass the vaddr down to the driver.  This lets drivers that just call
  vunmap on the pointer avoid having to store the pointer in their GEM
  private structures. - Move documentation into a /** DOC */ comment in
  drm_prime.c and include it in drm.tmpl with a !P line.  I tried to use !F
  lines to include documentation of the individual functions from drmP.h,
  but
  the docproc / kernel-doc scripts barf on that file, so hopefully this is
  good enough for now.
  - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
  
 (drm/prime: drop reference on imported dma-buf come from gem)
  
  Signed-off-by: Aaron Plattner aplatt...@nvidia.com
  Cc: Daniel Vetter daniel.vet...@ffwll.ch
  Cc: David Airlie airl...@linux.ie
  ---
  
Documentation/DocBook/drm.tmpl |   4 +
drivers/gpu/drm/drm_prime.c| 186
+-
include/drm/drmP.h |  12 +++
3 files changed, 201 insertions(+), 1 deletion(-)
  
  [snip]
  
  diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
  index 7f12573..366910d 100644
  --- a/drivers/gpu/drm/drm_prime.c
  +++ b/drivers/gpu/drm/drm_prime.c
  
  [snip]
  
  +/**
  + * DOC: PRIME Helpers
  + *
  + * Drivers can implement @gem_prime_export and @gem_prime_import in
  terms
  of + * simpler APIs by using the helper functions @drm_gem_prime_export
  and
  + * @drm_gem_prime_import.  These functions implement dma-buf support in
  terms of + * five lower-level driver callbacks:
  + *
  + * Export callbacks:
  + *
  + *  - @gem_prime_pin (optional): prepare a GEM object for exporting
  + *
  + *  - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
  pages + *
  + *  - @gem_prime_vmap: vmap a buffer exported by your driver
  + *
  + *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
  + *
  + * Import callback:
  + *
  + *  - @gem_prime_import_sg_table (import): produce a GEM object from
  another + *driver's scatter/gather table
  + */
  +
  +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
  +   struct drm_gem_object *obj, int flags)
  +{
  +  if (dev-driver-gem_prime_pin) {
  +  int ret = dev-driver-gem_prime_pin(obj);
  +  if (ret)
  +  return ERR_PTR(ret);
  +  }
  +  return dma_buf_export(obj, drm_gem_prime_dmabuf_ops, obj-size,
  +0600);
  
  Why do you use 0600 instead of the flags passed by the caller ?
 
 Because I copied  pasted it from i915_gem_prime_export prior to commit
 5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
 pointed it out just now.

That's a pretty valid reason I guess :-) Should I submit a patch or are you 
already working on one ?

  +}
  +EXPORT_SYMBOL(drm_gem_prime_export);

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel