Re: [PATCH 00/10] drm/exynos: add pm_runtime support

2015-09-21 Thread Andrzej Hajda 
On 09/04/2015 10:15 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> This series adds proper runtime PM suport to CRTCs and Encoders, so
> now instead of relying on 'suspended' or 'enabled' flags to track when
> the CRTC or Encoder is enabled we let the pm_runtime subsystem do it for us
> and remove all the flags. This is a important step to the atomic 
> suspend/resume
> support that will land in drm anytime soon.
> 
> Please review!
> 
>   Gustavo

The title is quite misleading, exynos_drm has already pm_runtime support :)
Could you explain more why do you want to change it, what are requirements of
atomic pm? What is wrong with the current one?

If I remember correctly one of arguments for replacing pm callbacks in
components by one centralized callback in exynos_drm_drv was to avoid issues
with non-deterministic order of calling components suspend callback.
Are there any recent changes in PM, DRM which invalidates the reason above?

On the other side your patchset adds implicit dependency on PM_SLEEP config
option, it should be avoided or at least it should be explicit.

Regards
Andrzej

--
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

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Sylwester Nawrocki 
Hi Mauro,

On 21/09/15 13:41, Mauro Carvalho Chehab wrote:
> Btw, I just got a Samsung TM1 device, with seems to be using an arm64
> SoC. Is this driver providing support for its camera?

The TM1 device (Z3) is based on a Qualcomm 64-bit SoC. The $subject
patch adds support for a standalone JPEG codec IP block of Samsung
Exynos5433 SoC, which can be found for instance in Galaxy Note4.
Perhaps someone else can provide more details regarding the TM1's camera
status.

-- 
Regards,
Sylwester
--
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

[PATCH v3 3/4] platform/chrome: Support reading/writing the vboot context

2015-09-21 Thread Emilio López 
Some EC implementations include a small nvram space used to store
verified boot context data. This patch offers a way to expose this
data to userspace.

Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Emilio López 
---

Changes from v1:
 - Use is_bin_visible instead of is_visible

Changes from v2:
 - Changes suggested by Javier (makefile, size checks, etc)
 - Add his reviewed-by

 drivers/platform/chrome/Makefile  |   3 +-
 drivers/platform/chrome/cros_ec_dev.c |   1 +
 drivers/platform/chrome/cros_ec_vbc.c | 137 ++
 include/linux/mfd/cros_ec.h   |   1 +
 4 files changed, 141 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/chrome/cros_ec_vbc.c

diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 4a11b01..bc498bd 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,7 +1,8 @@
 
 obj-$(CONFIG_CHROMEOS_LAPTOP)  += chromeos_laptop.o
 obj-$(CONFIG_CHROMEOS_PSTORE)  += chromeos_pstore.o
-cros_ec_devs-objs   := cros_ec_dev.o cros_ec_sysfs.o 
cros_ec_lightbar.o
+cros_ec_devs-objs  := cros_ec_dev.o cros_ec_sysfs.o \
+  cros_ec_lightbar.o cros_ec_vbc.o
 obj-$(CONFIG_CROS_EC_CHARDEV)   += cros_ec_devs.o
 obj-$(CONFIG_CROS_EC_LPC)   += cros_ec_lpc.o
 obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
diff --git a/drivers/platform/chrome/cros_ec_dev.c 
b/drivers/platform/chrome/cros_ec_dev.c
index e8fcdc2..d19263f 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -32,6 +32,7 @@ static int ec_major;
 static const struct attribute_group *cros_ec_groups[] = {
_ec_attr_group,
_ec_lightbar_attr_group,
+   _ec_vbc_attr_group,
NULL,
 };
 
diff --git a/drivers/platform/chrome/cros_ec_vbc.c 
b/drivers/platform/chrome/cros_ec_vbc.c
new file mode 100644
index 000..564a0d0
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_vbc.c
@@ -0,0 +1,137 @@
+/*
+ * cros_ec_vbc - Expose the vboot context nvram to userspace
+ *
+ * Copyright (C) 2015 Collabora Ltd.
+ *
+ * based on vendor driver,
+ *
+ * Copyright (C) 2012 The Chromium OS Authors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static ssize_t vboot_context_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *att, char *buf,
+ loff_t pos, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct cros_ec_dev *ec = container_of(dev, struct cros_ec_dev,
+ class_dev);
+   struct cros_ec_device *ecdev = ec->ec_dev;
+   struct ec_params_vbnvcontext *params;
+   struct cros_ec_command *msg;
+   int err;
+   const size_t para_sz = sizeof(params->op);
+   const size_t resp_sz = sizeof(struct ec_response_vbnvcontext);
+   const size_t payload = max(para_sz, resp_sz);
+
+   msg = kmalloc(sizeof(*msg) + payload, GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+
+   /* NB: we only kmalloc()ated enough space for the op field */
+   params = (struct ec_params_vbnvcontext *)msg->data;
+   params->op = EC_VBNV_CONTEXT_OP_READ;
+
+   msg->version = EC_VER_VBNV_CONTEXT;
+   msg->command = EC_CMD_VBNV_CONTEXT;
+   msg->outsize = para_sz;
+   msg->insize = resp_sz;
+
+   err = cros_ec_cmd_xfer(ecdev, msg);
+   if (err < 0) {
+   dev_err(dev, "Error sending read request: %d\n", err);
+   kfree(msg);
+   return err;
+   }
+
+   memcpy(buf, msg->data, resp_sz);
+
+   kfree(msg);
+   return resp_sz;
+}
+
+static ssize_t vboot_context_write(struct file *filp, struct kobject *kobj,
+  struct bin_attribute *attr, char *buf,
+  loff_t pos, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct cros_ec_dev *ec = container_of(dev, struct cros_ec_dev,
+ class_dev);
+   struct cros_ec_device *ecdev = ec->ec_dev;
+   struct ec_params_vbnvcontext *params;
+   struct cros_ec_command *msg;
+   int err;
+   const size_t para_sz = sizeof(*params);
+   const size_t data_sz =

[PATCH v3 2/4] Documentation: bindings: mfd: cros ec: document vbc EC property

2015-09-21 Thread Emilio López 
Some EC implementations include a small nvram space used to store
verified boot context data. This boolean property lets us indicate
whether this space is available or not on a specific EC implementation.

Signed-off-by: Emilio López 
---

Patch is new in v3, split from 3/4

 Documentation/devicetree/bindings/mfd/cros-ec.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt 
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
index 1777916..136e0c2 100644
--- a/Documentation/devicetree/bindings/mfd/cros-ec.txt
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -34,6 +34,10 @@ Required properties (LPC):
 - compatible: "google,cros-ec-lpc"
 - reg: List of (IO address, size) pairs defining the interface uses
 
+Optional properties (all):
+- google,has-vbc-nvram: Some implementations of the EC include a small
+  nvram space used to store verified boot context data. This boolean flag
+  is used to specify whether this nvram is present or not.
 
 Example for I2C:
 
-- 
2.1.4

--
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

[PATCH v3 4/4] ARM: dts: Enable EC vboot context support on Peach boards

2015-09-21 Thread Emilio López 
The Peach boards use the EC to store the vboot context information,
so add the corresponding properties on the EC node to indicate so.

Reviewed-by: Krzysztof Kozlowski 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Emilio López 
---

Changes from v1:
 - none

Changes from v2:
 - collect tags from Krzysztof & Javier

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..ac02fb4 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -935,6 +935,7 @@
pinctrl-0 = <_spi_cs _irq>;
reg = <0>;
spi-max-frequency = <3125000>;
+   google,has-vbc-nvram;
 
controller-data {
samsung,spi-feedback-delay = <1>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386..b60dec0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -898,6 +898,7 @@
pinctrl-0 = <_spi_cs _irq>;
reg = <0>;
spi-max-frequency = <3125000>;
+   google,has-vbc-nvram;
 
controller-data {
samsung,spi-feedback-delay = <1>;
-- 
2.1.4

--
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

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Mauro Carvalho Chehab 
Em Mon, 21 Sep 2015 11:59:27 +0200
Andrzej Pietrasiewicz  escreveu:

> Hi Hans,
> 
> W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
> > On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
> >> From: Marek Szyprowski 
> >>
> >> Add Exynos 5433 jpeg h/w codec node.
> >>
> >> Signed-off-by: Marek Szyprowski 
> >> Signed-off-by: Andrzej Pietrasiewicz 
> >> ---
> >>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
> >>   1 file changed, 21 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
> >> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> >
> > This dtsi file doesn't exist in the media-git tree. What is the story here?
> >
> > Should this go through a different subsystem?
> >
> > I think the media subsystem can take patches 1-3 and whoever does DT 
> > patches can
> > take this patch, right?
> >
> 
> The cover letter explains that the series is rebased onto Mauro's
> master with Kukjin's branch merged. The latter does contain
> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
> media subsystem and leaving DT patch to someone else is the
> way to go.

I'm ok with such strategy, provided that the new driver builds fine with
COMPILE_TEST without the need of the dtsi patch.

Please also notice that, if the driver uses MC, it has to wait for
the MC next gen support to be merged, and may need to be rebased, due
to a few changes at the MC internal APIs: one function got renamed
(the function that create links between two pads) and we're now using
lists for links (that will only affect the driver if it has its own
graph traversal routines).

Btw, I just got a Samsung TM1 device, with seems to be using an arm64
SoC. Is this driver providing support for its camera?

Regards,
Mauro.
--
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

[PATCH v3 0/4] platform/chrome: vboot context support

2015-09-21 Thread Emilio López 
Hi everyone,

This series adds support for reading and writing the verified boot context
nvram space on the EC using the cros_ec sysfs interface.

The first patch improves is_visible() functionality, making it work
for binary attributes as well as normal ones. This is needed so the
sysfs group can be hidden when the EC doesn't offer any space for
the context.

The second patch documents the property used in the binding documents.
This used to live in the next patch on the previous versions of this series.

The third patch is the actual code implementing the interface to read
and write the context data.

The fourth patch adds the DT properties on peach boards which, judging by
the vendor tree, use the EC to store the verified boot context.

The series was tested on a peach pi and was found to work OK there. As
always, all comments and further tests are welcome :)

Cheers!
Emilio

Emilio López (4):
  sysfs: Support is_visible() on binary attributes
  Documentation: bindings: mfd: cros ec: document vbc EC property
  platform/chrome: Support reading/writing the vboot context
  ARM: dts: Enable EC vboot context support on Peach boards

 Documentation/devicetree/bindings/mfd/cros-ec.txt |   4 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts|   1 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   1 +
 drivers/platform/chrome/Makefile  |   3 +-
 drivers/platform/chrome/cros_ec_dev.c |   1 +
 drivers/platform/chrome/cros_ec_vbc.c | 137 ++
 fs/sysfs/group.c  |  17 ++-
 include/linux/mfd/cros_ec.h   |   1 +
 include/linux/sysfs.h |  18 ++-
 9 files changed, 176 insertions(+), 7 deletions(-)
 create mode 100644 drivers/platform/chrome/cros_ec_vbc.c

-- 
2.1.4

--
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

[PATCH v3 4/4] usb: dwc2: refactor common low-level hw code to platform.c

2015-09-21 Thread Marek Szyprowski 
DWC2 module on some platforms needs three additional hardware
resources: phy controller, clock and power supply. All of them must be
enabled/activated to properly initialize and operate. This was initially
handled in s3c-hsotg driver, which has been converted to 'gadget' part
of dwc2 driver. Unfortunately, not all of this code got moved to common
platform code, what resulted in accessing DWC2 registers without
enabling low-level hardware resources. This fails for example on Exynos
SoCs. This patch moves all the code for managing those resources to
common platform.c file and provides convenient wrappers for controlling
them.

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/dwc2/core.h |   4 +-
 drivers/usb/dwc2/gadget.c   | 193 
 drivers/usb/dwc2/platform.c | 234 +---
 3 files changed, 217 insertions(+), 214 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1a7982d..a130e38 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -706,6 +706,7 @@ struct dwc2_hsotg {
enum usb_dr_mode dr_mode;
unsigned int hcd_enabled:1;
unsigned int gadget_enabled:1;
+   unsigned int ll_hw_enabled:1;
 
struct phy *phy;
struct usb_phy *uphy;
@@ -1104,7 +1105,8 @@ extern void dwc2_set_all_params(struct dwc2_core_params 
*params, int value);
 
 extern int dwc2_get_hwparams(struct dwc2_hsotg *hsotg);
 
-
+extern int dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg);
+extern int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg);
 
 /*
  * Dump core registers and SPRAM
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 3f656d9..12ac879 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -25,15 +25,11 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 
 #include 
 #include 
 #include 
-#include 
 
 #include "core.h"
 #include "hw.h"
@@ -2944,50 +2940,6 @@ static struct usb_ep_ops dwc2_hsotg_ep_ops = {
 };
 
 /**
- * dwc2_hsotg_phy_enable - enable platform phy dev
- * @hsotg: The driver state
- *
- * A wrapper for platform code responsible for controlling
- * low-level USB code
- */
-static void dwc2_hsotg_phy_enable(struct dwc2_hsotg *hsotg)
-{
-   struct platform_device *pdev = to_platform_device(hsotg->dev);
-
-   dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
-
-   if (hsotg->uphy)
-   usb_phy_init(hsotg->uphy);
-   else if (hsotg->plat && hsotg->plat->phy_init)
-   hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
-   else {
-   phy_init(hsotg->phy);
-   phy_power_on(hsotg->phy);
-   }
-}
-
-/**
- * dwc2_hsotg_phy_disable - disable platform phy dev
- * @hsotg: The driver state
- *
- * A wrapper for platform code responsible for controlling
- * low-level USB code
- */
-static void dwc2_hsotg_phy_disable(struct dwc2_hsotg *hsotg)
-{
-   struct platform_device *pdev = to_platform_device(hsotg->dev);
-
-   if (hsotg->uphy)
-   usb_phy_shutdown(hsotg->uphy);
-   else if (hsotg->plat && hsotg->plat->phy_exit)
-   hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
-   else {
-   phy_power_off(hsotg->phy);
-   phy_exit(hsotg->phy);
-   }
-}
-
-/**
  * dwc2_hsotg_init - initalize the usb core
  * @hsotg: The driver state
  */
@@ -3068,14 +3020,12 @@ static int dwc2_hsotg_udc_start(struct usb_gadget 
*gadget,
hsotg->gadget.dev.of_node = hsotg->dev->of_node;
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
 
-   ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
-   hsotg->supplies);
-   if (ret) {
-   dev_err(hsotg->dev, "failed to enable supplies: %d\n", ret);
-   goto err;
+   if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
+   ret = dwc2_lowlevel_hw_enable(hsotg);
+   if (ret)
+   goto err;
}
 
-   dwc2_hsotg_phy_enable(hsotg);
if (!IS_ERR_OR_NULL(hsotg->uphy))
otg_set_peripheral(hsotg->uphy->otg, >gadget);
 
@@ -3133,9 +3083,9 @@ static int dwc2_hsotg_udc_stop(struct usb_gadget *gadget)
 
if (!IS_ERR_OR_NULL(hsotg->uphy))
otg_set_peripheral(hsotg->uphy->otg, NULL);
-   dwc2_hsotg_phy_disable(hsotg);
 
-   regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
+   if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL)
+   dwc2_lowlevel_hw_disable(hsotg);
 
mutex_unlock(>init_mutex);
 
@@ -3473,15 +3423,11 @@ static inline void dwc2_hsotg_of_probe(struct 
dwc2_hsotg *hsotg) { }
 int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
 {
struct device *dev = hsotg->dev;
-   struct dwc2_hsotg_plat *plat = dev->platform_data;
int epnum;
int ret;
int i;
u32 p_tx_fifo[] =

[PATCH v3 2/4] usb: dwc2: remove non-functional clock gating

2015-09-21 Thread Marek Szyprowski 
During typical gadget operation, dwc2 clock was enabled 3 times: from
dwc2_gadget_init(), dwc2_hsotg_udc_start() and dwc2_hsotg_pullup(), and
then disabled in s3c_hsotg_pullup(), s3c_hsotg_udc_stop() and
dwc2_hsotg_remove(). This really makes no sense, so leave clock control
code only in dwc2_gadget_init/remove functions.

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/dwc2/gadget.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 410ea6e..3f656d9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3068,8 +3068,6 @@ static int dwc2_hsotg_udc_start(struct usb_gadget *gadget,
hsotg->gadget.dev.of_node = hsotg->dev->of_node;
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
 
-   clk_enable(hsotg->clk);
-
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
hsotg->supplies);
if (ret) {
@@ -3139,8 +3137,6 @@ static int dwc2_hsotg_udc_stop(struct usb_gadget *gadget)
 
regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
 
-   clk_disable(hsotg->clk);
-
mutex_unlock(>init_mutex);
 
return 0;
@@ -3174,7 +3170,6 @@ static int dwc2_hsotg_pullup(struct usb_gadget *gadget, 
int is_on)
mutex_lock(>init_mutex);
spin_lock_irqsave(>lock, flags);
if (is_on) {
-   clk_enable(hsotg->clk);
hsotg->enabled = 1;
dwc2_hsotg_core_init_disconnected(hsotg, false);
dwc2_hsotg_core_connect(hsotg);
@@ -3182,7 +3177,6 @@ static int dwc2_hsotg_pullup(struct usb_gadget *gadget, 
int is_on)
dwc2_hsotg_core_disconnect(hsotg);
dwc2_hsotg_disconnect(hsotg);
hsotg->enabled = 0;
-   clk_disable(hsotg->clk);
}
 
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
-- 
1.9.2

--
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

Re: [PATCH v4 0/16] Add Analogix Core Display Port Driver

2015-09-21 Thread Thierry Reding 
On Mon, Sep 21, 2015 at 06:27:40PM +0800, Yakir Yang wrote:
> Hi Thierry,
> 
> Thanks for your suggest :)
> 
> On 09/21/2015 05:15 PM, Thierry Reding wrote:
> >On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
> >>Hi Heiko,
> >>
> >>On 09/02/2015 10:15 AM, Yakir Yang wrote:
> >>>Hi Heiko,
> >>>
> >>>在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
> Hi Yakir,
> 
> Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
> >The Samsung Exynos eDP controller and Rockchip RK3288 eDP
> >controller
> >share the same IP, so a lot of parts can be re-used. I split the common
> >code into bridge directory, then rk3288 and exynos only need to keep
> >some platform code. Cause I can't find the exact IP name of exynos dp
> >controller, so I decide to name dp core driver with "analogix" which I
> >find in rk3288 eDP TRM ;)
> >
> >Beyond that, there are three light registers setting differents bewteen
> >exynos and rk3288.
> >1. RK3288 have five special pll resigters which not indicata in exynos
> >dp controller.
> >2. The address of DP_PHY_PD(dp phy power manager register) are
> >different
> >between rk3288 and exynos.
> >3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
> >debug
> >register).
> >
> >I have verified this series on two kinds of rockchip platform board,
> >one
> >is rk3288 sdk board which connect with a 2K display port monitor, the
> >other
> >is google jerry chromebook which connect with a eDP screen
> >"cnm,n116bgeea2",
> >both of them works rightlly.
> it looks like during the rebase something did go wrong and I found some
> issues
> I mentioned in the replies to individual patches.
> 
> I did prepare a branch based on mainline [0] with both the old and the
> new edp
> driver - rk3288_veyron_defconfig build both drivers into the image.
> 
> While the old driver still works, I wasn't able to make the new one work
> yet
> ... the drm core does find the connector, but not that anything is
> connected
> to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
> interesting before then.
> >>>Many thanks for your comment and debug, I would rebase on your
> >>>"edp-with-veyron" branch and fix the broken, make sure v6 would
> >>>work rightly at least in your side and my side.
> >>Just like we talk off line, I guess there are two tricky questions which
> >>make analogix_dp just crash/failed on rockchip platform:
> >>
> >>-  One is how to reach a agreement with the common way to register
> >>connector. There would be a conflict with Exynos & IMX & Rockchip.
> >>  On analogix_dp thread, Exynos want to register connector when that
> >>connector is ready.
> >>  On dw_hdmi thread, IMX want to register connector when all component 
> >> is
> >>already.
> >>  So Exynos & IMX & Rockchip should reach a common way to register
> >>connector to fix this issue.
> >>
> >>-  The other is atomic API.
> >>   The rockchip drm haven't implemented the atomic API, but the original
> >>exynos_dp have used the atomic API on connector helper function. That's why
> >>analogix_dp just keep crash on your side.
> >There's really no reason not to convert Rockchip to atomic. It will have
> >to happen eventually anyway.
> 
> Do agree on this point, and I see Tomasz Figa have done some WIP
> works on implementing the atomic_commit, maybe would upstream
> in further.(https://chromium-review.googlesource.com/#/c/284560/1)
> 
> 
> >That said, there's another option that would allow you to side-step both
> >of the above problems at the same time. If you turn the common code into
> >a helper library that should give you enough flexibility to integrate it
> >into all existing users. For example you could leave out the connector
> >registration and let the drivers do that. Similarly since the helpers
> >are only hooked up at registration time you could probably find a way to
> >share the low-level code but again leave it up to the drivers to glue it
> >all together at registration time (drivers could wrap the low-level code
> >with atomic or non-atomic callbacks).
> 
> Wow, sounds good, but I'm not sure I understand this rightly. Do you
> mean that I could support two kinds of callbacks in analogix_dp_core
> driver, and export them out. And move the connector registration code
> into the helper driver (like exynos_dp.c), so helper driver could chose to
> use the atomic or non-atomic callbacks. like:
> 
> -- analogix_dp_core.c
> 
> ...
> struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
> .dpms = drm_atomic_helper_connector_dpms,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .detect = analogix_dp_detect,
> .destroy = analogix_dp_connector_destroy,
> .reset =

Re: [PATCH 1/4] sysfs: Support is_visible() on binary attributes

2015-09-21 Thread Emilio López 
This is v3, even if the subject doesn't say so. This is what happens 
when you forget to use --reroll-count and try to fix it manually :)


Emilio

On 21/09/15 10:38, Emilio López wrote:

According to the sysfs header file:

 "The returned value will replace static permissions defined in
  struct attribute or struct bin_attribute."

but this isn't the case, as is_visible is only called on struct attribute
only. This patch introduces a new is_bin_visible() function to implement
the same functionality for binary attributes, and updates documentation
accordingly.

Note that to keep functionality and code similar to that of normal
attributes, the mode is now checked as well to ensure it contains only
read/write permissions or SYSFS_PREALLOC.

Reviewed-by: Guenter Roeck 
Signed-off-by: Emilio López 
---

Changes from v1:
  - Don't overload is_visible, introduce is_bin_visible instead as
discussed on the list.

Changes from v2:
  - Note change in mode checking on the commit log
  - Add Guenter's reviewed-by

  fs/sysfs/group.c  | 17 +++--
  include/linux/sysfs.h | 18 ++
  2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 39a0199..51b56e6 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -73,13 +73,26 @@ static int create_files(struct kernfs_node *parent, struct 
kobject *kobj,
}

if (grp->bin_attrs) {
-   for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
+   for (i = 0, bin_attr = grp->bin_attrs; *bin_attr; i++, 
bin_attr++) {
+   umode_t mode = (*bin_attr)->attr.mode;
+
if (update)
kernfs_remove_by_name(parent,
(*bin_attr)->attr.name);
+   if (grp->is_bin_visible) {
+   mode = grp->is_bin_visible(kobj, *bin_attr, i);
+   if (!mode)
+   continue;
+   }
+
+   WARN(mode & ~(SYSFS_PREALLOC | 0664),
+"Attribute %s: Invalid permissions 0%o\n",
+(*bin_attr)->attr.name, mode);
+
+   mode &= SYSFS_PREALLOC | 0664;
error = sysfs_add_file_mode_ns(parent,
&(*bin_attr)->attr, true,
-   (*bin_attr)->attr.mode, NULL);
+   mode, NULL);
if (error)
break;
}
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9f65758..2f66050 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -64,10 +64,18 @@ do {
\
   *a new subdirectory with this name.
   * @is_visible:   Optional: Function to return permissions associated 
with an
   *attribute of the group. Will be called repeatedly for each
- * attribute in the group. Only read/write permissions as well as
- * SYSFS_PREALLOC are accepted. Must return 0 if an attribute is
- * not visible. The returned value will replace static permissions
- * defined in struct attribute or struct bin_attribute.
+ * non-binary attribute in the group. Only read/write
+ * permissions as well as SYSFS_PREALLOC are accepted. Must
+ * return 0 if an attribute is not visible. The returned value
+ * will replace static permissions defined in struct attribute.
+ * @is_bin_visible:
+ * Optional: Function to return permissions associated with a
+ * binary attribute of the group. Will be called repeatedly
+ * for each binary attribute in the group. Only read/write
+ * permissions as well as SYSFS_PREALLOC are accepted. Must
+ * return 0 if a binary attribute is not visible. The returned
+ * value will replace static permissions defined in
+ * struct bin_attribute.
   * @attrs:Pointer to NULL terminated list of attributes.
   * @bin_attrs:Pointer to NULL terminated list of binary attributes.
   *Either attrs or bin_attrs or both must be provided.
@@ -76,6 +84,8 @@ struct attribute_group {
const char  *name;
umode_t (*is_visible)(struct kobject *,
  struct attribute *, int);
+   umode_t (*is_bin_visible)(struct kobject *,
+ struct bin_attribute *, int);
struct attribute**attrs;
struct bin_attribute**bin_attrs;
  };


--
To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Andrzej Pietrasiewicz 

Hi Mauro,

W dniu 21.09.2015 o 13:41, Mauro Carvalho Chehab pisze:





I think the media subsystem can take patches 1-3 and whoever does DT patches can
take this patch, right?



The cover letter explains that the series is rebased onto Mauro's
master with Kukjin's branch merged. The latter does contain
the exynos5433.dtsi. That said, yes, taking patches 1-3 in
media subsystem and leaving DT patch to someone else is the
way to go.


I'm ok with such strategy, provided that the new driver builds fine with
COMPILE_TEST without the need of the dtsi patch.



I've checked. It does compile with COMPILE_TEST.



Please also notice that, if the driver uses MC, it has to wait for
the MC next gen support to be merged,


No, it does not. It is a rather simple mem2mem device.

Sylwester has answered about camera support which is a different
topic.

Andrzej
--
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

Re: [PATCH v3 2/4] Documentation: bindings: mfd: cros ec: document vbc EC property

2015-09-21 Thread Javier Martinez Canillas 
Hello Emilio,

On Mon, Sep 21, 2015 at 6:38 AM, Emilio López
 wrote:
> Some EC implementations include a small nvram space used to store
> verified boot context data. This boolean property lets us indicate
> whether this space is available or not on a specific EC implementation.
>
> Signed-off-by: Emilio López 

Looks good to me.

Reviewed-by: Javier Martinez Canillas 

Best regards,
Javier
--
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

Re: [PATCH v2 0/9] drm/exynos: rewrite fimg2d error handling

2015-09-21 Thread Emil Velikov 
Hi Tobias,

On 8 September 2015 at 16:22, Tobias Jakobi
 wrote:
> Hello,
>
> during the discussion about the last patchset touching the
> fimg2d code, it became apparent that the error handling for
> the command submission is currently unsatisfactory.
>
> This series rewrites the handling. All functions that submit
> command buffers now first check if enough space is available
> and only then proceed to build the command buffers.
>
> In particular the command buffer is no longer left in a
> half-finished state, since parameters passed to the functions
> are now validated before command submission. For this some
> validation functions are introduced.
>
> This should also increase performance if the bottleneck is
> the submission part, since adding commands to the buffer
> is now more lightweight.
>
> Last but not least some prefix was added to messages printed
> by fprintf and printf, and the G2D context struct was moved
> out of the public header.
>
>
> Please review and let me know if I can improve anything!
>
Considering that there were no more objections with the series I've
scooped them up.

Thanks for clearing this and sticking around !
Emil
--
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

Re: [PATCH v2 0/9] drm/exynos: rewrite fimg2d error handling

2015-09-21 Thread Tobias Jakobi 
Hey Emil,

Emil Velikov wrote:
> Hi Tobias,
> 
> On 8 September 2015 at 16:22, Tobias Jakobi
>  wrote:
>> Hello,
>>
>> during the discussion about the last patchset touching the
>> fimg2d code, it became apparent that the error handling for
>> the command submission is currently unsatisfactory.
>>
>> This series rewrites the handling. All functions that submit
>> command buffers now first check if enough space is available
>> and only then proceed to build the command buffers.
>>
>> In particular the command buffer is no longer left in a
>> half-finished state, since parameters passed to the functions
>> are now validated before command submission. For this some
>> validation functions are introduced.
>>
>> This should also increase performance if the bottleneck is
>> the submission part, since adding commands to the buffer
>> is now more lightweight.
>>
>> Last but not least some prefix was added to messages printed
>> by fprintf and printf, and the G2D context struct was moved
>> out of the public header.
>>
>>
>> Please review and let me know if I can improve anything!
>>
> Considering that there were no more objections with the series I've
> scooped them up.
thanks a lot! Going to prepare the next batch then :)

With best wishes,
Tobias

> 
> Thanks for clearing this and sticking around !
> Emil
> 

--
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

[PATCH] ARM: dts: exynos4412-odroid: unify voltage regulator style

2015-09-21 Thread Tobias Jakobi 
Use 'ldoN_reg: LDON' syntax and drop the deprecated
'regulator-compatible' property.

Signed-off-by: Tobias Jakobi 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 518230f..9f381bd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -294,15 +294,13 @@
regulator-always-on;
};
 
-   ldo8_reg: ldo@8 {
-   regulator-compatible = "LDO8";
+   ldo8_reg: LDO8 {
regulator-name = "VDD10_HDMI_1.0V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
};
 
-   ldo10_reg: ldo@10 {
-   regulator-compatible = "LDO10";
+   ldo10_reg: LDO10 {
regulator-name = "VDDQ_MIPIHSI_1.8V";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-- 
2.0.5

--
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

[PATCH] ARM: dts: exynos4412-odroid: remove redundant pinctrl settings

2015-09-21 Thread Tobias Jakobi 
The pinctrl settings in i2c_0 and i2c_1 are already provided
through the exynos4 dtsi.

Signed-off-by: Tobias Jakobi 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3f8bc7b..3c34e74 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -217,8 +217,6 @@
 };
 
 _0 {
-   pinctrl-0 = <_bus>;
-   pinctrl-names = "default";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <40>;
status = "okay";
@@ -444,8 +442,6 @@
 };
 
 _1 {
-   pinctrl-names = "default";
-   pinctrl-0 = <_bus>;
status = "okay";
max98090: max98090@10 {
compatible = "maxim,max98090";
@@ -460,8 +456,6 @@
 
 _2 {
status = "okay";
-   pinctrl-names = "default";
-   pinctrl-0 = <_bus>;
 };
 
 _8 {
-- 
2.0.5

--
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

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Hans Verkuil 
On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
> From: Marek Szyprowski 
> 
> Add Exynos 5433 jpeg h/w codec node.
> 
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi

This dtsi file doesn't exist in the media-git tree. What is the story here?

Should this go through a different subsystem?

I think the media subsystem can take patches 1-3 and whoever does DT patches can
take this patch, right?

Regards,

Hans

> index 59e21b6..5cb489f 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -916,6 +916,27 @@
>   io-channel-ranges;
>   status = "disabled";
>   };
> + jpeg: jpeg@1502 {
> + compatible = "samsung,exynos5433-jpeg";
> + reg = <0x1502 0x1>;
> + interrupts = <0 411 0>;
> + clock-names = "pclk",
> +   "aclk",
> +   "aclk_xiu",
> +   "sclk";
> + clocks = <_mscl CLK_PCLK_JPEG>,
> +  <_mscl CLK_ACLK_JPEG>,
> +  <_mscl CLK_ACLK_XIU_MSCLX>,
> +  <_mscl CLK_SCLK_JPEG>;
> + assigned-clocks = <_mscl 
> CLK_MOUT_ACLK_MSCL_400_USER>,
> +   <_mscl CLK_MOUT_SCLK_JPEG_USER>,
> +   <_mscl CLK_MOUT_SCLK_JPEG>,
> +   <_top CLK_MOUT_SCLK_JPEG_A>;
> + assigned-clock-parents = <_top CLK_ACLK_MSCL_400>,
> +  <_top CLK_SCLK_JPEG_MSCL>,
> +  <_mscl 
> CLK_MOUT_SCLK_JPEG_USER>,
> +  <_top 
> CLK_MOUT_BUS_PLL_USER>;
> + };
>   };
>  
>   timer {
> 
--
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

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-21 Thread Andrzej Pietrasiewicz 

Hi Hans,

W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:

On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:

From: Marek Szyprowski 

Add Exynos 5433 jpeg h/w codec node.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Andrzej Pietrasiewicz 
---
  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
  1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi


This dtsi file doesn't exist in the media-git tree. What is the story here?

Should this go through a different subsystem?

I think the media subsystem can take patches 1-3 and whoever does DT patches can
take this patch, right?



The cover letter explains that the series is rebased onto Mauro's
master with Kukjin's branch merged. The latter does contain
the exynos5433.dtsi. That said, yes, taking patches 1-3 in
media subsystem and leaving DT patch to someone else is the
way to go.

Andrzej
--
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

Re: [PATCH v4 0/16] Add Analogix Core Display Port Driver

2015-09-21 Thread Yakir Yang 

Hi Thierry,

Thanks for your suggest :)

On 09/21/2015 05:15 PM, Thierry Reding wrote:

On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:

Hi Heiko,

On 09/02/2015 10:15 AM, Yakir Yang wrote:

Hi Heiko,

在 09/02/2015 05:47 AM, Heiko Stuebner 写道:

Hi Yakir,

Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:

The Samsung Exynos eDP controller and Rockchip RK3288 eDP
controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM ;)

Beyond that, there are three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are
different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
debug
register).

I have verified this series on two kinds of rockchip platform board,
one
is rk3288 sdk board which connect with a 2K display port monitor, the
other
is google jerry chromebook which connect with a eDP screen
"cnm,n116bgeea2",
both of them works rightlly.

it looks like during the rebase something did go wrong and I found some
issues
I mentioned in the replies to individual patches.

I did prepare a branch based on mainline [0] with both the old and the
new edp
driver - rk3288_veyron_defconfig build both drivers into the image.

While the old driver still works, I wasn't able to make the new one work
yet
... the drm core does find the connector, but not that anything is
connected
to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
interesting before then.

Many thanks for your comment and debug, I would rebase on your
"edp-with-veyron" branch and fix the broken, make sure v6 would
work rightly at least in your side and my side.

Just like we talk off line, I guess there are two tricky questions which
make analogix_dp just crash/failed on rockchip platform:

-  One is how to reach a agreement with the common way to register
connector. There would be a conflict with Exynos & IMX & Rockchip.
  On analogix_dp thread, Exynos want to register connector when that
connector is ready.
  On dw_hdmi thread, IMX want to register connector when all component is
already.
  So Exynos & IMX & Rockchip should reach a common way to register
connector to fix this issue.

-  The other is atomic API.
   The rockchip drm haven't implemented the atomic API, but the original
exynos_dp have used the atomic API on connector helper function. That's why
analogix_dp just keep crash on your side.

There's really no reason not to convert Rockchip to atomic. It will have
to happen eventually anyway.


Do agree on this point, and I see Tomasz Figa have done some WIP
works on implementing the atomic_commit, maybe would upstream
in further.(https://chromium-review.googlesource.com/#/c/284560/1)



That said, there's another option that would allow you to side-step both
of the above problems at the same time. If you turn the common code into
a helper library that should give you enough flexibility to integrate it
into all existing users. For example you could leave out the connector
registration and let the drivers do that. Similarly since the helpers
are only hooked up at registration time you could probably find a way to
share the low-level code but again leave it up to the drivers to glue it
all together at registration time (drivers could wrap the low-level code
with atomic or non-atomic callbacks).


Wow, sounds good, but I'm not sure I understand this rightly. Do you
mean that I could support two kinds of callbacks in analogix_dp_core
driver, and export them out. And move the connector registration code
into the helper driver (like exynos_dp.c), so helper driver could chose to
use the atomic or non-atomic callbacks. like:

-- analogix_dp_core.c 


...
struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = analogix_dp_detect,
.destroy = analogix_dp_connector_destroy,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = 
drm_atomic_helper_connector_duplicate_state,

.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
EXPORT_SYMBOL(analogix_dp_connector_atomic_funcs);

struct drm_connector_funcs analogix_dp_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = analogix_dp_detect,
.destroy = analogix_dp_connector_destroy,
};
EXPORT_SYMBOL(analogix_dp_connector_funcs);

Re: [PATCH v4 0/16] Add Analogix Core Display Port Driver

2015-09-21 Thread Thierry Reding 
On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
> Hi Heiko,
> 
> On 09/02/2015 10:15 AM, Yakir Yang wrote:
> >Hi Heiko,
> >
> >在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
> >>Hi Yakir,
> >>
> >>Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
> >>>The Samsung Exynos eDP controller and Rockchip RK3288 eDP
> >>>controller
> >>>share the same IP, so a lot of parts can be re-used. I split the common
> >>>code into bridge directory, then rk3288 and exynos only need to keep
> >>>some platform code. Cause I can't find the exact IP name of exynos dp
> >>>controller, so I decide to name dp core driver with "analogix" which I
> >>>find in rk3288 eDP TRM ;)
> >>>
> >>>Beyond that, there are three light registers setting differents bewteen
> >>>exynos and rk3288.
> >>>1. RK3288 have five special pll resigters which not indicata in exynos
> >>>dp controller.
> >>>2. The address of DP_PHY_PD(dp phy power manager register) are
> >>>different
> >>>between rk3288 and exynos.
> >>>3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
> >>>debug
> >>>register).
> >>>
> >>>I have verified this series on two kinds of rockchip platform board,
> >>>one
> >>>is rk3288 sdk board which connect with a 2K display port monitor, the
> >>>other
> >>>is google jerry chromebook which connect with a eDP screen
> >>>"cnm,n116bgeea2",
> >>>both of them works rightlly.
> >>it looks like during the rebase something did go wrong and I found some
> >>issues
> >>I mentioned in the replies to individual patches.
> >>
> >>I did prepare a branch based on mainline [0] with both the old and the
> >>new edp
> >>driver - rk3288_veyron_defconfig build both drivers into the image.
> >>
> >>While the old driver still works, I wasn't able to make the new one work
> >>yet
> >>... the drm core does find the connector, but not that anything is
> >>connected
> >>to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
> >>interesting before then.
> >
> >Many thanks for your comment and debug, I would rebase on your
> >"edp-with-veyron" branch and fix the broken, make sure v6 would
> >work rightly at least in your side and my side.
> 
> Just like we talk off line, I guess there are two tricky questions which
> make analogix_dp just crash/failed on rockchip platform:
> 
> -  One is how to reach a agreement with the common way to register
> connector. There would be a conflict with Exynos & IMX & Rockchip.
>  On analogix_dp thread, Exynos want to register connector when that
> connector is ready.
>  On dw_hdmi thread, IMX want to register connector when all component is
> already.
>  So Exynos & IMX & Rockchip should reach a common way to register
> connector to fix this issue.
> 
> -  The other is atomic API.
>   The rockchip drm haven't implemented the atomic API, but the original
> exynos_dp have used the atomic API on connector helper function. That's why
> analogix_dp just keep crash on your side.

There's really no reason not to convert Rockchip to atomic. It will have
to happen eventually anyway.

That said, there's another option that would allow you to side-step both
of the above problems at the same time. If you turn the common code into
a helper library that should give you enough flexibility to integrate it
into all existing users. For example you could leave out the connector
registration and let the drivers do that. Similarly since the helpers
are only hooked up at registration time you could probably find a way to
share the low-level code but again leave it up to the drivers to glue it
all together at registration time (drivers could wrap the low-level code
with atomic or non-atomic callbacks).

This option may also have the benefit of loosening the coupling between
DRM drivers and the helper code for this IP, which may be handy in case
the drivers diverge again in the future, or ease transitions to new API.

Thierry


signature.asc
Description: PGP signature