Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded
Hey Inki, On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote: On 2014년 07월 19일 05:36, Sjoerd Simons wrote: The exynos DRM module currently is not automatically loaded when build as a module. This is due to the simple fact that it doesn't have any MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE in one module, however commit 21bdd17b21b45ea solved that. The first two patches revert the previous removals of MODULE_DEVICE_TABLE calls, while the last one adds calls for the remaining OF match tables without a MODULE_DEVICE_TABLE call. Exynos drm follows single-driver model. So each usb driver of Exynos drm wouldn't need its own MODULE_DEVICE_TABLE. Strictly speaking you're right, for module autoloading to work the module just needs to have one that matches. So in principle all other entries are redundant. However for exynos drm there does not seem to be one main device which is guaranteed to always be present which can be used to key the module autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries for all the various subdrivers to ensure autoloading actually happens, especially since the various subdrivers can be seperately enabled at build time. The one exception from the above might be the HDMI sub-driver, which is always build together with the mixer (And i asume the HDMI hw block depends on the mixer block for its input). However it seems more elegant and less error-prone to have simply entries for both, rather then implicitly replying on the other (sub)driver to trigger module loading. Especially given there is essentially no cost in having another module alias. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH V5 11/12] Documentation: Add DT bindings for ps8622/ps8625 bridge driver
On Fri, Jul 18, 2014 at 02:13:57AM +0530, Ajay Kumar wrote:
From: Vincent Palatin vpala...@chromium.org
Add DT binding documentation for ps8622/ps8625 bridge driver.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/drm/bridge/ps8622.txt | 21
This is the wrong directory. Bindings are supposed to be OS agnostic,
but DRM is (mostly) Linux-specific. video/bridge would be a better
subdirectory for this. Somebody really ought to be moving out the
existing bindings in the drm subdirectory to a more proper location.
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
new file mode 100644
index 000..1d154ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
@@ -0,0 +1,21 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: parade,ps8622 or parade,ps8625
Documentation/devicetree/bindings/vendor-prefixes.txt doesn't contain an
entry for parade yet.
+ - reg: first i2c address of the bridge
+ - sleep-gpios: OF device-tree gpio specification
+ - reset-gpios: OF device-tree gpio specification
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
In case of an external backlight, don't you still need a way to control
it? Perhaps instead of using this boolean property you should make this
take a phandle to the real backlight? Like so:
backlight {
compatible = pwm-backlight;
...
}
bridge@48 {
compatible = parade,ps8622;
...
backlight = /backlight;
}
Then you can simply look up the backlight device when that property
exists and instantiate the built-in backlight otherwise.
+
+Example:
+ ps8622-bridge@48 {
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ display-timings = lcd_display_timings;
Why is this specifying display-timings? It's not mentioned in the
binding above and I don't see why the bridge would need to provide
one since it's really a property of the panel.
Thierry
pgp9mH_uJ_bZE.pgp
Description: PGP signature
Re: [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
On Fri, Jul 18, 2014 at 02:13:58AM +0530, Ajay Kumar wrote:
From: Rahul Sharma rahul.sha...@samsung.com
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 0ca6256..82e2942 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -31,6 +31,7 @@
#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
#include drm/bridge/panel_binder.h
+#include drm/bridge/ps8622.h
#include exynos_drm_drv.h
#include exynos_dp_core.h
@@ -999,6 +1000,10 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
if (find_bridge(nxp,ptn3460, bridge)) {
bridge_chain = ptn3460_init(dp-drm_dev, encoder, bridge.client,
bridge.node);
+ } else if (find_bridge(parade,ps8622, bridge) ||
+ find_bridge(parade,ps8625, bridge)) {
+ bridge_chain = ps8622_init(dp-drm_dev, encoder, bridge.client,
+ bridge.node);
}
We really ought to be adding some sort of registry at some point.
Otherwise every driver that wants to use bridges needs to come up with a
similar set of helpers to instantiate them.
Also you're making this driver depend on (now) two bridges, whereas it
really shouldn't matter which exact types it supports. Bridges should be
exposed via a generic interface.
Thierry
pgpflAgLNpAhe.pgp
Description: PGP signature
Re: [PATCH V5 00/12] drm/exynos: few patches to enhance bridge chip support
On 2014년 07월 18일 05:43, Ajay Kumar wrote: This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git This patchset also consolidates various inputs from the drm community regarding the bridge chaining concept: (1) [RFC V2 0/3] drm/bridge: panel and chaining http://www.spinics.net/lists/linux-samsung-soc/msg30160.html (2) [RFC V3 0/3] drm/bridge: panel and chaining http://www.spinics.net/lists/linux-samsung-soc/msg30507.html I have tested this after adding few DT changes for exynos5250-snow, exynos5420-peach-pit and exynos5800-peach-pi boards. The V4 series of this particular patchset was also tested by: Rahul Sharma rahul.sha...@samsung.com Javier Martinez Canillas jav...@dowhile0.org Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Hi Ajay, Thanks for your contribution. I am reviewing your patch series. Sorry for late. Below is my comment. How about using graph concept to bind eDP, LVDS bridge, and Panel? Your patch tries to bind bridge driver using find_bridge function, and this function tries to find bridge device node directly using of_find_compatible_node() again, which in turn make eDP driver to add all codes related to all bridge devices including all relevant bridge headers: i.e., if there are five bridge devices then eDP driver should try to find all of them. That is really not good. So my opinion is to define the relationship between eDP, LVDS, and Panel using graph concept: eDP context would have panel and bridge object according to graph definition of device tree. As a result, eDP context has already bridge_chain object for lvds bridge device and panel_binder-bridge object in exynos_drm_attach_lcd_bridge function context so it can add bridge_chain object to panel_binder-bridge as is there. I think lvds bridge device drivers could follow Linux driver model with this approach. Rob, it seems to need at least your ACK so that I can merge this patch series to exynos-drm-next. Thanks, Inki Dae Ajay Kumar (9): [RESEND PATCH V5 01/12] drm/exynos: Move DP setup out of hotplug workqueue [RESEND PATCH V5 02/12] drm/panel: add prepare and unprepare routines [RESEND PATCH V5 03/12] drm/exynos: dp: modify driver to support drm_panel [PATCH V5 04/12] drm/panel: Add driver for lvds/edp based panels [PATCH V5 05/12] Documentation: Add DT bindings for panel-lvds driver [RESEND PATCH V5 06/12] drm/bridge: add helper functions to support bridge chain [PATCH V5 07/12] drm/bridge: Add a driver which binds drm_bridge with drm_panel [RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining [RESEND PATCH V5 09/12] drm/exynos: dp: create bridge chain using ptn3460 and panel_binder Vincent Palatin (2): [PATCH V5 10/12] Documentation: Add DT bindings for ps8622/ps8625 bridge driver [PATCH V5 11/12] drm/bridge: Add ps8622/ps8625 bridge driver Rahul Sharma (1): [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver .../devicetree/bindings/drm/bridge/ps8622.txt | 21 + .../devicetree/bindings/panel/panel-lvds.txt | 50 ++ .../devicetree/bindings/video/exynos_dp.txt|2 + drivers/gpu/drm/bridge/Kconfig | 15 + drivers/gpu/drm/bridge/Makefile|2 + drivers/gpu/drm/bridge/panel_binder.c | 193 drivers/gpu/drm/bridge/ps8622.c| 476 drivers/gpu/drm/bridge/ptn3460.c | 137 +- drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_dp_core.c| 87 +++- drivers/gpu/drm/exynos/exynos_dp_core.h|2 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-lvds.c | 268 +++ include/drm/bridge/panel_binder.h | 44 ++ include/drm/bridge/ps8622.h| 41 ++ include/drm/bridge/ptn3460.h | 15 +- include/drm/drm_crtc.h | 72 +++
Re: [PATCH V5 05/12] Documentation: Add DT bindings for panel-lvds driver
On Fri, Jul 18, 2014 at 12:18:05PM +0530, Ajay kumar wrote: Hi Thierry, Thanks for your comments. On Fri, Jul 18, 2014 at 4:18 AM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Jul 18, 2014 at 02:20:39AM +0530, Ajay kumar wrote: +devicet...@vger.kernel.org On Fri, Jul 18, 2014 at 2:13 AM, Ajay Kumar ajaykumar...@samsung.com wrote: Add DT binding documentation for panel-lvds driver. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/panel/panel-lvds.txt | 50 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt b/Documentation/devicetree/bindings/panel/panel-lvds.txt new file mode 100644 index 000..fdf91da2 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt @@ -0,0 +1,50 @@ +panel interface for eDP/lvds panels + +Required properties: + - compatible: panel-lvds I think I've said this before. I oppose the addition of this binding. We need to list a device-specific compatible value here, wildcards like this aren't a good choice. And then if we have that compatible value we can move most of the optional properties below into a driver. Yes, panel-lvds is a wildcard for all lvds panels. And since lvds panels from different vendors have different values for power_up_delay, delay from video_to_backlight etc, I thought its better to pick them up from device tree. What I'm saying is that we shouldn't be adding this type of wildcard. Instead the compatible property needs to list the specific type of panel and since the driver will match on that specific compatible, the values for the delays etc. are all implicit and don't have to be listed in device tree. +Optional properties: If all these properties are optional, then what happens if a device tree node doesn't contain any of them? Doesn't that turn the driver into one big no-op? No! We need to provide lcd-supply and backlight-supply. What are those? I don't see them described anywhere. + -lcd-enable-gpios: + panel LCD poweron GPIO. + Indicates which GPIO needs to be powered up as output + to powerup/enable the switch to the LCD panel. + -backlight-enable-gpios: + panel LED enable GPIO. + Indicates which GPIO needs to be powered up as output + to enable the backlight. I've also said before that this really belongs in a backlight driver. Chances are that you'll want to have a way to set the brightness of the backlight as well, so simply an enable GPIO won't be good enough. Ok. I can handle this in backlight driver itself (with some minor glitches). You can make it work without glitches as well and we've discussed this before. But, how do I map bridge functions to panel functions now? The bridge supports (pre_enable, enable, disable and post_disable) which I map with (prepare, enable, disable and unprepare) of the panel, using a sample layer called bridge to panel_binder. Moving out the backlight control from panel means I really don't need those extra panel calls(prepare and unprepare)! Then how to distribute 2 panel calls(enable and disable) across 4 bridge calls? The .prepare() and .unprepare() functions are useful irrespective of backlight control. What you want to separate is powering up the panel from enabling the backlight. So .prepare() could be what's doing the power up of the panel (and possibly other initialization required to make it work) and .enable() could be as simple as turning on the backlight. What I'm saying is rather than use a backlight-enable-gpios property in the panel, that property should be part of the backlight device and the GPIO can then be toggled by the backlight driver when the backlight is enabled. + -panel-prepare-delay: + delay value in ms required for panel_prepare process + Delay in ms needed for the panel LCD unit to + powerup completely. + ex: delay needed till eDP panel throws HPD. + delay needed so that we cans tart reading edid. If the panel signals HPD then we don't need this delay at all and we should just wait for HPD instead. Not always for HPD, we need to wait for EDID module as well. I always thought that HPD signalled readiness from the panel to provide EDID, too. Are there really panels that need additional delays after HPD has been signalled until the EDID can be read? Are there maybe other ways to detect that EDID can't be read? + -panel-enable-delay: + delay value in ms required for panel_enable process + Delay in
Re: [RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining
On 2014년 07월 18일 05:43, Ajay Kumar wrote:
Modify the driver to invoke callbacks for the next bridge
in the bridge chain.
Also, remove the drm_connector implementation from ptn3460,
since the same is implemented using panel_binder.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/ptn3460.c| 137
+--
drivers/gpu/drm/exynos/exynos_dp_core.c | 16 ++--
include/drm/bridge/ptn3460.h| 15 ++--
3 files changed, 39 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index d466696..5fe16c6 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -34,37 +34,15 @@
#define PTN3460_EDID_SRAM_LOAD_ADDR 0x85
struct ptn3460_bridge {
- struct drm_connector connector;
struct i2c_client *client;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
- struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
u32 edid_emulation;
bool enabled;
};
-static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
- u8 *buf, int len)
-{
- int ret;
-
- ret = i2c_master_send(ptn_bridge-client, addr, 1);
- if (ret = 0) {
- DRM_ERROR(Failed to send i2c command, ret=%d\n, ret);
- return ret;
- }
-
- ret = i2c_master_recv(ptn_bridge-client, buf, len);
- if (ret = 0) {
- DRM_ERROR(Failed to recv i2c data, ret=%d\n, ret);
- return ret;
- }
-
- return 0;
-}
-
static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
char val)
{
@@ -126,6 +104,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
+ drm_next_bridge_pre_enable(bridge);
+
/*
* There's a bug in the PTN chip where it falsely asserts hotplug before
* it is fully functional. We're forced to wait for the maximum start up
@@ -142,6 +122,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
static void ptn3460_enable(struct drm_bridge *bridge)
{
+ drm_next_bridge_enable(bridge);
}
static void ptn3460_disable(struct drm_bridge *bridge)
@@ -153,6 +134,8 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge-enabled = false;
+ drm_next_bridge_disable(bridge);
+
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
@@ -162,6 +145,7 @@ static void ptn3460_disable(struct drm_bridge *bridge)
static void ptn3460_post_disable(struct drm_bridge *bridge)
{
+ drm_next_bridge_post_disable(bridge);
}
void ptn3460_bridge_destroy(struct drm_bridge *bridge)
@@ -173,6 +157,9 @@ void ptn3460_bridge_destroy(struct drm_bridge *bridge)
gpio_free(ptn_bridge-gpio_pd_n);
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_free(ptn_bridge-gpio_rst_n);
+
+ drm_next_bridge_destroy(bridge);
+
/* Nothing else to free, we've got devm allocated memory */
}
@@ -184,81 +171,10 @@ struct drm_bridge_funcs ptn3460_bridge_funcs = {
.destroy = ptn3460_bridge_destroy,
};
-int ptn3460_get_modes(struct drm_connector *connector)
-{
- struct ptn3460_bridge *ptn_bridge;
- u8 *edid;
- int ret, num_modes;
- bool power_off;
-
- ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
-
- if (ptn_bridge-edid)
- return drm_add_edid_modes(connector, ptn_bridge-edid);
-
- power_off = !ptn_bridge-enabled;
- ptn3460_pre_enable(ptn_bridge-bridge);
-
- edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
- if (!edid) {
- DRM_ERROR(Failed to allocate edid\n);
- return 0;
- }
-
- ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
- EDID_LENGTH);
- if (ret) {
- kfree(edid);
- num_modes = 0;
- goto out;
- }
-
- ptn_bridge-edid = (struct edid *)edid;
- drm_mode_connector_update_edid_property(connector, ptn_bridge-edid);
-
- num_modes = drm_add_edid_modes(connector, ptn_bridge-edid);
-
-out:
- if (power_off)
- ptn3460_disable(ptn_bridge-bridge);
-
- return num_modes;
-}
-
-struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
-{
- struct ptn3460_bridge *ptn_bridge;
-
- ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
-
- return ptn_bridge-encoder;
-}
-
-struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
- .get_modes = ptn3460_get_modes,
- .best_encoder = ptn3460_best_encoder,
-};
-
-enum drm_connector_status ptn3460_detect(struct drm_connector *connector,
- bool force)
-{
-
Re: [RESEND PATCH V5 03/12] drm/exynos: dp: modify driver to support drm_panel
On Fri, Jul 18, 2014 at 02:13:49AM +0530, Ajay Kumar wrote: [...] diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig [...] depends on DRM_EXYNOS_FIMD ARCH_EXYNOS (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS) One of the reasons the current way of implementing bridges is that it doesn't scale, as shown by this ridiculous dependency. In patch [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver you add support for another type of bridge but it doesn't update this dependency. I suspect that in order for this to work properly you'll need to extend the dependency like so (rewritten to make it somewhat cleaner): depends on DRM_EXYNOS_FIMD ARCH_EXYNOS depends on DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS depends on DRM_PS8622=n || DRM_PS8622=y || DRM_PS8622=DRM_EXYNOS And you'll need one more of these lines for each new bridge chip that you want to support. Thierry pgpqKEq56NuBZ.pgp Description: PGP signature
Re: [RESEND PATCH V5 03/12] drm/exynos: dp: modify driver to support drm_panel
On Fri, Jul 18, 2014 at 02:13:49AM +0530, Ajay Kumar wrote:
Add drm_panel controls to support powerup/down of the
eDP panel, if one is present at the sink side.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos_dp.txt|2 +
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_dp_core.c| 45
drivers/gpu/drm/exynos/exynos_dp_core.h|2 +
4 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 53dbccf..c029a09 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -51,6 +51,8 @@ Required properties for dp-controller:
LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
- display-timings: timings for the connected panel as described by
Documentation/devicetree/bindings/video/display-timing.txt
+ -edp-panel:
+ phandle for the edp/lvds drm_panel node.
There's really no need for the edp- prefix here. Also please don't use
drm_panel in the binding description since it makes no sense outside of
DRM (and bindings need to be OS agnostic).
Also: eDP and LVDS
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a94b114..b3d0d9b 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,6 +28,7 @@
#include drm/drmP.h
#include drm/drm_crtc.h
#include drm/drm_crtc_helper.h
+#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
@@ -1029,6 +1030,9 @@ static int exynos_dp_create_connector(struct
exynos_drm_display *display,
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
+ if (dp-edp_panel)
+ drm_panel_attach(dp-edp_panel, dp-connector);
This function can fail, so you really need to do some error-checking
here.
@@ -1063,11 +1067,13 @@ static void exynos_dp_poweron(struct exynos_dp_device
*dp)
if (dp-dpms_mode == DRM_MODE_DPMS_ON)
return;
+ drm_panel_prepare(dp-edp_panel);
clk_prepare_enable(dp-clock);
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
enable_irq(dp-irq);
exynos_dp_setup(dp);
+ drm_panel_enable(dp-edp_panel);
These two as well. clk_prepare_enable() can also fail by the way.
exynos_dp_init_dp() can also fail theoretically (it returns int) but
never returns anything other than 0, so it could just as well return
void.
@@ -1075,10 +1081,12 @@ static void exynos_dp_poweroff(struct
exynos_dp_device *dp)
if (dp-dpms_mode != DRM_MODE_DPMS_ON)
return;
+ drm_panel_disable(dp-edp_panel);
disable_irq(dp-irq);
flush_work(dp-hotplug_work);
exynos_dp_phy_exit(dp);
clk_disable_unprepare(dp-clock);
+ drm_panel_unprepare(dp-edp_panel);
}
And these two also.
static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
@@ -1209,8 +1217,17 @@ err:
static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
{
int ret;
+ struct device_node *videomode_parent;
+
+ /* Receive video timing info from panel node
+ * if there is a panel node
+ */
+ if (dp-panel_node)
+ videomode_parent = dp-panel_node;
+ else
+ videomode_parent = dp-dev-of_node;
- ret = of_get_videomode(dp-dev-of_node, dp-panel.vm,
+ ret = of_get_videomode(videomode_parent, dp-panel.vm,
You shouldn't be grabbing the video timings from some random node like
this. Instead you should use the DRM panel's .get_modes() function to
query the supported modes. The panel may not (in fact, should not, at
least under most circumstances) define video timings in the device tree.
@@ -1341,6 +1353,21 @@ static int exynos_dp_probe(struct platform_device
*pdev)
if (ret)
return ret;
+ dp = devm_kzalloc(pdev-dev, sizeof(struct exynos_dp_device),
+ GFP_KERNEL);
+ if (!dp)
+ return -ENOMEM;
+
+ dp-panel_node = of_parse_phandle(dev-of_node, edp-panel, 0);
There should be no need to store the struct device_node * obtained here
in the context like this.
+ if (dp-panel_node) {
+ dp-edp_panel = of_drm_find_panel(dp-panel_node);
+ of_node_put(dp-panel_node);
Especially since after this that pointer may become invalid.
Thierry
pgp8ePn9e15ZK.pgp
Description: PGP signature
Re: [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
On 07/21/2014 05:11 PM, Chanwoo Choi wrote:
On 07/21/2014 04:38 PM, Arnd Bergmann wrote:
On Monday 21 July 2014 11:17:44 Chanwoo Choi wrote:
This patchset support Exynos3250 ADC (Analog Digital Converter) because
Exynos3250 has additional special clock for ADC IP.
Changes from v6:
- Use exynos3250-adc compatible string instead of exynos3250-adc-v2
- Use sclk clock name instead of sclk_adc
- Remove un-necessary macro for exyno-adc-data-v2 structure.
- Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
- Change the number of ADC channels (Exynos3250 has only two channels for
ADC)
Looks good to me. Two small requests:
a) if you don't mind, can you add my patch (1/2) to add support for s3c64xx
to
your series, adding your Signed-off-by line in addition to mine? I think
that one was noncontroversial, while the second patch (2/2) need some more
work to address the comments and do testing.
OK, I'll add this patch.
But, I have a question.
Your patch add following compatible string.
s3c64100-adc is right?
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = samsung,s3c64100-adc,
+ .data = exynos_adc_s3c64xx_data,
+ }, {
Additionally,
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt has not included
samsung,s3c6410-adc compatible string. Should I add this string in
exynos-adc.txt?
drivers/iio/adc/exynos-adc.c has not includeded following compatible string.
Should I add this compatible string on exynos-adc.c?
+ Must be samsung,s3c2410-adc for
+ the ADC in s3c2410 and compatibles
+ Must be samsung,s3c2416-adc for
+ the ADC in s3c2416 and compatibles
+ Must be samsung,s3c2440-adc for
+ the ADC in s3c2440 and compatibles
+ Must be samsung,s3c2440-adc for
+ the ADC in s3c2440 and compatibles
+ Must be samsung,s3c2443-adc for
+ the ADC in s3c2443 and compatibles
Thanks,
Chanwoo Choi
--
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: [RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining
On Fri, Jul 18, 2014 at 02:13:54AM +0530, Ajay Kumar wrote: [...] Also, remove the drm_connector implementation from ptn3460, since the same is implemented using panel_binder. I think that's a step backwards. In fact I think the panel-bridge binder driver shouldn't be needed at all. At least not for now. We have a very limited number of bridge drivers, so it shouldn't hurt at this stage to implement the connector instantiation within each driver. Once we have more bridge drivers, and therefore a better understanding of what they need, we can always add something like the panel-binder (though I think it should be library code, similar to the drm_encoder_helper_add() API, rather than this kind of self-contained object). Thierry pgpc11T1gmxjr.pgp Description: PGP signature
[PATCH 3/3] ARM: exynos_defconfig: Enable cpuidle driver
The cpuidle driver for Exynos supports all SoCs now. AFTR is supported only on Exynos4210 and Exynos5250 (WFI is used on other). Add the driver to default exynos config. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- arch/arm/configs/exynos_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index fc7d1683bf67..237434e26565 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -24,6 +24,12 @@ CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE=root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M console=ttySAC1,115200 init=/linuxrc mem=256M +CONFIG_CPU_IDLE=y +CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y +CONFIG_CPU_IDLE_GOV_LADDER=y +CONFIG_CPU_IDLE_GOV_MENU=y +CONFIG_ARM_BIG_LITTLE_CPUIDLE=y +CONFIG_ARM_EXYNOS_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y CONFIG_PM_RUNTIME=y -- 1.9.1 -- 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 2/3] ARM: EXYNOS: Enable cpuidle in WFI on all SoCs
Add cpuidle device for each SoC but set AFTR enter function only on
supported ones (for now these are only Exynos4210 and Exynos5250). For
other chipsets use only WFI.
This actually does not give any special energy-saving benefits but
allows to track the idle time of each core.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 2a43a1734eca..4109d592f6fc 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -171,14 +171,20 @@ static void exynos_restart(enum reboot_mode mode, const
char *cmd)
static struct platform_device exynos_cpuidle = {
.name = exynos_cpuidle,
- .dev.platform_data = exynos_enter_aftr,
+ /*
+* Currently AFTR is not implemented for each SoC.
+* Set this to exynos_enter_aftr() only for supported SoCs.
+*/
+ .dev.platform_data = NULL,
.id= -1,
};
void __init exynos_cpuidle_init(void)
{
if (soc_is_exynos4210() || soc_is_exynos5250())
- platform_device_register(exynos_cpuidle);
+ exynos_cpuidle.dev.platform_data = exynos_enter_aftr;
+
+ platform_device_register(exynos_cpuidle);
}
void __init exynos_cpufreq_init(void)
--
1.9.1
--
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: [GIT PULL 4/5] Samsung exynos_mct update for v3.17
On 07/20/2014 12:06 AM, Olof Johansson wrote: On Sat, Jul 19, 2014 at 09:52:52AM +0900, Kukjin Kim wrote: Note that this is also based on 3.16-rc5 because of dependency with previous samsung fixes including exynos_mct already merged in mainline during -rc. The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab: Linux 3.16-rc5 (2014-07-13 14:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/exynos-mct for you to fetch changes up to 1a631118c1d085fe162f3b6d44f710c72206ef2d: clocksource: exynos_mct: Only use 32-bits where possible (2014-07-19 03:07:52 +0900) exynos_mct update for v3.17 - only use 32-bit access for performance benefits on exynos 32-bit system and this means ARCH timer should be supported on exynos 64-bit system instead of current MCT. - use readl_relaxed/writel_relaxed to consistently use the proper functions in exynos_mct. There's no reason for these to go through arm-soc, is there? They should go through the clocksource tree (Daniel Lezcano / Thomas Gleixner). They also lack acks from them if they for some reason need to go through arm-soc. Yes, that's right. Furthermore I have been discussing with Doug about these patches before. Kukjin, is there any dependency on these patches ? -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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 v6 10/14] drm/panel: add S6E3FA0 driver
On 07/18/2014 03:49 AM, YoungJun Cho wrote:
Hi Thierry,
Thank you a lot for kind comments.
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
[...]
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER 0xb0
+#define MCS_AID0xb2
+#define MCS_ELVSSOPT 0xb6
+#define MCS_TEMPERATURE_SET0xb8
+#define MCS_PENTILE_CTRL 0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM 0xd7
+#define MCS_ALS0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1 0xf0
+#define MCS_GAMMA_UPDATE 0xf7
+#define MCS_KEY_LEV2 0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
Is this not a manufacturer specific command? I couldn't find it in the
DSI or DCS specifications, but it sounds like something standard (also
indicated by the DCS_ prefix). Can you point out the specification for
this?
Andrzej commented before and decided it as DCS one because if the value
is less than 0xb0, it is DCS one and the others are MCS one.
But still I'm not sure it is correct.
I would not say 'decided'. I have just stated that according to DCS
specification
it should be DCS command (below 0xb0), but it is not present in mipi dcs
specs.
On the other side many panels have it [1]:
[1]:
https://www.google.com/search?q=%22Write+Content+Adaptive+Brightness+Control%22
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+#define DEFAULT_VDDM_VAL 0x15
+
+struct s6e3fa0 {
+ struct device *dev;
+ struct drm_panelpanel;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc*reset_gpio;
+ struct videomodevm;
+
+ unsigned intpower_on_delay;
+ unsigned intreset_delay;
+ unsigned intinit_delay;
+ unsigned intwidth_mm;
+ unsigned intheight_mm;
+
+ unsigned char id;
+ unsigned char vddm;
+ unsigned intbrightness;
+};
Please don't use this kind of artificial padding. A simple space will
do.
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
Please turn this into a function so we can get proper type checking.
+
+/* VDD Memory Lookup Table contains pairs of {ReadValue, WriteValue} */
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+ {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+ {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+ {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+ {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+ {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+ {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+ {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+ {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+ {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+ {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+ {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+ {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+ {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+ {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+ {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
+ {0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
+ {0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
+ {0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
+ {0x5a, 0x4e}, {0x5b, 0x4f}, {0x5c, 0x50}, {0x5d, 0x51}, {0x5e, 0x52},
+ {0x5f, 0x53}, {0x60, 0x54}, {0x61, 0x55}, {0x62, 0x56}, {0x63, 0x57},
+ {0x64, 0x58}, {0x65, 0x59}, {0x66, 0x5a}, {0x67, 0x5b}, {0x68, 0x5c},
+ {0x69, 0x5d}, {0x6a, 0x5e}, {0x6b, 0x5f}, {0x6c, 0x60}, {0x6d, 0x61},
+ {0x6e, 0x62}, {0x6f, 0x63}, {0x70, 0x64}, {0x71, 0x65}, {0x72, 0x66},
+ {0x73, 0x67}, {0x74, 0x68}, {0x75, 0x69}, {0x76, 0x6a}, {0x77, 0x6b},
+ {0x78, 0x6c}, {0x79, 0x6d}, {0x7a, 0x6e}, {0x7b, 0x6f}, {0x7c, 0x70},
+ {0x7d, 0x71}, {0x7e, 0x72}, {0x7f, 0x73},
+};
What's this used for?
This ldi contains an internal memory and requires an appropriate VDD.
Each panel stores OTP value for this vddm, so reads this value, finds
matching value with vddm_lut and writes the final value to avoid noise
issues from an inappropriate VDD.
+static
Re: [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
On Monday 21 July 2014 17:11:12 Chanwoo Choi wrote:
work to address the comments and do testing.
OK, I'll add this patch.
But, I have a question.
Your patch add following compatible string.
s3c64100-adc is right?
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = samsung,s3c64100-adc,
+ .data = exynos_adc_s3c64xx_data,
+ }, {
There is a typo, thanks for spotting this. It should be
samsung,s3c6410-adc, not samsung,s3c64100-adc.
b) For the compatible string, I think it makes sense to set a fallback to
samsung,exynos-adc-v2 in the case for exynos3250, making the DT
representation
compatible = samsung,exynos3250-adc, samsung,exynos-adc-v2;
It's not entirely compatible because of the addition of the clock, but
since the register layout is the same, I think it still make sense.
OK, I'll add it in exynos3250.dtsi as following:
adc: adc@126C {
- compatible = samsung,exynos-adc-v3;
+ compatible = samsung,exynos3250-adc,
+samsung,exynos-adc-v2;
reg = 0x126C 0x100, 0x10020718 0x4;
interrupts = 0 137 0;
- clock-names = adc, sclk_tsadc;
+ clock-names = adc, sclk;
clocks = cmu CLK_TSADC, cmu CLK_SCLK_TSADC;
#io-channel-cells = 1;
io-channel-ranges;
Ok, looks good.
Arnd
--
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: [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
On Monday 21 July 2014 17:17:44 Chanwoo Choi wrote:
On 07/21/2014 05:11 PM, Chanwoo Choi wrote:
On 07/21/2014 04:38 PM, Arnd Bergmann wrote:
On Monday 21 July 2014 11:17:44 Chanwoo Choi wrote:
This patchset support Exynos3250 ADC (Analog Digital Converter) because
Exynos3250 has additional special clock for ADC IP.
Changes from v6:
- Use exynos3250-adc compatible string instead of exynos3250-adc-v2
- Use sclk clock name instead of sclk_adc
- Remove un-necessary macro for exyno-adc-data-v2 structure.
- Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
- Change the number of ADC channels (Exynos3250 has only two channels for
ADC)
Looks good to me. Two small requests:
a) if you don't mind, can you add my patch (1/2) to add support for
s3c64xx to
your series, adding your Signed-off-by line in addition to mine? I think
that one was noncontroversial, while the second patch (2/2) need some
more
work to address the comments and do testing.
OK, I'll add this patch.
But, I have a question.
Your patch add following compatible string.
s3c64100-adc is right?
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = samsung,s3c64100-adc,
+ .data = exynos_adc_s3c64xx_data,
+ }, {
Additionally,
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt has not included
samsung,s3c6410-adc compatible string. Should I add this string in
exynos-adc.txt?
drivers/iio/adc/exynos-adc.c has not includeded following compatible string.
Should I add this compatible string on exynos-adc.c?
+ Must be samsung,s3c2410-adc for
+ the ADC in s3c2410 and compatibles
+ Must be samsung,s3c2416-adc for
+ the ADC in s3c2416 and compatibles
+ Must be samsung,s3c2440-adc for
+ the ADC in s3c2440 and compatibles
+ Must be samsung,s3c2440-adc for
+ the ADC in s3c2440 and compatibles
+ Must be samsung,s3c2443-adc for
+ the ADC in s3c2443 and compatibles
Yes, please.
Arnd
--
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 v6 10/14] drm/panel: add S6E3FA0 driver
On Mon, Jul 21, 2014 at 10:56:08AM +0200, Andrzej Hajda wrote:
On 07/18/2014 03:49 AM, YoungJun Cho wrote:
Hi Thierry,
Thank you a lot for kind comments.
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
[...]
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER 0xb0
+#define MCS_AID 0xb2
+#define MCS_ELVSSOPT 0xb6
+#define MCS_TEMPERATURE_SET 0xb8
+#define MCS_PENTILE_CTRL 0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM 0xd7
+#define MCS_ALS 0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1 0xf0
+#define MCS_GAMMA_UPDATE 0xf7
+#define MCS_KEY_LEV2 0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC 0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
Is this not a manufacturer specific command? I couldn't find it in the
DSI or DCS specifications, but it sounds like something standard (also
indicated by the DCS_ prefix). Can you point out the specification for
this?
Andrzej commented before and decided it as DCS one because if the value
is less than 0xb0, it is DCS one and the others are MCS one.
But still I'm not sure it is correct.
I would not say 'decided'. I have just stated that according to DCS
specification
it should be DCS command (below 0xb0), but it is not present in mipi dcs
specs.
On the other side many panels have it [1]:
[1]:
https://www.google.com/search?q=%22Write+Content+Adaptive+Brightness+Control%22
Yeah, my search yielded similar results. I wonder if this is perhaps
part of a draft future specification. I'll try to ask around some more
if anybody knows what the status of this is.
+static void s6e3fa0_read_mtp_id(struct s6e3fa0 *ctx)
+{
+ unsigned char id[MTP_ID_LEN];
+ int ret;
+
+ s6e3fa0_set_maximum_return_packet_size(ctx, MTP_ID_LEN);
+ ret = s6e3fa0_dcs_read(ctx, MIPI_DCS_GET_DISPLAY_ID, id, MTP_ID_LEN);
This also looks like a standard DCS command. I can't find it in either
v1.01 nor v1.02 of the specification, though. Do you know where it's
specified?
Yes, I also can't find it in DCS specification and there is no special
description in panel datasheet.
But as it is declared in include/video/mipi_display.h, so I think it
is a standard one.
On page 9 of the Introduction of MIPI by Renesas [2] there is info
it is a part of Nokia I/F command list, I guess it is kind of alpha
version of MIPI DCS.
[2]: http://wenku.baidu.com/view/658fab68af1ffc4ffe47acbe.html
That link is the only one which contains Nokia I/F command list on the
internet (that is, according to Google). But since this is already part
of the mipi_display.h header file we may as well use it.
I wonder if perhaps the READ_DDB_START and READ_DDB_CONTINUE commands
could be used as a replacement for this display ID.
Adding Guennadi, Tomi, Paul and Imre on Cc since they were involved with
the original patch that added mipi_display.h. Perhaps they remember what
the origin of this command is.
Thierry
pgpnFLO4L6LXU.pgp
Description: PGP signature
Re: [PATCH 00/12] drm/exynos/ipp: image post processing improvements, part three
Hi Inki, On 07/09/2014 04:47 PM, Inki Dae wrote: On 2014년 07월 03일 22:10, Andrzej Hajda wrote: This set of independent patches contains various improvement and fixes for exynos_drm ipp framework. The patchset is based on exynos-drm-next branch. Did you test ipp module using libdrm? If so, can you share the app? I would try to test this patch series before merging them. Mainline libdrm has no any ipp interfaces. I have used ipptest program developed by you :), with minor changes. More advanced tests are on my TODO list, but for this patchset ipptest seems to be OK - the patches are mainly cleanup patches. Regards Andrzej Thanks, Inki Dae Regards Andrzej Andrzej Hajda (12): drm/exynos/ipp: remove type casting drm/exynos/ipp: remove unused field from exynos_drm_ipp_private drm/exynos/ipp: remove struct exynos_drm_ipp_private drm/exynos/ipp: correct address type drm/exynos/ipp: remove temporary variable drm/exynos/ipp: remove incorrect checks of list_first_entry result drm/exynos/ipp: simplify memory check function drm/exynos/ipp: remove useless registration checks drm/exynos/ipp: simplify ipp_find_obj drm/exynos/ipp: remove redundant messages drm/exynos/ipp: simplify ipp_create_id drm/exynos/ipp: simplify ipp_find_driver drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 259 +--- drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +- 3 files changed, 73 insertions(+), 197 deletions(-) -- 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 v6 10/14] drm/panel: add S6E3FA0 driver
On Fri, Jul 18, 2014 at 10:49:35AM +0900, YoungJun Cho wrote:
Hi Thierry,
Thank you a lot for kind comments.
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
[...]
+static void s6e3fa0_set_maximum_return_packet_size(struct s6e3fa0 *ctx,
+ unsigned int size)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx-dev);
+ const struct mipi_dsi_host_ops *ops = dsi-host-ops;
+
+ if (ops ops-transfer) {
+ unsigned char buf[] = {size, 0};
+ struct mipi_dsi_msg msg = {
+ .channel = dsi-channel,
+ .type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
+ .tx_len = sizeof(buf),
+ .tx_buf = buf
+ };
+
+ ops-transfer(dsi-host, msg);
+ }
+}
The Set Maximum Return Packet Size command is a standard command, so
please turn that into a generic function exposed by the DSI core.
For this and below standard DCS commands, you want to use generic functions,
but I have no idea for that.
Could you explain more detail?
The goal should be to make these standard DCS commands available to all
DSI peripherals, so the implementation should look something like this:
static int mipi_dsi_set_maximum_return_packet_size(struct mipi_dsi_device *dsi,
u16 size)
{
struct mipi_dsi_msg msg;
if (!dsi-ops || !dsi-ops-transfer)
return -ENOSYS;
memset(msg, 0, sizeof(msg));
msg.channel = dsi-channel;
msg.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE;
msg.tx_len = sizeof(size);
msg.tx_buf = size;
return dsi-ops-transfer(dsi-host, msg);
}
The above is somewhat special, since it isn't DCS. For DCS I'd suggest a
common prefix, like so:
enum mipi_dcs_tear_mode {
MIPI_DCS_TEAR_VBLANK,
MIPI_DCS_TEAR_BLANK,
};
static int mipi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dcs_tear_mode mode)
{
u8 data[2] = { MIPI_DSI_DCS_SET_TEAR_ON, mode };
struct mipi_dsi_msg msg;
if (!dsi-ops || !dsi-ops-transfer)
return -ENOSYS;
memset(msg, 0, sizeof(msg));
msg.channel = dsi-channel;
msg.type = MIPI_DSI_DCS_SHORT_WRITE_PARAM;
msg.tx_len = sizeof(data);
msg.tx_buf = data;
return dsi-ops-transfer(dsi-host, msg);
}
Thierry
pgpMAAGvUAroT.pgp
Description: PGP signature
Re: [PATCH 1/3] cpuidle: exynos: Allow to use the driver without AFTR
On 07/21/2014 10:36 AM, Krzysztof Kozlowski wrote:
Allow the driver to be used when AFTR enter function is not provided
(device platform data is NULL).
This actually does not give any special energy-saving benefits but
allows to track the idle time of each core. Additionally it is a safe
way to validate supplied platform data.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
I think we already talk about this in the mailing list several times.
It does not make sense to enable the cpuidle driver for WFI just for the
sake of tracking via sysfs some idle timings.
Using the cpuidle driver means using the underlying cpuidle
infrastructure with all the stats computation in the governor.
If there is a *real* need of a WFI cpuidle driver, then a generic WFI
cpuidle driver could be implemented to supersede this one.
It took a while to cleanup this driver and remove all the hacks around
this AFTR state... :)
---
drivers/cpuidle/cpuidle-exynos.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-exynos.c b/drivers/cpuidle/cpuidle-exynos.c
index 7c0151263828..5325a394be7e 100644
--- a/drivers/cpuidle/cpuidle-exynos.c
+++ b/drivers/cpuidle/cpuidle-exynos.c
@@ -77,7 +77,10 @@ static int exynos_cpuidle_probe(struct platform_device *pdev)
{
int ret;
+ /* If NULL enter only WFI */
exynos_enter_aftr = (void *)(pdev-dev.platform_data);
+ if (!exynos_enter_aftr)
+ exynos_idle_driver.state_count = 1;
ret = cpuidle_register(exynos_idle_driver, NULL);
if (ret) {
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
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 2/2] iio: exynos-adc: add experimental touchscreen support
On Sunday 20 July 2014 23:37:18 Hartmut Knaack wrote:
Jonathan Cameron schrieb:
On 18/07/14 20:29, Arnd Bergmann wrote:
- I simply register the input device from the adc driver
itself, as the at91 code does. The driver also supports
sub-nodes, but I don't understand how they are meant
to be used, so using those might be better.
So, the alternative you are (I think) referring to is to use
the buffered in kernel client interface. That way a separate
touch screen driver can use the output channels provided by IIO
in much the same way you might use a regulator or similar.
Note that whilst this is similar to the simple polled interface
used for things like the iio_hwmon driver, the data flow is
quite different (clearly the polled interfce would be
inappropriate here).
Whilst we've discussed it in the past for touch screen drivers
like this, usually the hardware isn't generic enough to be
of any real use if not being used as a touch screen. As such
it's often simpler to just have the support directly in the
driver (as you've observed the at91 driver does this).
Ok, I see. That's exactly the information I was looking for.
Whilst the interface has been there a while, it's not really had
all that much use. The original target was the simpler case
of 3D accelerometer where we have a generic iio to input
bridge driver. Time constraints meant that I haven't yet actually
formally submitted the input side of this. Whilst there are lots
of other things that can use this interface, right now nothing
actually does so.
Ok.
- The new exynos_read_s3c64xx_ts() function is intentionally
very similar to the existing exynos_read_raw() functions.
It should probably be changed, either by merging the two
into one, or by simplifying the exynos_read_s3c64xx_ts()
function. This depends a bit on the answers to the questions
above.
I'd be tempted to not bother keeping them that similar. It's
not a generic IIO channel so simplify it where possible.
Ok.
index 5f95638513d2..cf1d9f3e2492 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -34,6 +34,7 @@
#include linux/regulator/consumer.h
#include linux/of_platform.h
#include linux/err.h
+#include linux/input.h
Might want to make the input side optional at compile time...
I supose the existing parts are unlikely to be used much in headless
devices, but you never know. Maybe we just leave this until someone
shouts they want to be able to avoid compiling it in.
I expected the input stuff to just be left out by the compiler
if CONFIG_INPUT is not set. I'll try it out and change it if necessary.
struct completion completion;
+ boolread_ts;
u32 value;
+ u32 value2;
As I state further down, I'd rather keep a little
clear of the naming used in IIO for bits that aren't
going through IIO (less confusing!). Maybe just
have
u32 x, y;
Ok.
unsigned intversion;
};
@@ -390,12 +396,61 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return ret;
}
+static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long mask)
+{
+ struct exynos_adc *info = iio_priv(indio_dev);
+ unsigned long timeout;
+ int ret;
+
+ if (mask != IIO_CHAN_INFO_RAW)
+ return -EINVAL;
+
+ mutex_lock(indio_dev-mlock);
+ info-read_ts = 1;
Since info-read_ts is of type bool, use true/false.
Ok
+
+ reinit_completion(info-completion);
+
+ writel(ADC_S3C2410_TSC_PULL_UP_DISABLE | ADC_TSC_AUTOPST,
+ ADC_V1_TSC(info-regs));
+
+ /* Select the ts channel to be used and Trigger conversion */
+ info-data-start_conv(info, 0);
0 is a rather magic value. A define perhaps?
I'm not entirely sure about why we pass 0 here, it's either channel zero
being used for touchscreen, or the channel number being ignore after
we write to the TSC register above. I copied it from the original driver,
but it might be helpful if someone with access to the specs could comment
here.
I'll add a macro for now.
+
+ timeout = wait_for_completion_timeout
+ (info-completion, EXYNOS_ADC_TIMEOUT);
+ if (timeout == 0) {
+ dev_warn(indio_dev-dev, Conversion timed out! Resetting\n);
+ if (info-data-init_hw)
+ info-data-init_hw(info);
+ ret = -ETIMEDOUT;
+ } else {
+ *val = info-value;
+ *val2 = info-value2;
This is definitely abuse as those two values are not intended for
different values. If you want to do this please use different naming
and don't try to fiddle it into the IIO read raw framework.
As you've suggested above,
Re: [PATCH 1/3] cpuidle: exynos: Allow to use the driver without AFTR
On pon, 2014-07-21 at 11:53 +0200, Daniel Lezcano wrote:
On 07/21/2014 10:36 AM, Krzysztof Kozlowski wrote:
Allow the driver to be used when AFTR enter function is not provided
(device platform data is NULL).
This actually does not give any special energy-saving benefits but
allows to track the idle time of each core. Additionally it is a safe
way to validate supplied platform data.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
I think we already talk about this in the mailing list several times.
It does not make sense to enable the cpuidle driver for WFI just for the
sake of tracking via sysfs some idle timings.
Using the cpuidle driver means using the underlying cpuidle
infrastructure with all the stats computation in the governor.
If there is a *real* need of a WFI cpuidle driver, then a generic WFI
cpuidle driver could be implemented to supersede this one.
It took a while to cleanup this driver and remove all the hacks around
this AFTR state... :)
Sure, I understand.
Best regards,
Krzysztof
---
drivers/cpuidle/cpuidle-exynos.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-exynos.c
b/drivers/cpuidle/cpuidle-exynos.c
index 7c0151263828..5325a394be7e 100644
--- a/drivers/cpuidle/cpuidle-exynos.c
+++ b/drivers/cpuidle/cpuidle-exynos.c
@@ -77,7 +77,10 @@ static int exynos_cpuidle_probe(struct platform_device
*pdev)
{
int ret;
+ /* If NULL enter only WFI */
exynos_enter_aftr = (void *)(pdev-dev.platform_data);
+ if (!exynos_enter_aftr)
+ exynos_idle_driver.state_count = 1;
ret = cpuidle_register(exynos_idle_driver, NULL);
if (ret) {
--
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] ARM: EXYNOS: Fix suspend/resume sequences
Hi, On 15.07.2014 16:26, Tomasz Figa wrote: Forgot to CC Daniel and linux-pm. Sorry for the noise. On 15.07.2014 16:24, Tomasz Figa wrote: Due to recent consolidation of Exynos suspend and cpuidle code, some parts of suspend and resume sequences are executed two times, once from exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it breaks suspend, at least on Exynos4-based boards. In addition, simple core power down from a cpuidle driver could, in case of CPU 0 could result in calling functions that are specific to suspend and deeper idle states. This patch fixes the issue by moving those operations outside the CPU PM notifier into suspend and AFTR code paths. This leads to a bit of code duplication, but allows additional code simplification, so in the end more code is removed than added. Signed-off-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/pm.c| 164 ++- drivers/cpuidle/cpuidle-exynos.c | 25 +- 2 files changed, 80 insertions(+), 109 deletions(-) This is an important regression fix for 3.16 and today 3.16-rc6 was already released... Kukjin, could you pick up this patch and few others you missed and make sure that it is included in 3.16-rc7? If you are busy, maybe Arnd or Olof could take them directly? Best regards, Tomasz -- 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 2/2] iio: exynos-adc: add experimental touchscreen support
On Sunday 20 July 2014 13:28:42 Dmitry Torokhov wrote:
On Sun, Jul 20, 2014 at 02:51:37PM +0100, Jonathan Cameron wrote:
+
+do {
+ret =exynos_read_s3c64xx_ts(dev, NULL, x, y,
IIO_CHAN_INFO_RAW);
= exynos
+if (ret == -ETIMEDOUT)
+break;
+
+pressed = x y ADC_DATX_PRESSED;
+if (!pressed)
+break;
+
+input_report_abs(info-input, ABS_X, x ADC_DATX_MASK);
+input_report_abs(info-input, ABS_Y, y ADC_DATX_MASK);
+input_report_key(info-input, BTN_TOUCH, 1);
+input_sync(info-input);
+
+msleep(1);
+} while (1);
It would be nice to actually close the device even if someone is
touching screen. Please implement open/close methods and have them set a
flag that you would check here.
Ok. I think it's even better to move the request_irq() into the open function,
which will avoid the flag and defer the error handling into the actual opening,
as well as syncing the running irq with the close function.
+/* data from s3c2410_ts driver */
+info-input-name = S3C24xx TouchScreen;
+info-input-id.bustype = BUS_HOST;
+info-input-id.vendor = 0xDEAD;
+info-input-id.product = 0xBEEF;
You do not need to fill these entries with fake data.
Ok, I wondered about this, but didn't want to change too much from
the old driver (I changed the version number).
+info-input-id.version = 0x0200;
Do I need this?
@@ -576,6 +728,11 @@ static int exynos_adc_probe(struct platform_device
*pdev)
err_of_populate:
device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
+if (has_ts) {
+input_unregister_device(info-input);
+free_irq(info-tsirq, info);
Are we sure that device is quiesced here and interrupt won't arrive
between input_unregister_device() and free_irq()? I guess if you
properly implement open/close it won't matter.
Should be fixed now.
+err_iio:
iio_device_unregister(indio_dev);
err_irq:
free_irq(info-irq, info);
@@ -595,9 +752,12 @@ static int exynos_adc_remove(struct platform_device
*pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
+input_free_device(info-input);
Should be unregister, not free.
Ok.
Thanks a lot for the review! I'll send out the new version after some build
testing.
Arnd
--
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 2/2] iio: exynos-adc: add experimental touchscreen support
On Monday 21 July 2014 12:23:58 Arnd Bergmann wrote:
Thanks a lot for the review! I'll send out the new version after some build
testing.
Here are the changes I did to the adc driver based on the review comments.
I'll start a new thread for the updated version that includes the changes.
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 3d2caea05977..823d7ebc7f52 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -67,6 +67,9 @@
#define ADC_S3C2410_CON_SELMUX(x) (((x)0x7)3)
+/* touch screen always uses channel 0 */
+#define ADC_S3C2410_MUX_TS 0
+
/* ADCTSC Register Bits */
#define ADC_S3C2443_TSC_UD_SEN (1u 8)
#define ADC_S3C2410_TSC_YM_SEN (1u 7)
@@ -106,6 +109,7 @@
#define ADC_CON_EN_START (1u 0)
#define ADC_DATX_PRESSED (1u 15)
#define ADC_DATX_MASK 0xFFF
+#define ADC_DATY_MASK 0xFFF
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
@@ -123,10 +127,12 @@ struct exynos_adc {
struct completion completion;
- boolread_ts;
u32 value;
- u32 value2;
unsigned intversion;
+
+ boolread_ts;
+ u32 ts_x;
+ u32 ts_y;
};
struct exynos_adc_data {
@@ -396,21 +402,14 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return ret;
}
-static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan,
- int *val,
- int *val2,
- long mask)
+static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y)
{
struct exynos_adc *info = iio_priv(indio_dev);
unsigned long timeout;
int ret;
- if (mask != IIO_CHAN_INFO_RAW)
- return -EINVAL;
-
mutex_lock(indio_dev-mlock);
- info-read_ts = 1;
+ info-read_ts = true;
reinit_completion(info-completion);
@@ -418,7 +417,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
ADC_V1_TSC(info-regs));
/* Select the ts channel to be used and Trigger conversion */
- info-data-start_conv(info, 0);
+ info-data-start_conv(info, ADC_S3C2410_MUX_TS);
timeout = wait_for_completion_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
@@ -428,12 +427,12 @@ static int exynos_read_s3c64xx_ts(struct iio_dev
*indio_dev,
info-data-init_hw(info);
ret = -ETIMEDOUT;
} else {
- *val = info-value;
- *val2 = info-value2;
- ret = IIO_VAL_INT;
+ *x = info-ts_x;
+ *y = info-ts_y;
+ ret = 0;
}
- info-read_ts = 0;
+ info-read_ts = false;
mutex_unlock(indio_dev-mlock);
return ret;
@@ -445,8 +444,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
/* Read value */
if (info-read_ts) {
- info-value = readl(ADC_V1_DATX(info-regs)) ADC_DATX_MASK;
- info-value2 = readl(ADC_V1_DATY(info-regs)) ADC_DATX_MASK;
+ info-ts_x = readl(ADC_V1_DATX(info-regs));
+ info-ts_y = readl(ADC_V1_DATY(info-regs));
writel(ADC_TSC_WAIT4INT | ADC_S3C2443_TSC_UD_SEN,
ADC_V1_TSC(info-regs));
} else {
info-value = readl(ADC_V1_DATX(info-regs)) ADC_DATX_MASK;
@@ -477,7 +476,7 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
int ret;
do {
- ret =exynos_read_s3c64xx_ts(dev, NULL, x, y,
IIO_CHAN_INFO_RAW);
+ ret = exynos_read_s3c64xx_ts(dev, x, y);
if (ret == -ETIMEDOUT)
break;
@@ -486,11 +485,15 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
break;
input_report_abs(info-input, ABS_X, x ADC_DATX_MASK);
- input_report_abs(info-input, ABS_Y, y ADC_DATX_MASK);
+ input_report_abs(info-input, ABS_Y, y ADC_DATY_MASK);
input_report_key(info-input, BTN_TOUCH, 1);
input_sync(info-input);
msleep(1);
+
+ /* device may have been closed while touched */
+ if (!info-input-users)
+ return IRQ_HANDLED;
} while (1);
input_report_key(info-input, BTN_TOUCH, 0);
@@ -552,10 +555,28 @@ static int exynos_adc_remove_devices(struct device *dev,
void *c)
return 0;
}
+static int exynos_adc_ts_open(struct input_dev *dev)
+{
+ struct exynos_adc *info = input_get_drvdata(dev);
+
+ return request_threaded_irq(info-tsirq, NULL, exynos_ts_isr,
+ 0, touchscreen, info);
+}
+
Re: [PATCH 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
On 16.07.2014 01:59, Tomasz Figa wrote: On 15.07.2014 20:02, Kukjin Kim wrote: On 07/08/14 22:54, Tomasz Figa wrote: On 08.07.2014 15:48, Kukjin Kim wrote: Tomasz Figa wrote: Due to recently merged patches and previous merge conflicts, the Samsung PM Debug functionality no longer can be enabled. This patch fixes incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds missing header inclusion. Yes, you're right and it should be fixed...but I have comments... Signed-off-by: Tomasz Figat.f...@samsung.com --- arch/arm/plat-samsung/Kconfig| 8 +++- arch/arm/plat-samsung/pm-debug.c | 1 + 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 301b892..483c959 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -412,9 +412,14 @@ config S5P_DEV_MFC comment Power management +config HAVE_SAMSUNG_PM_DEBUG +bool +help + Allow compilation of Samsung PM debugging code. + config SAMSUNG_PM_DEBUG bool S3C2410 PM Suspend debug -depends on PM DEBUG_KERNEL DEBUG_S3C_UART +depends on PM DEBUG_KERNEL HAVE_SAMSUNG_PM_DEBUG help Say Y here if you want verbose debugging from the PM Suspend and Resume code. Seefile:Documentation/arm/Samsung-S3C24XX/Suspend.txt @@ -484,6 +489,7 @@ config S5P_SLEEP config DEBUG_S3C_UART depends on PLAT_SAMSUNG +select HAVE_SAMSUNG_PM_DEBUG Hmm... The DEBUG_S3C_UART will be '0' when we select DEBUG_S3C_UART0, then the HAVE_SAMSUNG_PM_DEBUG will not be selected so SAMSUNG_PM_DEBUG is also... Yes, that's right. I posted v2 after a while in another reply to this thread. Any updates? Or I missed your updated? I'm afraid you missed. V2 has been there since a long time posted as a reply to original patch. You can find it here: https://lkml.org/lkml/2014/6/25/301 Ping. Best regards, Tomasz -- 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] ARM: EXYNOS: Fix build with PM_SLEEP=n
Hi, On Saturday, July 19, 2014 04:42:34 AM Kukjin Kim wrote: On 07/16/14 20:59, Tomasz Figa wrote: Hi Krzysztof, On 14.07.2014 09:45, Krzysztof Kozlowski wrote: Fix building of exynos defconfig with disabled PM_SLEEP: CONFIG_PM_SLEEP=n CONFIG_PM_SLEEP_SMP=n CONFIG_SUSPEND=n by moving functions for power up/down of CPU and cluster to platsmp.c The build error messages: arch/arm/mach-exynos/built-in.o: In function `exynos_boot_secondary': arch/arm/mach-exynos/platsmp.c:111: undefined reference to `exynos_cpu_power_state' arch/arm/mach-exynos/platsmp.c:112: undefined reference to `exynos_cpu_power_up' arch/arm/mach-exynos/platsmp.c:116: undefined reference to `exynos_cpu_power_state' make: *** [vmlinux] Error 1 Signed-off-by: Krzysztof Kozlowskik.kozlow...@samsung.com --- Changes since v1: 1. Use different solution - just move the power up/down functions to a common place instead of adding stubs in common.h. Suggested by Tomasz Figa. --- arch/arm/mach-exynos/platsmp.c | 66 ++ arch/arm/mach-exynos/pm.c | 66 -- 2 files changed, 66 insertions(+), 66 deletions(-) + Bart, Reviewed-by: Tomasz Figat.f...@samsung.com Applied, thanks. Bart, I think this is better at this moment to fix the build breakage with disabling PM...if you have any comments, please let me know. To fix PM_SLEEP=n build itself (with ARM_EXYNOS_CPUIDLE=n) Krzysztof's patch is not enough and patch [1] is also needed (this patch is very simple so I think that it is okay for v3.16). For PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y config more changes are needed and they are contained in patch [2] (please note that this patch depends on patch [3] from Tomasz Figa which was redone recently into [4] so my patch also needs to be refreshed). However if you think that this would result in too much changes for v3.16 kernel we can make ARM_EXYNOS_CPUIDLE select (or depend on) PM_SLEEP for now and fix the issue completely later in v3.17 kernel. [1] [PATCH 1/2] ARM: EXYNOS: Fix build with PM_SLEEP=n part #2 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34080.html [2] [PATCH 2/2] ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34081.html [3] [PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32809.html [4] [PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34150.html Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- 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: [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
On 21.07.2014 10:00, Arnd Bergmann wrote:
On Monday 21 July 2014 10:52:28 Chanwoo Choi wrote:
Yes, your current version is certainly better than this, but another way
to address Tomasz' comment would be to change the binding to list the sclk
as optional for any device and make the code silently ignore missing sclk
entries, like:
info-sclk = devm_clk_get(pdev-dev, sclk);
if (IS_ERR(info-sclk)) {
switch (PTR_ERR(info-sclk)) {
case -EPROBE_DEFER:
/* silently return error so we can retry */
return -EPROBE_DEFER:
case -ENOENT:
/* silently ignore missing optional clk */
info-sclk = NULL;
break;
default:
/* any other error: clk is defined by doesn't work */
dev_err(pdev-dev, failed getting sclk clock, err =
%ld\n,
PTR_ERR(info-sclk));
return PTR_ERR(info-sclk));
}
}
I tested this patch suggested by you.
But, devm_clk_get returns always '-ENOENT' on follwong two cases:
Case 1.
ADC dt node in exynos3250.dtsi don't include 'sclk' clock as following:
adc: adc@126C {
compatible = samsung,exynos3250-adc;
reg = 0x126C 0x100, 0x10020718 0x4;
interrupts = 0 137 0;
clock-names = adc;
clocks = cmu CLK_TSADC;
#io-channel-cells = 1;
io-channel-ranges;
};
Case 2.
ADC dt node in exynos3250.dtsi don't include 'sclk' clock
but, exynos3250 clock controller don't support CLK_SCLK_TSADC clock as
following:
adc: adc@126C {
compatible = samsung,exynos3250-adc;
reg = 0x126C 0x100, 0x10020718 0x4;
interrupts = 0 137 0;
clock-names = adc, sclk;
clocks = cmu CLK_TSADC, cmu CLK_SCLK_TSADC;
#io-channel-cells = 1;
io-channel-ranges;
};
But neither of those cases is actually a correct DT representation for
exynos3250: The first case describes an ADC that doesn't need a second
clock, so if the hardware actually needs it to function, it is clearly
unsufficiently described. The second case is even worse because it refers
to a clock that isn't there. Actually that should probably return a different
error code, but that's a different matter.
So, I think exynos-adc needs to use 'needs_sclk' field suggested by Tomasz
Figa.
I don't mind you adding a field to the data, especially since you already
need to have separate structures to encode the different number of channels.
However, I don't see it as necessary either. What you do here is just
checking the DT representation for correctness and consistency. It's not
harmful but we don't normally do that because passing incorrect DT blobs
can cause an infinite number of other problems that we don't check for.
I believe we should be enforcing as much correctness on DT data as
possible without too much burden in the code. Otherwise how we are
supposed to know if an error is caused by wrong/missing data in DT, bug
in the driver or who knows else?
In this case making this clock required depending on compatible string
doesn't seem too bothersome to me.
Best regards,
Tomasz
--
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: [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
On Monday 21 July 2014 12:38:55 Tomasz Figa wrote: I believe we should be enforcing as much correctness on DT data as possible without too much burden in the code. Otherwise how we are supposed to know if an error is caused by wrong/missing data in DT, bug in the driver or who knows else? In this case making this clock required depending on compatible string doesn't seem too bothersome to me. It makes some sense given that we already need the separate compatible string (for the number of channels). Without that part, I'd probably prefer not having the new string just for the extra clock being required, that could be handled more easily by just making it an optional clock. Arnd -- 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] Exynos4: cpuidle: support dual CPUs with AFTR state
On 07/16/2014 07:34 PM, Bartlomiej Zolnierkiewicz wrote: Hi, On Friday, May 30, 2014 03:53:09 PM Bartlomiej Zolnierkiewicz wrote: Hi, On Friday, May 30, 2014 01:34:45 PM Tomasz Figa wrote: Hi Daniel, On 30.05.2014 11:30, Daniel Lezcano wrote: On 04/24/2014 07:42 PM, Tomasz Figa wrote: Hi Daniel, Please see my comments inline. Btw. Please fix your e-mail composer to properly wrap your messages around 7xth column, as otherwise they're hard to read. On 04.04.2014 11:48, Daniel Lezcano wrote: The following driver is for exynos4210. I did not yet finished the other boards, so I created a specific driver for 4210 which could be merged later. The driver is based on Colin Cross's driver found at: https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/ This one was based on a 3.4 kernel and an old API. It has been refreshed, simplified and based on the recent code cleanup I sent today. The AFTR could be entered when all the cpus (except cpu0) are down. In order to reach this situation, the couple idle states are used. There is a sync barrier at the entry and the exit of the low power function. So all cpus will enter and exit the function at the same time. At this point, CPU0 knows the other cpu will power down itself. CPU0 waits for the CPU1 to be powered down and then initiate the AFTR power down sequence. No interrupts are handled by CPU1, this is why we switch to the timer broadcast even if the local timer is not impacted by the idle state. When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then they both exit the idle function. This driver allows the exynos4210 to have the same power consumption at idle time than the one when we have to unplug CPU1 in order to let CPU0 to reach the AFTR state. This patch is a RFC because, we have to find a way to remove the macros definitions and cpu powerdown function without pulling the arch dependent headers. Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org --- arch/arm/mach-exynos/common.c| 11 +- drivers/cpuidle/Kconfig.arm |8 ++ drivers/cpuidle/Makefile |1 + drivers/cpuidle/cpuidle-exynos4210.c | 226 ++ [ ... ] Otherwise, I quite like the whole idea. I need to play a bit with CPU hotplug and PMU to verify that things couldn't really be simplified a bit, but in general this looks reasonably. Hi Tomasz, did you have time to look at this simplification ? Unfortunately I got preempted with other things to do and now I'm on vacation. I worked a bit with Bart (added on CC) on this and generally the conclusion was that all the things are necessary. He was also working to extend the driver to support Exynos4x12. Bart, has anything interesting showed up since we talked about this last time? Since we last looked into this I have fixed the standard AFTR support for Exynos3250 and started to work on adding Exynos3250 support to this driver (as Exynos3250 support has bigger priority than Exynos4x12 one). Unfortunately I also got preempted with other things so it is still unfinished and doesn't work yet. Moreover I had no possibility to test the new driver on Exynos4210 based Origen yet (I hope to do this next week). I have tested this patch on Origen board (Exynos4210 rev 1.1) and it causes system lockup (it seems that the code gets stuck on waiting for CPU1 to wake up). The kernels I have tried: * current -next + this patch + few fixes to bring it up to date * commit cd245f5 + this patch + some fixes * next-20140403 + your Exynos cpuidle patch series + this patch I have also tried with S5P_VA_SYSRAM replaced by S5P_INFORM5 to match Exynos 4210 rev 1.1 but it didn't help. U-Boot version used is: U-Boot 2012.07 (Sep 22 2012 - 05:12:41) for ORIGEN Could you please tell me which hardware/bootloader/kernel exactly have you used to test this patch? When I used it, it was on top of 3.15-rc1: https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/cpuidle/samsung-next The hardware was a exynos-4210 origen board ver A. Also could you please port/retest your patch over the current -next? Will do that in my free time after unstacking my emails after 2 weeks of vacations :) -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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] ARM: EXYNOS: Fix build with PM_SLEEP=n
On Monday, July 21, 2014 12:38:28 PM Bartlomiej Zolnierkiewicz wrote: Hi, On Saturday, July 19, 2014 04:42:34 AM Kukjin Kim wrote: On 07/16/14 20:59, Tomasz Figa wrote: Hi Krzysztof, On 14.07.2014 09:45, Krzysztof Kozlowski wrote: Fix building of exynos defconfig with disabled PM_SLEEP: CONFIG_PM_SLEEP=n CONFIG_PM_SLEEP_SMP=n CONFIG_SUSPEND=n by moving functions for power up/down of CPU and cluster to platsmp.c The build error messages: arch/arm/mach-exynos/built-in.o: In function `exynos_boot_secondary': arch/arm/mach-exynos/platsmp.c:111: undefined reference to `exynos_cpu_power_state' arch/arm/mach-exynos/platsmp.c:112: undefined reference to `exynos_cpu_power_up' arch/arm/mach-exynos/platsmp.c:116: undefined reference to `exynos_cpu_power_state' make: *** [vmlinux] Error 1 Signed-off-by: Krzysztof Kozlowskik.kozlow...@samsung.com --- Changes since v1: 1. Use different solution - just move the power up/down functions to a common place instead of adding stubs in common.h. Suggested by Tomasz Figa. --- arch/arm/mach-exynos/platsmp.c | 66 ++ arch/arm/mach-exynos/pm.c | 66 -- 2 files changed, 66 insertions(+), 66 deletions(-) + Bart, Reviewed-by: Tomasz Figat.f...@samsung.com Applied, thanks. Bart, I think this is better at this moment to fix the build breakage with disabling PM...if you have any comments, please let me know. To fix PM_SLEEP=n build itself (with ARM_EXYNOS_CPUIDLE=n) Krzysztof's patch is not enough and patch [1] is also needed (this patch is very simple so I think that it is okay for v3.16). Hmmm, I now see that you've applied Krzysztof's patch for v3.17 not v3.16. In that case how do you want to deal with PM_SLEEP=n build breakages for v3.16 and what do you mean with fix the build breakage with disabling PM? Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics For PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y config more changes are needed and they are contained in patch [2] (please note that this patch depends on patch [3] from Tomasz Figa which was redone recently into [4] so my patch also needs to be refreshed). However if you think that this would result in too much changes for v3.16 kernel we can make ARM_EXYNOS_CPUIDLE select (or depend on) PM_SLEEP for now and fix the issue completely later in v3.17 kernel. [1] [PATCH 1/2] ARM: EXYNOS: Fix build with PM_SLEEP=n part #2 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34080.html [2] [PATCH 2/2] ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34081.html [3] [PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32809.html [4] [PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34150.html Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- 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 v6 10/14] drm/panel: add S6E3FA0 driver
On 07/21/2014 11:19 AM, Thierry Reding wrote:
On Mon, Jul 21, 2014 at 10:56:08AM +0200, Andrzej Hajda wrote:
On 07/18/2014 03:49 AM, YoungJun Cho wrote:
Hi Thierry,
Thank you a lot for kind comments.
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
[...]
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER 0xb0
+#define MCS_AID 0xb2
+#define MCS_ELVSSOPT 0xb6
+#define MCS_TEMPERATURE_SET 0xb8
+#define MCS_PENTILE_CTRL 0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM 0xd7
+#define MCS_ALS 0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1 0xf0
+#define MCS_GAMMA_UPDATE 0xf7
+#define MCS_KEY_LEV2 0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC 0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
Is this not a manufacturer specific command? I couldn't find it in the
DSI or DCS specifications, but it sounds like something standard (also
indicated by the DCS_ prefix). Can you point out the specification for
this?
Andrzej commented before and decided it as DCS one because if the value
is less than 0xb0, it is DCS one and the others are MCS one.
But still I'm not sure it is correct.
I would not say 'decided'. I have just stated that according to DCS
specification
it should be DCS command (below 0xb0), but it is not present in mipi dcs
specs.
On the other side many panels have it [1]:
[1]:
https://www.google.com/search?q=%22Write+Content+Adaptive+Brightness+Control%22
Yeah, my search yielded similar results. I wonder if this is perhaps
part of a draft future specification. I'll try to ask around some more
if anybody knows what the status of this is.
+static void s6e3fa0_read_mtp_id(struct s6e3fa0 *ctx)
+{
+ unsigned char id[MTP_ID_LEN];
+ int ret;
+
+ s6e3fa0_set_maximum_return_packet_size(ctx, MTP_ID_LEN);
+ ret = s6e3fa0_dcs_read(ctx, MIPI_DCS_GET_DISPLAY_ID, id, MTP_ID_LEN);
This also looks like a standard DCS command. I can't find it in either
v1.01 nor v1.02 of the specification, though. Do you know where it's
specified?
Yes, I also can't find it in DCS specification and there is no special
description in panel datasheet.
But as it is declared in include/video/mipi_display.h, so I think it
is a standard one.
On page 9 of the Introduction of MIPI by Renesas [2] there is info
it is a part of Nokia I/F command list, I guess it is kind of alpha
version of MIPI DCS.
[2]: http://wenku.baidu.com/view/658fab68af1ffc4ffe47acbe.html
That link is the only one which contains Nokia I/F command list on the
internet (that is, according to Google). But since this is already part
of the mipi_display.h header file we may as well use it.
I wonder if perhaps the READ_DDB_START and READ_DDB_CONTINUE commands
could be used as a replacement for this display ID.
Adding Guennadi, Tomi, Paul and Imre on Cc since they were involved with
the original patch that added mipi_display.h. Perhaps they remember what
the origin of this command is.
I guess it was PCF8833 used in Nokia 6100 [1][2].
[1]: http://www.vintagecomputercables.com/datasheet/PCF8833_1.pdf
[2]:
http://www.elecfreaks.com/store/download/datasheet/shield/6100_Display_Driver.pdf
Regards
Andrzej
Thierry
--
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: [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
On Mon, Jul 21, 2014 at 12:40 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Fri, Jul 18, 2014 at 02:13:58AM +0530, Ajay Kumar wrote:
From: Rahul Sharma rahul.sha...@samsung.com
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 0ca6256..82e2942 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -31,6 +31,7 @@
#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
#include drm/bridge/panel_binder.h
+#include drm/bridge/ps8622.h
#include exynos_drm_drv.h
#include exynos_dp_core.h
@@ -999,6 +1000,10 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
if (find_bridge(nxp,ptn3460, bridge)) {
bridge_chain = ptn3460_init(dp-drm_dev, encoder,
bridge.client,
bridge.node);
+ } else if (find_bridge(parade,ps8622, bridge) ||
+ find_bridge(parade,ps8625, bridge)) {
+ bridge_chain = ps8622_init(dp-drm_dev, encoder, bridge.client,
+ bridge.node);
}
We really ought to be adding some sort of registry at some point.
Otherwise every driver that wants to use bridges needs to come up with a
similar set of helpers to instantiate them.
Also you're making this driver depend on (now) two bridges, whereas it
really shouldn't matter which exact types it supports. Bridges should be
exposed via a generic interface.
How about moving out the find_bridge() function into a common header file,
and also supporting the list of bridge_init declarations in the same file?
We get bridge chip node from phandle, and then pass the same node
to find_bridge() which searches the list using of_device_is_compatible()
to call the appropriate bridge_init function?
Ajay
--
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 V5 00/12] drm/exynos: few patches to enhance bridge chip support
Hi Inki, On Mon, Jul 21, 2014 at 1:21 PM, Inki Dae inki@samsung.com wrote: On 2014년 07월 18일 05:43, Ajay Kumar wrote: This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git This patchset also consolidates various inputs from the drm community regarding the bridge chaining concept: (1) [RFC V2 0/3] drm/bridge: panel and chaining http://www.spinics.net/lists/linux-samsung-soc/msg30160.html (2) [RFC V3 0/3] drm/bridge: panel and chaining http://www.spinics.net/lists/linux-samsung-soc/msg30507.html I have tested this after adding few DT changes for exynos5250-snow, exynos5420-peach-pit and exynos5800-peach-pi boards. The V4 series of this particular patchset was also tested by: Rahul Sharma rahul.sha...@samsung.com Javier Martinez Canillas jav...@dowhile0.org Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Changes since V3: -- Remove hotplug based initialization of exynos_dp -- Make exynos_dp work directly with drm_panel, remove dependency on panel_binder -- Minor cleanups in panel_binder and panel_lvds driver Changes since V4: -- Use gpiod interface for panel-lvds and ps8622 drivers. -- Address comments from Javier. -- Fix compilation issues when PANEL_BINDER is selected as module. -- Split Documentation patches from driver patches. -- Rebase on top of the tree. Hi Ajay, Thanks for your contribution. I am reviewing your patch series. Sorry for late. Below is my comment. How about using graph concept to bind eDP, LVDS bridge, and Panel? Your patch tries to bind bridge driver using find_bridge function, and this function tries to find bridge device node directly using of_find_compatible_node() again, which in turn make eDP driver to add all codes related to all bridge devices including all relevant bridge headers: i.e., if there are five bridge devices then eDP driver should try to find all of them. That is really not good. I agree. So my opinion is to define the relationship between eDP, LVDS, and Panel using graph concept: eDP context would have panel and bridge object according to graph definition of device tree. As a result, eDP context has already bridge_chain object for lvds bridge device and panel_binder-bridge object in exynos_drm_attach_lcd_bridge function context so it can add bridge_chain object to panel_binder-bridge as is there. I think lvds bridge device drivers could follow Linux driver model with this approach. Sorry, I didn't quite understand the graph concept. Already Thierry suggested of having a common repository for list of supported bridges. That way, we can move out bridge detection stuff from exynos_dp to a common file. Ajay Rob, it seems to need at least your ACK so that I can merge this patch series to exynos-drm-next. Thanks, Inki Dae Ajay Kumar (9): [RESEND PATCH V5 01/12] drm/exynos: Move DP setup out of hotplug workqueue [RESEND PATCH V5 02/12] drm/panel: add prepare and unprepare routines [RESEND PATCH V5 03/12] drm/exynos: dp: modify driver to support drm_panel [PATCH V5 04/12] drm/panel: Add driver for lvds/edp based panels [PATCH V5 05/12] Documentation: Add DT bindings for panel-lvds driver [RESEND PATCH V5 06/12] drm/bridge: add helper functions to support bridge chain [PATCH V5 07/12] drm/bridge: Add a driver which binds drm_bridge with drm_panel [RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining [RESEND PATCH V5 09/12] drm/exynos: dp: create bridge chain using ptn3460 and panel_binder Vincent Palatin (2): [PATCH V5 10/12] Documentation: Add DT bindings for ps8622/ps8625 bridge driver [PATCH V5 11/12] drm/bridge: Add ps8622/ps8625 bridge driver Rahul Sharma (1): [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver .../devicetree/bindings/drm/bridge/ps8622.txt | 21 + .../devicetree/bindings/panel/panel-lvds.txt | 50 ++ .../devicetree/bindings/video/exynos_dp.txt|2 + drivers/gpu/drm/bridge/Kconfig | 15 + drivers/gpu/drm/bridge/Makefile|2 + drivers/gpu/drm/bridge/panel_binder.c | 193 drivers/gpu/drm/bridge/ps8622.c| 476 drivers/gpu/drm/bridge/ptn3460.c | 137 +- drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_dp_core.c| 87 +++- drivers/gpu/drm/exynos/exynos_dp_core.h|2 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile |1 +
Re: [RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining
Hi Thierry, On Mon, Jul 21, 2014 at 1:52 PM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Jul 18, 2014 at 02:13:54AM +0530, Ajay Kumar wrote: [...] Also, remove the drm_connector implementation from ptn3460, since the same is implemented using panel_binder. I think that's a step backwards. In fact I think the panel-bridge binder driver shouldn't be needed at all. At least not for now. We have a very limited number of bridge drivers, so it shouldn't hurt at this stage to implement the connector instantiation within each driver. Once we have more bridge drivers, and therefore a better understanding of what they need, we can always add something like the panel-binder (though I think it should be library code, similar to the drm_encoder_helper_add() API, rather than this kind of self-contained object). panel_binder was needed to wrap around panel as a bridge, and this was in turn needed because people wanted to represent a bridge+panel combo as a chain of bridges. So, if we choose to drop panel_binder, we choose to drop the idea of chaining the bridges, and end up calling drm_panel functions directly from individual bridges. And, the bridge will implement the connector functions as you suggested. I am okay with this, if Daniel/Rob don't have an issue with this. Ajay -- 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: [RESEND PATCH V5 03/12] drm/exynos: dp: modify driver to support drm_panel
Hi Thierry,
On Mon, Jul 21, 2014 at 1:44 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Fri, Jul 18, 2014 at 02:13:49AM +0530, Ajay Kumar wrote:
Add drm_panel controls to support powerup/down of the
eDP panel, if one is present at the sink side.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos_dp.txt|2 +
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_dp_core.c| 45
drivers/gpu/drm/exynos/exynos_dp_core.h|2 +
4 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 53dbccf..c029a09 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -51,6 +51,8 @@ Required properties for dp-controller:
LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
- display-timings: timings for the connected panel as described by
Documentation/devicetree/bindings/video/display-timing.txt
+ -edp-panel:
+ phandle for the edp/lvds drm_panel node.
There's really no need for the edp- prefix here. Also please don't use
drm_panel in the binding description since it makes no sense outside of
DRM (and bindings need to be OS agnostic).
Also: eDP and LVDS
Ok. Will fix this.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a94b114..b3d0d9b 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,6 +28,7 @@
#include drm/drmP.h
#include drm/drm_crtc.h
#include drm/drm_crtc_helper.h
+#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
@@ -1029,6 +1030,9 @@ static int exynos_dp_create_connector(struct
exynos_drm_display *display,
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
+ if (dp-edp_panel)
+ drm_panel_attach(dp-edp_panel, dp-connector);
This function can fail, so you really need to do some error-checking
here.
Ok.
@@ -1063,11 +1067,13 @@ static void exynos_dp_poweron(struct
exynos_dp_device *dp)
if (dp-dpms_mode == DRM_MODE_DPMS_ON)
return;
+ drm_panel_prepare(dp-edp_panel);
clk_prepare_enable(dp-clock);
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
enable_irq(dp-irq);
exynos_dp_setup(dp);
+ drm_panel_enable(dp-edp_panel);
These two as well. clk_prepare_enable() can also fail by the way.
exynos_dp_init_dp() can also fail theoretically (it returns int) but
never returns anything other than 0, so it could just as well return
void.
Ok. Will fix this.
@@ -1075,10 +1081,12 @@ static void exynos_dp_poweroff(struct
exynos_dp_device *dp)
if (dp-dpms_mode != DRM_MODE_DPMS_ON)
return;
+ drm_panel_disable(dp-edp_panel);
disable_irq(dp-irq);
flush_work(dp-hotplug_work);
exynos_dp_phy_exit(dp);
clk_disable_unprepare(dp-clock);
+ drm_panel_unprepare(dp-edp_panel);
}
And these two also.
Ok.
static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
@@ -1209,8 +1217,17 @@ err:
static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
{
int ret;
+ struct device_node *videomode_parent;
+
+ /* Receive video timing info from panel node
+ * if there is a panel node
+ */
+ if (dp-panel_node)
+ videomode_parent = dp-panel_node;
+ else
+ videomode_parent = dp-dev-of_node;
- ret = of_get_videomode(dp-dev-of_node, dp-panel.vm,
+ ret = of_get_videomode(videomode_parent, dp-panel.vm,
You shouldn't be grabbing the video timings from some random node like
this. Instead you should use the DRM panel's .get_modes() function to
query the supported modes. The panel may not (in fact, should not, at
least under most circumstances) define video timings in the device tree.
Right, I am planning to use panel-simple driver by adding drm_display_mode
structure for the lvds panels. So, I would not need this change.
@@ -1341,6 +1353,21 @@ static int exynos_dp_probe(struct platform_device
*pdev)
if (ret)
return ret;
+ dp = devm_kzalloc(pdev-dev, sizeof(struct exynos_dp_device),
+ GFP_KERNEL);
+ if (!dp)
+ return -ENOMEM;
+
+ dp-panel_node = of_parse_phandle(dev-of_node, edp-panel, 0);
There should be no need to store the struct device_node * obtained here
in the context like this.
+ if (dp-panel_node) {
+ dp-edp_panel = of_drm_find_panel(dp-panel_node);
+ of_node_put(dp-panel_node);
Especially since after this that pointer may become invalid.
Same
Re: [PATCH] ASoC: samsung: remove MACH_SMDKC100
On Sat, Jul 19, 2014 at 04:01:27AM +0900, Kukjin Kim wrote: This removes MACH_SMDKC100 because of no more support for SMDKC100. Reported-by: Paul Bolle pebo...@tiscali.nl Signed-off-by: Kukjin Kim kgene@samsung.com Cc: Mark Brown broo...@linaro.org This doesn't apply against current -next, can you please check what's going on there? signature.asc Description: Digital signature
Re: [PATCH V5 05/12] Documentation: Add DT bindings for panel-lvds driver
Hi Thierry, On Mon, Jul 21, 2014 at 1:22 PM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Jul 18, 2014 at 12:18:05PM +0530, Ajay kumar wrote: Hi Thierry, Thanks for your comments. On Fri, Jul 18, 2014 at 4:18 AM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Jul 18, 2014 at 02:20:39AM +0530, Ajay kumar wrote: +devicet...@vger.kernel.org On Fri, Jul 18, 2014 at 2:13 AM, Ajay Kumar ajaykumar...@samsung.com wrote: Add DT binding documentation for panel-lvds driver. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/panel/panel-lvds.txt | 50 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt b/Documentation/devicetree/bindings/panel/panel-lvds.txt new file mode 100644 index 000..fdf91da2 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt @@ -0,0 +1,50 @@ +panel interface for eDP/lvds panels + +Required properties: + - compatible: panel-lvds I think I've said this before. I oppose the addition of this binding. We need to list a device-specific compatible value here, wildcards like this aren't a good choice. And then if we have that compatible value we can move most of the optional properties below into a driver. Yes, panel-lvds is a wildcard for all lvds panels. And since lvds panels from different vendors have different values for power_up_delay, delay from video_to_backlight etc, I thought its better to pick them up from device tree. What I'm saying is that we shouldn't be adding this type of wildcard. Instead the compatible property needs to list the specific type of panel and since the driver will match on that specific compatible, the values for the delays etc. are all implicit and don't have to be listed in device tree. +Optional properties: If all these properties are optional, then what happens if a device tree node doesn't contain any of them? Doesn't that turn the driver into one big no-op? No! We need to provide lcd-supply and backlight-supply. What are those? I don't see them described anywhere. + -lcd-enable-gpios: + panel LCD poweron GPIO. + Indicates which GPIO needs to be powered up as output + to powerup/enable the switch to the LCD panel. + -backlight-enable-gpios: + panel LED enable GPIO. + Indicates which GPIO needs to be powered up as output + to enable the backlight. I've also said before that this really belongs in a backlight driver. Chances are that you'll want to have a way to set the brightness of the backlight as well, so simply an enable GPIO won't be good enough. Ok. I can handle this in backlight driver itself (with some minor glitches). You can make it work without glitches as well and we've discussed this before. But, how do I map bridge functions to panel functions now? The bridge supports (pre_enable, enable, disable and post_disable) which I map with (prepare, enable, disable and unprepare) of the panel, using a sample layer called bridge to panel_binder. Moving out the backlight control from panel means I really don't need those extra panel calls(prepare and unprepare)! Then how to distribute 2 panel calls(enable and disable) across 4 bridge calls? The .prepare() and .unprepare() functions are useful irrespective of backlight control. What you want to separate is powering up the panel from enabling the backlight. So .prepare() could be what's doing the power up of the panel (and possibly other initialization required to make it work) and .enable() could be as simple as turning on the backlight. What I'm saying is rather than use a backlight-enable-gpios property in the panel, that property should be part of the backlight device and the GPIO can then be toggled by the backlight driver when the backlight is enabled. + -panel-prepare-delay: + delay value in ms required for panel_prepare process + Delay in ms needed for the panel LCD unit to + powerup completely. + ex: delay needed till eDP panel throws HPD. + delay needed so that we cans tart reading edid. If the panel signals HPD then we don't need this delay at all and we should just wait for HPD instead. Not always for HPD, we need to wait for EDID module as well. I always thought that HPD signalled readiness from the panel to provide EDID, too. Are there really panels that need additional delays after HPD has been signalled until the EDID can be read? Are there maybe other ways to detect that EDID can't be read? +
Re: [RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining
On Mon, Jul 21, 2014 at 05:28:13PM +0530, Ajay kumar wrote: Hi Thierry, On Mon, Jul 21, 2014 at 1:52 PM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Jul 18, 2014 at 02:13:54AM +0530, Ajay Kumar wrote: [...] Also, remove the drm_connector implementation from ptn3460, since the same is implemented using panel_binder. I think that's a step backwards. In fact I think the panel-bridge binder driver shouldn't be needed at all. At least not for now. We have a very limited number of bridge drivers, so it shouldn't hurt at this stage to implement the connector instantiation within each driver. Once we have more bridge drivers, and therefore a better understanding of what they need, we can always add something like the panel-binder (though I think it should be library code, similar to the drm_encoder_helper_add() API, rather than this kind of self-contained object). panel_binder was needed to wrap around panel as a bridge, and this was in turn needed because people wanted to represent a bridge+panel combo as a chain of bridges. So, if we choose to drop panel_binder, we choose to drop the idea of chaining the bridges, and end up calling drm_panel functions directly from individual bridges. And, the bridge will implement the connector functions as you suggested. I am okay with this, if Daniel/Rob don't have an issue with this. I think bridge chaining and panel handling are separate issues. That's why I think we shouldn't mix them like this. From earlier discussion[0] the conclusion was that the final element in the chain should implement a connector (with the appropriate type). Often that last element would be an encoder (when there are no bridges). Sometimes the last element would be a bridge. It's logical for that same element to also implement the panel integration since it's closely tied to the connector. Thierry [0]: http://lists.freedesktop.org/archives/dri-devel/2014-May/059685.html pgpheuHZdQjQ3.pgp Description: PGP signature
Re: [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Recent patch by Tomasz Figa (irqchip: gic: Fix core ID calculation when topology is read from DT) fixed GIC driver to filter cluster ID from values returned by cpu_logical_map() for SoCs having registers mapped without per-CPU banking making it is possible to add CPU nodes for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also required by future changes adding initialization of cpuidle states in Exynos cpuidle driver through DT. This conflicts with work in the thread cpufreq: use generic cpufreq drivers for exynos platforms which is already in its 7th iteration. Perhaps best to work directly with Thomas to help him finish that series? Daniel -- 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 v8 00/13] Add Maxim 77802 PMIC support
Hello Lee, On 07/14/2014 01:35 PM, Javier Martinez Canillas wrote: * Patches 1-7 from v7 are not included since those were improvements to the max77686 mfd driver and can be applied independently. Lee Jones said that he is going to pick them from the posted v7 series. Thanks a lot for picking the max77686 preparatory patches. Since there are cross-subsystems dependencies, I think that the best way to sort this out is if relevant maintainers ack the patches so 01/13 to 012/13 can be merged through the mfd tree. The patches and the relevant acks are: Patch 03/13 (regulator - Mark Brown) Patches 04/13 to 09/13 (clk - Mike Turquette) Patches 10/13 to 12/13 (rtc - Alessandro Zummo) Mark, Mike and Alessandro, This is a gentle reminder to look at the patches that touches your subsystems and provide acks if possible so Lee can merge the remainder set through the mfd tree. There were only trivial changes for the regulator, clock and rtc drivers since v5 (posted almost a month ago in Jun 26) and this series is blocking a lot of other patch-sets so is hurting forward progress on the chromebook2 platform as a whole. Lee, Since I may not be able to get the acks before the merge window opens, do you think that is possible to merge patch 01/13 mfd: max77686: Add Maxim 77802 PMIC support which already has your ack? So at least we can get the dependency for the other drivers in 3.17 and avoid this cross subsystem churn for 3.18 since the rest of the drivers will be able to go through the relevant trees. Thanks a lot and 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 1/2] clk: samsung: exynos4: Enable ARMCLK down feature
On Fri, Jul 18, 2014 at 3:36 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Enable ARMCLK down feature on all Exynos4 SoCs. The frequency of ARMCLK will be reduced upon entering idle mode (WFI or WFE). The feature behaves like very fast cpufreq ondemand governor. In idle mode this reduces energy consumption on full frequency chosen by cpufreq governor by approximately: - Trats2: 6.5% (153 mA - 143 mA) - Trats: 33.0% (180 mA - 120 mA) - Gear1: 27.0% (180 mA - 130 mA) The patch uses simillar settings as Exynos5250 (clk-exynos5250.c), except it disables clock up feature and on Exynos4412 ARMCLK down is enabled for all 4 cores. Tested on Trats board (Exynos4210), Trats2 board (Exynos4412) and Samsung Gear 1 (Exynos4212). Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Tested on ODROID-U2, seems to be working. I don't have a way of measuring the power usage, but the system seems as stable as before. Tested-by: Daniel Drake dr...@endlessm.com -- 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: [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
On Mon, Jul 21, 2014 at 04:58:25PM +0530, Ajay kumar wrote:
On Mon, Jul 21, 2014 at 12:40 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Fri, Jul 18, 2014 at 02:13:58AM +0530, Ajay Kumar wrote:
From: Rahul Sharma rahul.sha...@samsung.com
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 0ca6256..82e2942 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -31,6 +31,7 @@
#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
#include drm/bridge/panel_binder.h
+#include drm/bridge/ps8622.h
#include exynos_drm_drv.h
#include exynos_dp_core.h
@@ -999,6 +1000,10 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
if (find_bridge(nxp,ptn3460, bridge)) {
bridge_chain = ptn3460_init(dp-drm_dev, encoder,
bridge.client,
bridge.node);
+ } else if (find_bridge(parade,ps8622, bridge) ||
+ find_bridge(parade,ps8625, bridge)) {
+ bridge_chain = ps8622_init(dp-drm_dev, encoder,
bridge.client,
+ bridge.node);
}
We really ought to be adding some sort of registry at some point.
Otherwise every driver that wants to use bridges needs to come up with a
similar set of helpers to instantiate them.
Also you're making this driver depend on (now) two bridges, whereas it
really shouldn't matter which exact types it supports. Bridges should be
exposed via a generic interface.
How about moving out the find_bridge() function into a common header file,
and also supporting the list of bridge_init declarations in the same file?
We get bridge chip node from phandle, and then pass the same node
to find_bridge() which searches the list using of_device_is_compatible()
to call the appropriate bridge_init function?
That could work, but it's still somewhat unusual and shouldn't be
required. I think we'd be better of with some sort of registry like we
have for panels. That would mean that a driver that wants to use a
bridge would do something like this:
struct drm_bridge *bridge;
struct device_node *np;
np = of_parse_phandle(dev-of_node, bridge, 0);
if (np) {
bridge = of_drm_find_bridge(np);
of_node_put(np);
if (!bridge)
return -EPROBE_DEFER;
}
An alternative way would be to add a non-OF wrapper around this, like
this for example:
bridge = drm_bridge_get(dev, NULL);
Which would be conceptually the same as clk_get() or regulator_get() and
could be easily extended to support non-DT setups as well.
As for bridge drivers I think we may have to rework things a little, so
that a driver can call some sequence like this:
struct foo_bridge {
struct drm_bridge base;
...
};
static const struct drm_bridge_funcs foo_bridge_funcs = {
...
};
static int foo_probe(...)
{
struct foo_bridge *bridge;
int err;
bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
if (!bridge)
return -ENOMEM;
/* setup bridge (return -EPROBE_DEFER if necessary, ...) */
/* register bridge with DRM */
drm_bridge_init(bridge-base);
bridge-base.dev = dev;
bridge-base.funcs = foo_bridge_funcs;
err = drm_bridge_add(bridge-base);
if (err 0)
return err;
dev_set_drvdata(dev, bridge);
...
}
drm_bridge_add() would add the bridge to a global list of bridge devices
which drm_bridge_get()/of_drm_find_bridge() can use to find the one that
it needs. The above has the big advantage that it's completely
independent of the underlying bus that the bridge is on. It could be I2C
or SPI, platform device or PCI device.
Thierry
pgpkq1_Z9U6wW.pgp
Description: PGP signature
Re: [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
Hi, On Monday, July 21, 2014 01:43:53 PM Daniel Drake wrote: On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Recent patch by Tomasz Figa (irqchip: gic: Fix core ID calculation when topology is read from DT) fixed GIC driver to filter cluster ID from values returned by cpu_logical_map() for SoCs having registers mapped without per-CPU banking making it is possible to add CPU nodes for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also required by future changes adding initialization of cpuidle states in Exynos cpuidle driver through DT. This conflicts with work in the thread cpufreq: use generic cpufreq drivers for exynos platforms which is already in its 7th iteration. Perhaps best to work directly with Thomas to help him finish that series? Patch [PATCH v7 4/6] ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data from Thomas needs another revision anyway since it lacks cluster ID in Exynos4210 CPU node. It also mixes addition of CPU nodes with cpufreq specific changes and IMHO addition of CPU nodes should be in separate patch to ease bisection if any later problems turn up. Therefore I think that it would be the best if Thomas would rebase his work on top of irqchip: gic: Fix core ID calculation when topology is read from DT patch and this one. Thomas, are you okay with this? Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- 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] ARM: dts: add CPU nodes for Exynos4 SoCs
On Mon, Jul 21, 2014 at 6:40 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Hi, On Monday, July 21, 2014 01:43:53 PM Daniel Drake wrote: On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Recent patch by Tomasz Figa (irqchip: gic: Fix core ID calculation when topology is read from DT) fixed GIC driver to filter cluster ID from values returned by cpu_logical_map() for SoCs having registers mapped without per-CPU banking making it is possible to add CPU nodes for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also required by future changes adding initialization of cpuidle states in Exynos cpuidle driver through DT. This conflicts with work in the thread cpufreq: use generic cpufreq drivers for exynos platforms which is already in its 7th iteration. Perhaps best to work directly with Thomas to help him finish that series? Patch [PATCH v7 4/6] ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data from Thomas needs another revision anyway since it lacks cluster ID in Exynos4210 CPU node. It also mixes addition of CPU nodes with cpufreq specific changes and IMHO addition of CPU nodes should be in separate patch to ease bisection if any later problems turn up. Therefore I think that it would be the best if Thomas would rebase his work on top of irqchip: gic: Fix core ID calculation when topology is read from DT patch and this one. Thomas, are you okay with this? Hi Bartlomiej, Yes, I am okay with this. Regards, Thomas. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- 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 -- 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] ARM: EXYNOS: Fix build with PM_SLEEP=n
On Monday, July 21, 2014 02:55:52 PM Bartlomiej Zolnierkiewicz wrote: On Monday, July 21, 2014 01:11:14 PM Bartlomiej Zolnierkiewicz wrote: On Monday, July 21, 2014 12:38:28 PM Bartlomiej Zolnierkiewicz wrote: Hi, On Saturday, July 19, 2014 04:42:34 AM Kukjin Kim wrote: On 07/16/14 20:59, Tomasz Figa wrote: Hi Krzysztof, On 14.07.2014 09:45, Krzysztof Kozlowski wrote: Fix building of exynos defconfig with disabled PM_SLEEP: CONFIG_PM_SLEEP=n CONFIG_PM_SLEEP_SMP=n CONFIG_SUSPEND=n by moving functions for power up/down of CPU and cluster to platsmp.c The build error messages: arch/arm/mach-exynos/built-in.o: In function `exynos_boot_secondary': arch/arm/mach-exynos/platsmp.c:111: undefined reference to `exynos_cpu_power_state' arch/arm/mach-exynos/platsmp.c:112: undefined reference to `exynos_cpu_power_up' arch/arm/mach-exynos/platsmp.c:116: undefined reference to `exynos_cpu_power_state' make: *** [vmlinux] Error 1 Signed-off-by: Krzysztof Kozlowskik.kozlow...@samsung.com --- Changes since v1: 1. Use different solution - just move the power up/down functions to a common place instead of adding stubs in common.h. Suggested by Tomasz Figa. --- arch/arm/mach-exynos/platsmp.c | 66 ++ arch/arm/mach-exynos/pm.c | 66 -- 2 files changed, 66 insertions(+), 66 deletions(-) + Bart, Reviewed-by: Tomasz Figat.f...@samsung.com Applied, thanks. Bart, I think this is better at this moment to fix the build breakage with disabling PM...if you have any comments, please let me know. To fix PM_SLEEP=n build itself (with ARM_EXYNOS_CPUIDLE=n) Krzysztof's patch is not enough and patch [1] is also needed (this patch is very simple so I think that it is okay for v3.16). Hmmm, I now see that you've applied Krzysztof's patch for v3.17 not v3.16. In that case how do you want to deal with PM_SLEEP=n build breakages for v3.16 and what do you mean with fix the build breakage with disabling PM? Just a bit of explanation: The PM_SLEEP=n build breakages show up on automated build tests done by various people. Minimal fixes for them (Krzysztof's patch + patch [1] + making ARM_EXYNOS_CPUIDLE depend on PM_SLEEP temporally) are really obvious and should be pretty safe so it would be great to have them in v3.16. If that is not possible lets fix the issue completely early in v3.17 cycle. Okay, so Krzysztof's patch was posted in pull request to Olof on Saturday and merged already for v3.17. In that case I will just refresh my patches and resubmit later. Sorry for all the noise. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics For PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y config more changes are needed and they are contained in patch [2] (please note that this patch depends on patch [3] from Tomasz Figa which was redone recently into [4] so my patch also needs to be refreshed). However if you think that this would result in too much changes for v3.16 kernel we can make ARM_EXYNOS_CPUIDLE select (or depend on) PM_SLEEP for now and fix the issue completely later in v3.17 kernel. [1] [PATCH 1/2] ARM: EXYNOS: Fix build with PM_SLEEP=n part #2 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34080.html [2] [PATCH 2/2] ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34081.html [3] [PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32809.html [4] [PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34150.html Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- 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 v2] ARM: dts: add CPU nodes for Exynos4 SoCs
Recent patch by Tomasz Figa (irqchip: gic: Fix core ID calculation
when topology is read from DT) fixed GIC driver to filter cluster ID
from values returned by cpu_logical_map() for SoCs having registers
mapped without per-CPU banking making it is possible to add CPU nodes
for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also
required by future changes adding initialization of cpuidle states in
Exynos cpuidle driver through DT.
Tested on Origen board (Exynos4210 SoC) and Trats2 (Exynos4412 SoC).
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
Based on next-20140717 branch of linux-next tree +
- [PATCH 2/6] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32811.html
- [PATCH] irqchip: gic: Fix core ID calculation when topology is read from DT
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34277.html
v2:
- match the unit-address with the reg
arch/arm/boot/dts/exynos4210.dtsi | 17 +
arch/arm/boot/dts/exynos4212.dtsi | 17 +
arch/arm/boot/dts/exynos4412.dtsi | 29 +
3 files changed, 63 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f..bc2b444 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,23 @@
pinctrl2 = pinctrl_2;
};
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@900 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0x900;
+ };
+
+ cpu@901 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0x901;
+ };
+ };
+
sysram@0202 {
compatible = mmio-sram;
reg = 0x0202 0x2;
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 3c00e6e..dd0a43e 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -22,6 +22,23 @@
/ {
compatible = samsung,exynos4212, samsung,exynos4;
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@A00 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0xA00;
+ };
+
+ cpu@A01 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0xA01;
+ };
+ };
+
combiner: interrupt-controller@1044 {
samsung,combiner-nr = 18;
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index c42a3e1..435a722 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -22,6 +22,35 @@
/ {
compatible = samsung,exynos4412, samsung,exynos4;
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@A00 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0xA00;
+ };
+
+ cpu@A01 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0xA01;
+ };
+
+ cpu@A02 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0xA02;
+ };
+
+ cpu@A03 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0xA03;
+ };
+ };
+
combiner: interrupt-controller@1044 {
samsung,combiner-nr = 20;
};
--
1.8.2.3
--
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 v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
On 07/17/2014 11:01 AM, YoungJun Cho wrote:
To support LCD I80 interface, the DSI host should register
TE interrupt handler from the TE GPIO of attached panel.
So the panel generates a tearing effect synchronization signal
then the DSI host calls the CRTC device manager to trigger
to transfer video image.
This whole patch seems to be a hack.
I think it is not a good idea to parse property of one device by another
device's driver.
Especially here TE GPIO belongs to the panel. The panel driver should
know how to configure it and how to use it or not. The panel driver will
generate TE signal based on this GPIO, DSI/BTA mechanism or any other
mechanism provided by the panel.
TE signal should be delivered to the display controller. The only role
of DSIM here is that it is between the panel and the display controller
so it should be used to route this signal to DC.
According to specs TE signal should/can be generated by DBI and DSI
command mode panels, so its handling should be more generic, not Exynos
specific.
Regards
Andrzej
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 95
-
1 file changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 58bfb2a..4997bfe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -16,7 +16,9 @@
#include drm/drm_panel.h
#include linux/clk.h
+#include linux/gpio/consumer.h
#include linux/irq.h
+#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
#include linux/component.h
@@ -24,6 +26,7 @@
#include video/mipi_display.h
#include video/videomode.h
+#include exynos_drm_crtc.h
#include exynos_drm_drv.h
/* returns true iff both arguments logically differs */
@@ -247,6 +250,7 @@ struct exynos_dsi {
struct clk *bus_clk;
struct regulator_bulk_data supplies[2];
int irq;
+ int te_gpio;
u32 pll_clk_rate;
u32 burst_clk_rate;
@@ -954,17 +958,89 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
+{
+ struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
+ struct drm_encoder *encoder = dsi-encoder;
+
+ if (dsi-state DSIM_STATE_ENABLED)
+ exynos_drm_crtc_te_handler(encoder-crtc);
+
+ return IRQ_HANDLED;
+}
+
+static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+{
+ enable_irq(dsi-irq);
+
+ if (gpio_is_valid(dsi-te_gpio))
+ enable_irq(gpio_to_irq(dsi-te_gpio));
+}
+
+static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+{
+ if (gpio_is_valid(dsi-te_gpio))
+ disable_irq(gpio_to_irq(dsi-te_gpio));
+
+ disable_irq(dsi-irq);
+}
+
static int exynos_dsi_init(struct exynos_dsi *dsi)
{
exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
- enable_irq(dsi-irq);
+ exynos_dsi_enable_irq(dsi);
exynos_dsi_wait_for_reset(dsi);
exynos_dsi_init_link(dsi);
return 0;
}
+static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
+{
+ int ret;
+
+ dsi-te_gpio = of_get_named_gpio(dsi-panel_node, te-gpios, 0);
+ if (!gpio_is_valid(dsi-te_gpio)) {
+ dev_err(dsi-dev, no te-gpios specified\n);
+ ret = dsi-te_gpio;
+ goto out;
+ }
+
+ ret = gpio_request_one(dsi-te_gpio, GPIOF_IN, te_gpio);
+ if (ret) {
+ dev_err(dsi-dev, gpio request failed with %d\n, ret);
+ goto out;
+ }
+
+ /*
+ * This TE GPIO IRQ should not be set to IRQ_NOAUTOEN, because panel
+ * calls drm_panel_init() first then calls mipi_dsi_attach() in probe().
+ * It means that te_gpio is invalid when exynos_dsi_enable_irq() is
+ * called by drm_panel_init() before panel is attached.
+ */
+ ret = request_threaded_irq(gpio_to_irq(dsi-te_gpio),
+ exynos_dsi_te_irq_handler, NULL,
+ IRQF_TRIGGER_RISING, TE, dsi);
+ if (ret) {
+ dev_err(dsi-dev, request interrupt failed with %d\n, ret);
+ gpio_free(dsi-te_gpio);
+ goto out;
+ }
+
+out:
+ return ret;
+}
+
+static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
+{
+ if (gpio_is_valid(dsi-te_gpio)) {
+ free_irq(gpio_to_irq(dsi-te_gpio), dsi);
+ gpio_free(dsi-te_gpio);
+ dsi-te_gpio = -ENOENT;
+ }
+}
+
static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
@@ -978,6 +1054,16 @@ static int
Re: [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
Hi Thierry,
On Mon, Jul 21, 2014 at 6:24 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Jul 21, 2014 at 04:58:25PM +0530, Ajay kumar wrote:
On Mon, Jul 21, 2014 at 12:40 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Fri, Jul 18, 2014 at 02:13:58AM +0530, Ajay Kumar wrote:
From: Rahul Sharma rahul.sha...@samsung.com
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 0ca6256..82e2942 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -31,6 +31,7 @@
#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
#include drm/bridge/panel_binder.h
+#include drm/bridge/ps8622.h
#include exynos_drm_drv.h
#include exynos_dp_core.h
@@ -999,6 +1000,10 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
if (find_bridge(nxp,ptn3460, bridge)) {
bridge_chain = ptn3460_init(dp-drm_dev, encoder,
bridge.client,
bridge.node);
+ } else if (find_bridge(parade,ps8622, bridge) ||
+ find_bridge(parade,ps8625, bridge)) {
+ bridge_chain = ps8622_init(dp-drm_dev, encoder,
bridge.client,
+
bridge.node);
}
We really ought to be adding some sort of registry at some point.
Otherwise every driver that wants to use bridges needs to come up with a
similar set of helpers to instantiate them.
Also you're making this driver depend on (now) two bridges, whereas it
really shouldn't matter which exact types it supports. Bridges should be
exposed via a generic interface.
How about moving out the find_bridge() function into a common header file,
and also supporting the list of bridge_init declarations in the same file?
We get bridge chip node from phandle, and then pass the same node
to find_bridge() which searches the list using of_device_is_compatible()
to call the appropriate bridge_init function?
That could work, but it's still somewhat unusual and shouldn't be
required. I think we'd be better of with some sort of registry like we
have for panels. That would mean that a driver that wants to use a
bridge would do something like this:
struct drm_bridge *bridge;
struct device_node *np;
np = of_parse_phandle(dev-of_node, bridge, 0);
if (np) {
bridge = of_drm_find_bridge(np);
of_node_put(np);
if (!bridge)
return -EPROBE_DEFER;
}
An alternative way would be to add a non-OF wrapper around this, like
this for example:
Let me try the DT version first :)
bridge = drm_bridge_get(dev, NULL);
Which would be conceptually the same as clk_get() or regulator_get() and
could be easily extended to support non-DT setups as well.
As for bridge drivers I think we may have to rework things a little, so
that a driver can call some sequence like this:
struct foo_bridge {
struct drm_bridge base;
...
};
static const struct drm_bridge_funcs foo_bridge_funcs = {
...
};
static int foo_probe(...)
{
struct foo_bridge *bridge;
int err;
bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
if (!bridge)
return -ENOMEM;
/* setup bridge (return -EPROBE_DEFER if necessary, ...) */
/* register bridge with DRM */
drm_bridge_init(bridge-base);
bridge-base.dev = dev;
bridge-base.funcs = foo_bridge_funcs;
err = drm_bridge_add(bridge-base);
if (err 0)
return err;
dev_set_drvdata(dev, bridge);
...
}
drm_bridge_add() would add the bridge to a global list of bridge devices
which drm_bridge_get()/of_drm_find_bridge() can use to find the one that
it needs. The above has the big advantage that
it'sdev-mode_config.bridge_list completely
independent of the underlying bus that the bridge is on. It could be I2C
or SPI, platform device or PCI device.
Thierry
Ok. This is all about making the bridge driver confine to the driver model.
But, I would need a drm_device pointer to register the bridge to DRM core.
How do I get it?
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH 2/2] iio: exynos-adc: add experimental touchscreen support
On Mon, Jul 21, 2014 at 12:23:58PM +0200, Arnd Bergmann wrote:
On Sunday 20 July 2014 13:28:42 Dmitry Torokhov wrote:
On Sun, Jul 20, 2014 at 02:51:37PM +0100, Jonathan Cameron wrote:
+
+do {
+ret =exynos_read_s3c64xx_ts(dev, NULL, x, y,
IIO_CHAN_INFO_RAW);
= exynos
+if (ret == -ETIMEDOUT)
+break;
+
+pressed = x y ADC_DATX_PRESSED;
+if (!pressed)
+break;
+
+input_report_abs(info-input, ABS_X, x ADC_DATX_MASK);
+input_report_abs(info-input, ABS_Y, y ADC_DATX_MASK);
+input_report_key(info-input, BTN_TOUCH, 1);
+input_sync(info-input);
+
+msleep(1);
+} while (1);
It would be nice to actually close the device even if someone is
touching screen. Please implement open/close methods and have them set a
flag that you would check here.
Ok. I think it's even better to move the request_irq() into the open function,
which will avoid the flag and defer the error handling into the actual
opening,
as well as syncing the running irq with the close function.
I do not quite like acquiring resources needed in open. I think drivers should
do all resource acquisition in probe() and leave open()/close() to
activate/quiesce devices.
+/* data from s3c2410_ts driver */
+info-input-name = S3C24xx TouchScreen;
+info-input-id.bustype = BUS_HOST;
+info-input-id.vendor = 0xDEAD;
+info-input-id.product = 0xBEEF;
You do not need to fill these entries with fake data.
Ok, I wondered about this, but didn't want to change too much from
the old driver (I changed the version number).
+info-input-id.version = 0x0200;
Do I need this?
Not really.
Thanks.
--
Dmitry
--
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] exynos: Support big endian mode in secondary_startup
From: Victor Kamensky victor.kamen...@linaro.org Exynos processors generally operate in little endian mode so their bootloader and ROM will almost always operate in little endian mode. This means that if a big endian kernel is run it must switch the CPU into big endian mode after gaining control. The generic secondary_startup that is called from exynos specific secondary startup code will do the switch, but we need it to do earlier because exynos specific secondary_startup code which runs first also works with data that is big endian when the kernel is compiled for big endian. [Rewrote commit message. -- broonie] Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Mark Brown broo...@linaro.org --- arch/arm/mach-exynos/headsmp.S | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-exynos/headsmp.S b/arch/arm/mach-exynos/headsmp.S index b54f9701e421..ac8364efb985 100644 --- a/arch/arm/mach-exynos/headsmp.S +++ b/arch/arm/mach-exynos/headsmp.S @@ -18,6 +18,11 @@ * ready for them to initialise. */ ENTRY(exynos4_secondary_startup) + /* +* ROM code operates in little endian mode, when we get control we +* need to switch it to big endian mode. +*/ +ARM_BE8(setend be) mrc p15, 0, r0, c0, c0, 5 and r0, r0, #15 adr r4, 1f -- 2.0.1 -- 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] exynos: boot serial endian fix
From: Victor Kamensky victor.kamen...@linaro.org In order to support booting a big endian kernel the uncompress serial line write utils need to use endian neutral functions to read h/w register. Fix uart_rd, uart_wr and serial chip fifo related macros to do this. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Mark Brown broo...@linaro.org --- arch/arm/include/debug/samsung.S | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/include/debug/samsung.S b/arch/arm/include/debug/samsung.S index 8d8d922e5e44..dc62d4ae04d0 100644 --- a/arch/arm/include/debug/samsung.S +++ b/arch/arm/include/debug/samsung.S @@ -9,17 +9,20 @@ * published by the Free Software Foundation. */ +#include asm/assembler.h #include linux/serial_s3c.h /* The S5PV210/S5PC110 implementations are as belows. */ .macro fifo_level_s5pv210 rd, rx ldr \rd, [\rx, # S3C2410_UFSTAT] + ARM_BE8(rev \rd, \rd) and \rd, \rd, #S5PV210_UFSTAT_TXMASK .endm .macro fifo_full_s5pv210 rd, rx ldr \rd, [\rx, # S3C2410_UFSTAT] + ARM_BE8(rev \rd, \rd) tst \rd, #S5PV210_UFSTAT_TXFULL .endm @@ -28,6 +31,7 @@ .macro fifo_level_s3c2440 rd, rx ldr \rd, [\rx, # S3C2410_UFSTAT] + ARM_BE8(rev \rd, \rd) and \rd, \rd, #S3C2440_UFSTAT_TXMASK .endm @@ -37,6 +41,7 @@ .macro fifo_full_s3c2440 rd, rx ldr \rd, [\rx, # S3C2410_UFSTAT] + ARM_BE8(rev \rd, \rd) tst \rd, #S3C2440_UFSTAT_TXFULL .endm @@ -50,6 +55,7 @@ .macro busyuart, rd, rx ldr \rd, [\rx, # S3C2410_UFCON] + ARM_BE8(rev \rd, \rd) tst \rd, #S3C2410_UFCON_FIFOMODE@ fifo enabled? beq 1001f @ @ FIFO enabled... @@ -61,6 +67,7 @@ 1001: @ busy waiting for non fifo ldr \rd, [\rx, # S3C2410_UTRSTAT] + ARM_BE8(rev \rd, \rd) tst \rd, #S3C2410_UTRSTAT_TXFE beq 1001b @@ -69,6 +76,7 @@ .macro waituart,rd,rx ldr \rd, [\rx, # S3C2410_UFCON] + ARM_BE8(rev \rd, \rd) tst \rd, #S3C2410_UFCON_FIFOMODE@ fifo enabled? beq 1001f @ @ FIFO enabled... @@ -80,6 +88,7 @@ 1001: @ idle waiting for non fifo ldr \rd, [\rx, # S3C2410_UTRSTAT] + ARM_BE8(rev \rd, \rd) tst \rd, #S3C2410_UTRSTAT_TXFE beq 1001b -- 2.0.1 -- 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 2/2] iio: exynos-adc: add experimental touchscreen support
On Mon, Jul 21, 2014 at 05:11:27PM +0200, Arnd Bergmann wrote:
On Monday 21 July 2014 07:44:42 Dmitry Torokhov wrote:
It would be nice to actually close the device even if someone is
touching screen. Please implement open/close methods and have them set a
flag that you would check here.
Ok. I think it's even better to move the request_irq() into the open
function,
which will avoid the flag and defer the error handling into the actual
opening,
as well as syncing the running irq with the close function.
I do not quite like acquiring resources needed in open. I think drivers
should
do all resource acquisition in probe() and leave open()/close() to
activate/quiesce devices.
Ok, I'll move it back then. I'm not sure what I'm supposed to do
in open/close then. Isn't it enough to check info-input-users
like this?
static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
{
struct exynos_adc *info = dev_id;
struct iio_dev *dev = dev_get_drvdata(info-dev);
u32 x, y;
bool pressed;
int ret;
while (info-input-users) {
ret = exynos_read_s3c64xx_ts(dev, x, y);
if (ret == -ETIMEDOUT)
break;
pressed = x y ADC_DATX_PRESSED;
if (!pressed) {
input_report_key(info-input, BTN_TOUCH, 0);
input_sync(info-input);
break;
}
input_report_abs(info-input, ABS_X, x ADC_DATX_MASK);
input_report_abs(info-input, ABS_Y, y ADC_DATY_MASK);
input_report_key(info-input, BTN_TOUCH, 1);
input_sync(info-input);
msleep(1);
};
writel(0, ADC_V1_CLRINTPNDNUP(info-regs));
return IRQ_HANDLED;
}
I could do enable_irq()/disable_irq(), but that leaves a small
race at startup where we request the irq line and then immediately
disable it again.
I think the above (or a separate flag in driver structure) coupled with
enable/disable IRQ is fine - input core can deal with calls to input_report_*
on devices that have been properly allocated but have not been registered yet.
drivers/input/keyboard/samsung-keypad.c does similar handling.
Thanks.
--
Dmitry
--
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 1/2] PM / devfreq: Export helper functions for drivers
함명주 myungjoo@samsung.com writes: Sender : Punit Agrawalpunit.agra...@arm.com From: Ørjan Eide These functions are indended for use by drivers and should be available also when the driver is built as a module. Cc: MyungJoo Ham Cc: Kyungmin Park Signed-off-by: Ørjan Eide Dear Punit, Hi MyungJoo, Just being curious, is there any reason not to use EXPORT_SYMBOL_GPL ? No reason other than to match the existing EXPORT_SYMBOLs in this file. Would you prefer this and the following patch to use EXPORT_SYMBOL_GPL instead? Cheers, MyungJoo. -- MyungJoo Ham (함명주), PHD Frontier CS Lab, Software Center Samsung Electronics Cell: +82-10-6714-2858-- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v8 00/13] Add Maxim 77802 PMIC support
On Mon, Jul 21, 2014 at 02:44:07PM +0200, Javier Martinez Canillas wrote: On 07/14/2014 01:35 PM, Javier Martinez Canillas wrote: Mark, Mike and Alessandro, This is a gentle reminder to look at the patches that touches your subsystems and provide acks if possible so Lee can merge the remainder set through the mfd tree. Please stop nagging, you are chasing after only one week which is excessive for something that isn't an urgent bugfix (especially with a series like this that has had many rapid repins). Several weeks to a month would be more appropriate, and then resending the patches rather than sending contentless pings is more useful. Sending mails like this just means that people have more mail to read that isn't your patch, it is more likely to get you negative attention than positive - for example, I will tend to deprioritise things where I'm being chased too urgently as I do not wish to encourage such behaviour by being seen to reward it. In general I would recommend taking a step back, slowing down, and if you are not getting a response either thinking of something else to do in parallel or trying to do things that make it easier to accept your change if there are any (sometimes it's just a case of waiting). Look at how frequently the relevant maintainers tend to respond, at what the previous review comments have been and also consider the possibility that people might take holidays or just be busy. signature.asc Description: Digital signature
Re: [PATCH v8 00/13] Add Maxim 77802 PMIC support
On 07/22/2014 02:10 AM, Mark Brown wrote: On Mon, Jul 21, 2014 at 02:44:07PM +0200, Javier Martinez Canillas wrote: On 07/14/2014 01:35 PM, Javier Martinez Canillas wrote: Mark, Mike and Alessandro, This is a gentle reminder to look at the patches that touches your subsystems and provide acks if possible so Lee can merge the remainder set through the mfd tree. Please stop nagging, you are chasing after only one week which is excessive for something that isn't an urgent bugfix (especially with a series like this that has had many rapid repins). Several weeks to a month would be more appropriate, and then resending the patches rather than sending contentless pings is more useful. Sending mails like this just means that people have more mail to read that isn't your patch, it is more likely to get you negative attention than positive - for example, I will tend to deprioritise things where I'm being chased too urgently as I do not wish to encourage such behaviour by being seen to reward it. I didn't mean to bother you. It's true that it has been only a week since I posted v8 of this series but I didn't have feedback for the clock, rtc and regulator drivers since v5 which was posted on June, 26 so I thought that a ping just to be sure it was not forgotten was not that bad. But sorry I won't do it again and will just wait. About the many re-spins, as most mfd drivers this PMIC support touches different subsystems and the series had many patches so each time I had feedback for some patches I prepared a new version and reposted the whole series. This doesn't mean that all the patches changed from version to version though, some patches have not changed for several revisions. In general I would recommend taking a step back, slowing down, and if you are not getting a response either thinking of something else to do in parallel or trying to do things that make it easier to accept your change if there are any (sometimes it's just a case of waiting). Look at how frequently the relevant maintainers tend to respond, at what the previous review comments have been and also consider the possibility that people might take holidays or just be busy. Sorry, I didn't mean to imply that you are not busy or might be on holidays. I guess I just got anxious due the merge window being close... 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 00/12] drm/exynos/ipp: image post processing improvements, part three
On 2014년 07월 21일 18:23, Andrzej Hajda wrote: Hi Inki, On 07/09/2014 04:47 PM, Inki Dae wrote: On 2014년 07월 03일 22:10, Andrzej Hajda wrote: This set of independent patches contains various improvement and fixes for exynos_drm ipp framework. The patchset is based on exynos-drm-next branch. Did you test ipp module using libdrm? If so, can you share the app? I would try to test this patch series before merging them. Mainline libdrm has no any ipp interfaces. I have used ipptest program developed by you :), with minor changes. More advanced tests are on my TODO list, but for this patchset ipptest seems to be OK - the patches are mainly cleanup patches. Did the ipptest work fine? I just tried to build the app so didn't test the app. :) Got it, will merge this patch series. Thanks, Inki Dae Regards Andrzej Thanks, Inki Dae Regards Andrzej Andrzej Hajda (12): drm/exynos/ipp: remove type casting drm/exynos/ipp: remove unused field from exynos_drm_ipp_private drm/exynos/ipp: remove struct exynos_drm_ipp_private drm/exynos/ipp: correct address type drm/exynos/ipp: remove temporary variable drm/exynos/ipp: remove incorrect checks of list_first_entry result drm/exynos/ipp: simplify memory check function drm/exynos/ipp: remove useless registration checks drm/exynos/ipp: simplify ipp_find_obj drm/exynos/ipp: remove redundant messages drm/exynos/ipp: simplify ipp_create_id drm/exynos/ipp: simplify ipp_find_driver drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 259 +--- drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +- 3 files changed, 73 insertions(+), 197 deletions(-) -- 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 -- 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 v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
On 2014년 07월 21일 23:01, Andrzej Hajda wrote:
On 07/17/2014 11:01 AM, YoungJun Cho wrote:
To support LCD I80 interface, the DSI host should register
TE interrupt handler from the TE GPIO of attached panel.
So the panel generates a tearing effect synchronization signal
then the DSI host calls the CRTC device manager to trigger
to transfer video image.
This whole patch seems to be a hack.
I think it is not a good idea to parse property of one device by another
device's driver.
Especially here TE GPIO belongs to the panel. The panel driver should
know how to configure it and how to use it or not. The panel driver will
generate TE signal based on this GPIO, DSI/BTA mechanism or any other
mechanism provided by the panel.
TE signal should be delivered to the display controller. The only role
of DSIM here is that it is between the panel and the display controller
so it should be used to route this signal to DC.
According to specs TE signal should/can be generated by DBI and DSI
command mode panels, so its handling should be more generic, not Exynos
specific.
Right. However, it seems that there are no much users using command mode
panel so we would need more times to discuss the generic way. I think we
can have this feature in specific to Exynos drm - it doesn't affect
other SoC -. Actually, I know OMAP people handle this feature in a way
specific to OMAP SoC. If other users need more generic way to this
feature then we could have a discussion about the generic way at that time.
That is why Mr. Cho implemented TE feature like this. Do you have more
good idea? I wish the idea would be specific so that Mr. Cho can
implement it.
P.s. Thierry already opposed the use of mipi_dsi_host_ops, I agree with
him. And also it seems not good to use crtc and encoder/connector
because these frameworks are common to all architecture including x86 so
other architectures wouldn't need TE feature.
Thanks,
Inki Dae
Regards
Andrzej
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 95
-
1 file changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 58bfb2a..4997bfe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -16,7 +16,9 @@
#include drm/drm_panel.h
#include linux/clk.h
+#include linux/gpio/consumer.h
#include linux/irq.h
+#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
#include linux/component.h
@@ -24,6 +26,7 @@
#include video/mipi_display.h
#include video/videomode.h
+#include exynos_drm_crtc.h
#include exynos_drm_drv.h
/* returns true iff both arguments logically differs */
@@ -247,6 +250,7 @@ struct exynos_dsi {
struct clk *bus_clk;
struct regulator_bulk_data supplies[2];
int irq;
+int te_gpio;
u32 pll_clk_rate;
u32 burst_clk_rate;
@@ -954,17 +958,89 @@ static irqreturn_t exynos_dsi_irq(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
+{
+struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
+struct drm_encoder *encoder = dsi-encoder;
+
+if (dsi-state DSIM_STATE_ENABLED)
+exynos_drm_crtc_te_handler(encoder-crtc);
+
+return IRQ_HANDLED;
+}
+
+static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+{
+enable_irq(dsi-irq);
+
+if (gpio_is_valid(dsi-te_gpio))
+enable_irq(gpio_to_irq(dsi-te_gpio));
+}
+
+static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+{
+if (gpio_is_valid(dsi-te_gpio))
+disable_irq(gpio_to_irq(dsi-te_gpio));
+
+disable_irq(dsi-irq);
+}
+
static int exynos_dsi_init(struct exynos_dsi *dsi)
{
exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
-enable_irq(dsi-irq);
+exynos_dsi_enable_irq(dsi);
exynos_dsi_wait_for_reset(dsi);
exynos_dsi_init_link(dsi);
return 0;
}
+static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
+{
+int ret;
+
+dsi-te_gpio = of_get_named_gpio(dsi-panel_node, te-gpios, 0);
+if (!gpio_is_valid(dsi-te_gpio)) {
+dev_err(dsi-dev, no te-gpios specified\n);
+ret = dsi-te_gpio;
+goto out;
+}
+
+ret = gpio_request_one(dsi-te_gpio, GPIOF_IN, te_gpio);
+if (ret) {
+dev_err(dsi-dev, gpio request failed with %d\n, ret);
+goto out;
+}
+
+/*
+ * This TE GPIO IRQ should not be set to IRQ_NOAUTOEN, because panel
+ * calls drm_panel_init() first then calls mipi_dsi_attach() in probe().
+ * It means that te_gpio is invalid when exynos_dsi_enable_irq() is
+ * called by
[PATCHv8 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
This patchset support Exynos3250 ADC (Analog Digital Converter) because Exynos3250 has additional special clock for ADC IP. Changes from v7: - Add acked message by Arnd Bergmann - Use two compatible string for Exynos3250 ADC as following: : compatible = samsung,exynos3250-adc, samsung,exynos-adc-v2; Changes from v6: - Use exynos3250-adc compatible string instead of exynos3250-adc-v2 - Use sclk clock name instead of sclk_adc - Remove un-necessary macro for exyno-adc-data-v2 structure. - Remove '(void *)' cast and mark the exynos-adc-data structure as 'const' - Change the number of ADC channels (Exynos3250 has only two channels for ADC) Changes from v5: - Add acked message by Kukjin Kim - Add reviewed messgae by Tomasz Figa - Fix typo (for for - for) Changes from v4: - Use 'exynos_adc_data' structure instead of 'exynos_adc_ops' structure and remove enum variable of ADC version - Fix wrong name of special clock (sclk_tsadc - sclk_adc) - Add reviewed message by Naveen Krishna Chatradhi - Add functions for ADC clock control Changes from v3: - Add new 'exynos_adc_ops' structure to improve readability according to Tomasz Figa comment[1] [1] https://lkml.org/lkml/2014/4/16/238 - Add new 'exynos3250-adc-v2' compatible string to support Exynos3250 ADC - Fix wrong compaitlbe string of ADC in Exynos3250 dtsi file Changes from v2: - Check return value of clock function to deal with error exception - Fix minor coding style to improve readability Changes from v1: - Add new samsung,exynos-adc-v3 compatible to support Exynos3250 ADC - Add a patch about DT binding documentation Chanwoo Choi (4): iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC iio: devicetree: Add DT binding documentation for Exynos3250 ADC ARM: dts: Fix wrong compatible string for Exynos3250 ADC .../devicetree/bindings/arm/samsung/exynos-adc.txt | 25 +- arch/arm/boot/dts/exynos3250.dtsi | 5 +- drivers/iio/adc/exynos_adc.c | 335 +++-- 3 files changed, 275 insertions(+), 90 deletions(-) -- 1.8.0 -- 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
[PATCHv8 1/4] iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
This patchset add 'exynos_adc_data' structure which includes some functions
to control ADC operation and specific data according to ADC version (v1 or v2).
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/iio/adc/exynos_adc.c | 226 ---
1 file changed, 147 insertions(+), 79 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 010578f..dde4ca8 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -39,11 +39,6 @@
#include linux/iio/machine.h
#include linux/iio/driver.h
-enum adc_version {
- ADC_V1,
- ADC_V2
-};
-
/* EXYNOS4412/5250 ADC_V1 registers definitions */
#define ADC_V1_CON(x) ((x) + 0x00)
#define ADC_V1_DLY(x) ((x) + 0x08)
@@ -85,6 +80,7 @@ enum adc_version {
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
struct exynos_adc {
+ struct exynos_adc_data *data;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
@@ -97,43 +93,139 @@ struct exynos_adc {
unsigned intversion;
};
-static const struct of_device_id exynos_adc_match[] = {
- { .compatible = samsung,exynos-adc-v1, .data = (void *)ADC_V1 },
- { .compatible = samsung,exynos-adc-v2, .data = (void *)ADC_V2 },
- {},
+struct exynos_adc_data {
+ int num_channels;
+
+ void (*init_hw)(struct exynos_adc *info);
+ void (*exit_hw)(struct exynos_adc *info);
+ void (*clear_irq)(struct exynos_adc *info);
+ void (*start_conv)(struct exynos_adc *info, unsigned long addr);
};
-MODULE_DEVICE_TABLE(of, exynos_adc_match);
-static inline unsigned int exynos_adc_get_version(struct platform_device *pdev)
+static void exynos_adc_v1_init_hw(struct exynos_adc *info)
{
- const struct of_device_id *match;
+ u32 con1;
- match = of_match_node(exynos_adc_match, pdev-dev.of_node);
- return (unsigned int)match-data;
+ writel(1, info-enable_reg);
+
+ /* set default prescaler values and Enable prescaler */
+ con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+ /* Enable 12-bit ADC resolution */
+ con1 |= ADC_V1_CON_RES;
+ writel(con1, ADC_V1_CON(info-regs));
+}
+
+static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
+{
+ u32 con;
+
+ writel(0, info-enable_reg);
+
+ con = readl(ADC_V1_CON(info-regs));
+ con |= ADC_V1_CON_STANDBY;
+ writel(con, ADC_V1_CON(info-regs));
+}
+
+static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
+{
+ writel(1, ADC_V1_INTCLR(info-regs));
}
-static void exynos_adc_hw_init(struct exynos_adc *info)
+static void exynos_adc_v1_start_conv(struct exynos_adc *info,
+unsigned long addr)
+{
+ u32 con1;
+
+ writel(addr, ADC_V1_MUX(info-regs));
+
+ con1 = readl(ADC_V1_CON(info-regs));
+ writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info-regs));
+}
+
+static const struct exynos_adc_data const exynos_adc_v1_data = {
+ .num_channels = MAX_ADC_V1_CHANNELS,
+
+ .init_hw= exynos_adc_v1_init_hw,
+ .exit_hw= exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_v1_start_conv,
+};
+
+static void exynos_adc_v2_init_hw(struct exynos_adc *info)
{
u32 con1, con2;
- if (info-version == ADC_V2) {
- con1 = ADC_V2_CON1_SOFT_RESET;
- writel(con1, ADC_V2_CON1(info-regs));
+ writel(1, info-enable_reg);
- con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
- ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
- writel(con2, ADC_V2_CON2(info-regs));
+ con1 = ADC_V2_CON1_SOFT_RESET;
+ writel(con1, ADC_V2_CON1(info-regs));
- /* Enable interrupts */
- writel(1, ADC_V2_INT_EN(info-regs));
- } else {
- /* set default prescaler values and Enable prescaler */
- con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+ con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+ ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+ writel(con2, ADC_V2_CON2(info-regs));
- /* Enable 12-bit ADC resolution */
- con1 |= ADC_V1_CON_RES;
- writel(con1, ADC_V1_CON(info-regs));
- }
+ /* Enable interrupts */
+ writel(1, ADC_V2_INT_EN(info-regs));
+}
+
+static void exynos_adc_v2_exit_hw(struct exynos_adc *info)
+{
+ u32 con;
+
+ writel(0, info-enable_reg);
+
+ con = readl(ADC_V2_CON1(info-regs));
+ con = ~ADC_CON_EN_START;
+ writel(con, ADC_V2_CON1(info-regs));
+}
+
+static void
[PATCHv8 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_adc' clock as following:
- 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
clock in FSYS_BLK.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/iio/adc/exynos_adc.c | 111 +++
1 file changed, 103 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index dde4ca8..87e0895 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -24,6 +24,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/delay.h
+#include linux/errno.h
#include linux/kernel.h
#include linux/slab.h
#include linux/io.h
@@ -70,8 +71,9 @@
#define ADC_V2_CON2_ACH_SEL(x) (((x) 0xF) 0)
#define ADC_V2_CON2_ACH_MASK 0xF
-#define MAX_ADC_V2_CHANNELS10
-#define MAX_ADC_V1_CHANNELS8
+#define MAX_ADC_V2_CHANNELS10
+#define MAX_ADC_V1_CHANNELS8
+#define MAX_EXYNOS3250_ADC_CHANNELS2
/* Bit definitions common for ADC_V1 and ADC_V2 */
#define ADC_CON_EN_START (1u 0)
@@ -81,9 +83,11 @@
struct exynos_adc {
struct exynos_adc_data *data;
+ struct device *dev;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -95,6 +99,7 @@ struct exynos_adc {
struct exynos_adc_data {
int num_channels;
+ bool needs_sclk;
void (*init_hw)(struct exynos_adc *info);
void (*exit_hw)(struct exynos_adc *info);
@@ -102,6 +107,66 @@ struct exynos_adc_data {
void (*start_conv)(struct exynos_adc *info, unsigned long addr);
};
+static void exynos_adc_unprepare_clk(struct exynos_adc *info)
+{
+ if (info-data-needs_sclk)
+ clk_unprepare(info-sclk);
+ clk_unprepare(info-clk);
+}
+
+static int exynos_adc_prepare_clk(struct exynos_adc *info)
+{
+ int ret;
+
+ ret = clk_prepare(info-clk);
+ if (ret) {
+ dev_err(info-dev, failed preparing adc clock: %d\n, ret);
+ return ret;
+ }
+
+ if (info-data-needs_sclk) {
+ ret = clk_prepare(info-sclk);
+ if (ret) {
+ clk_unprepare(info-clk);
+ dev_err(info-dev,
+ failed preparing sclk_adc clock: %d\n, ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static void exynos_adc_disable_clk(struct exynos_adc *info)
+{
+ if (info-data-needs_sclk)
+ clk_disable(info-sclk);
+ clk_disable(info-clk);
+}
+
+static int exynos_adc_enable_clk(struct exynos_adc *info)
+{
+ int ret;
+
+ ret = clk_enable(info-clk);
+ if (ret) {
+ dev_err(info-dev, failed enabling adc clock: %d\n, ret);
+ return ret;
+ }
+
+ if (info-data-needs_sclk) {
+ ret = clk_enable(info-sclk);
+ if (ret) {
+ clk_disable(info-clk);
+ dev_err(info-dev,
+ failed enabling sclk_adc clock: %d\n, ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
static void exynos_adc_v1_init_hw(struct exynos_adc *info)
{
u32 con1;
@@ -208,6 +273,16 @@ static const struct exynos_adc_data const
exynos_adc_v2_data = {
.start_conv = exynos_adc_v2_start_conv,
};
+static const struct exynos_adc_data const exynos3250_adc_data = {
+ .num_channels = MAX_EXYNOS3250_ADC_CHANNELS,
+ .needs_sclk = true,
+
+ .init_hw= exynos_adc_v2_init_hw,
+ .exit_hw= exynos_adc_v2_exit_hw,
+ .clear_irq = exynos_adc_v2_clear_irq,
+ .start_conv = exynos_adc_v2_start_conv,
+};
+
static const struct of_device_id exynos_adc_match[] = {
{
.compatible = samsung,exynos-adc-v1,
@@ -215,6 +290,9 @@ static const struct of_device_id exynos_adc_match[] = {
}, {
.compatible = samsung,exynos-adc-v2,
.data = exynos_adc_v2_data,
+ }, {
+ .compatible = samsung,exynos3250-adc,
+ .data = exynos3250_adc_data,
},
{},
};
@@
[PATCHv8 4/4] ARM: dts: Fix wrong compatible string for Exynos3250 ADC
This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
need to control only special clock for ADC. Exynos SoC except for Exynos3250
has not included special clock for ADC. The exynos ADC driver can control
special clock if compatible string is 'exynos3250-adc-v2'.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
arch/arm/boot/dts/exynos3250.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 15c9c87..767189a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -407,10 +407,11 @@
};
adc: adc@126C {
- compatible = samsung,exynos-adc-v3;
+ compatible = samsung,exynos3250-adc,
+samsung,exynos-adc-v2;
reg = 0x126C 0x100, 0x10020718 0x4;
interrupts = 0 137 0;
- clock-names = adc, sclk_tsadc;
+ clock-names = adc, sclk;
clocks = cmu CLK_TSADC, cmu CLK_SCLK_TSADC;
#io-channel-cells = 1;
io-channel-ranges;
--
1.8.0
--
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
[PATCHv8 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_adc') for ADC which provide clock to internal ADC.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 25 --
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 832fe8c..adc61b0 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,14 +14,21 @@ Required properties:
for exynos4412/5250 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
+ Must be samsung,exynos3250-adc for
+ controllers compatible with ADC of Exynos3250.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
- #io-channel-cells = 1; As ADC has multiple outputs
-- clocks From common clock binding: handle to adc clock.
-- clock-names From common clock binding: Shall be adc.
+- clocks From common clock bindings: handles to clocks specified
+ in clock-names property, in the same order.
+- clock-names From common clock bindings: list of clock input names
+ used by ADC block:
+ - adc : ADC bus clock
+ - sclk : ADC special clock (only for Exynos3250 and
+ compatible ADC block)
- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +48,20 @@ adc: adc@12D1 {
vdd-supply = buck5_reg;
};
+Example: adding device info in dtsi file for Exynos3250 with additional sclk
+
+adc: adc@126C {
+ compatible = samsung,exynos3250-adc, samsung,exynos-adc-v2;
+ reg = 0x126C 0x100, 0x10020718 0x4;
+ interrupts = 0 137 0;
+ #io-channel-cells = 1;
+ io-channel-ranges;
+
+ clocks = cmu CLK_TSADC, cmu CLK_SCLK_TSADC;
+ clock-names = adc, sclk;
+
+ vdd-supply = buck5_reg;
+};
Example: Adding child nodes in dts file
--
1.8.0
--
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 2/2] iio: adc: exynos_adc: Add support for S3C24xx ADC
This patch add support for s3c2410/s3c2416/s3c2440/s3c2443 ADC. The s3c24xx
is alomost same as ADCv1. But, There are a little difference as following:
- ADCMUX register address to select channel
- ADCDAT mask (10bit or 12bit ADC resolution according to SoC version)
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 10 ++-
drivers/iio/adc/exynos_adc.c | 89 +-
2 files changed, 96 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index b6e3989..fe34c76 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -11,11 +11,19 @@ New driver handles the following
Required properties:
- compatible: Must be samsung,exynos-adc-v1
- for exynos4412/5250 controllers.
+ for exynos4412/5250 and s5pv210 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
Must be samsung,exynos3250-adc for
controllers compatible with ADC of Exynos3250.
+ Must be samsung,s3c2410-adc for
+ the ADC in s3c2410 and compatibles
+ Must be samsung,s3c2416-adc for
+ the ADC in s3c2416 and compatibles
+ Must be samsung,s3c2440-adc for
+ the ADC in s3c2440 and compatibles
+ Must be samsung,s3c2443-adc for
+ the ADC in s3c2443 and compatibles
Must be samsung,s3c6410-adc for
the ADC in s3c6410 and compatibles
- reg: Contains ADC register address range (base address and
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 05bdd2f12..7d28032 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -51,6 +51,9 @@
#define ADC_V1_MUX(x) ((x) + 0x1c)
#define ADC_V1_CLRINTPNDNUP(x) ((x) + 0x20)
+/* S3C2410 ADC registers definitions */
+#define ADC_S3C2410_MUX(x) ((x) + 0x18)
+
/* Future ADC_V2 registers definitions */
#define ADC_V2_CON1(x) ((x) + 0x00)
#define ADC_V2_CON2(x) ((x) + 0x04)
@@ -67,6 +70,8 @@
/* Bit definitions for S3C2410 ADC */
#define ADC_S3C2410_CON_SELMUX(x) (((x) 7) 3)
+#define ADC_S3C2410_DATX_MASK 0x3FF
+#define ADC_S3C2416_CON_RES_SEL(1 3)
/* Bit definitions for ADC_V2 */
#define ADC_V2_CON1_SOFT_RESET (1u 2)
@@ -84,6 +89,7 @@
/* Bit definitions common for ADC_V1 and ADC_V2 */
#define ADC_CON_EN_START (1u 0)
+#define ADC_CON_EN_START_MASK (0x3 0)
#define ADC_DATX_MASK 0xFFF
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
@@ -101,12 +107,14 @@ struct exynos_adc {
struct completion completion;
u32 value;
+ u32 value2;
unsigned intversion;
};
struct exynos_adc_data {
int num_channels;
bool needs_sclk;
+ u32 mask;
void (*init_hw)(struct exynos_adc *info);
void (*exit_hw)(struct exynos_adc *info);
@@ -217,6 +225,17 @@ static void exynos_adc_v1_start_conv(struct exynos_adc
*info,
static const struct exynos_adc_data const exynos_adc_v1_data = {
.num_channels = MAX_ADC_V1_CHANNELS,
+ .mask = ADC_DATX_MASK, /* 12bit ADC resolution */
+
+ .init_hw= exynos_adc_v1_init_hw,
+ .exit_hw= exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_v1_start_conv,
+};
+
+static struct exynos_adc_data const exynos_adc_s3c24xx_data = {
+ .num_channels = MAX_ADC_V1_CHANNELS,
+ .mask = ADC_S3C2410_DATX_MASK, /* 10bit ADC resolution */
.init_hw= exynos_adc_v1_init_hw,
.exit_hw= exynos_adc_v1_exit_hw,
@@ -224,6 +243,55 @@ static const struct exynos_adc_data const
exynos_adc_v1_data = {
.start_conv = exynos_adc_v1_start_conv,
};
+static void exynos_adc_s3c2416_start_conv(struct exynos_adc *info,
+ unsigned long addr)
+{
+ u32 con1;
+
+ /* Enable 12bit ADC resolution */
+ con1 = readl(ADC_V1_CON(info-regs));
+ con1 |= ADC_S3C2416_CON_RES_SEL;
+ writel(con1, ADC_V1_CON(info-regs));
+
+ /* Select channel for S3C2416 */
+ writel(addr, ADC_S3C2410_MUX(info-regs));
+
+ con1 = readl(ADC_V1_CON(info-regs));
+ writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info-regs));
+}
+
+static struct exynos_adc_data const
[PATCH 0/2] iio: adc: exynos_adc: Add support for s3c64xx/s3c24xx ADC
This patch add support for s3c64xx/s3c24xx ADC. s3c64xx/s3c24xx is alomost same as ADCv1. But, s3c64xx/s3c24xx has a little difference from ADCv1 as following: - ADCMUX register address to select channel - ADCDAT mask (10bit or 12bit ADC resolution according to SoC version) This patchset is implemented based on exynos3250 ADC patchset[1]. [1] http://www.spinics.net/lists/kernel/msg1791299.html Arnd Bergmann (1): iio: adc: exynos_adc: add support for s3c64xx adc Chanwoo Choi (1): iio: adc: exynos_adc: Add support for S3C24xx ADC .../devicetree/bindings/arm/samsung/exynos-adc.txt | 12 +- drivers/iio/adc/exynos_adc.c | 121 - 2 files changed, 129 insertions(+), 4 deletions(-) -- 1.8.0 -- 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 1/2] iio: adc: exynos_adc: add support for s3c64xx adc
From: Arnd Bergmann a...@arndb.de
The ADC in s3c64xx is almost the same as exynosv1, but
has a different 'select' method. Adding this here will be
helpful to move over the existing s3c64xx platform from the
legacy plat-samsung/adc driver to the new exynos-adc.
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 2 ++
drivers/iio/adc/exynos_adc.c | 32 +-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 6d34891..b6e3989 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -16,6 +16,8 @@ Required properties:
future controllers.
Must be samsung,exynos3250-adc for
controllers compatible with ADC of Exynos3250.
+ Must be samsung,s3c6410-adc for
+ the ADC in s3c6410 and compatibles
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 87e0895..05bdd2f12 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,12 +40,16 @@
#include linux/iio/machine.h
#include linux/iio/driver.h
-/* EXYNOS4412/5250 ADC_V1 registers definitions */
+/* S3C/EXYNOS4412/5250 ADC_V1 registers definitions */
#define ADC_V1_CON(x) ((x) + 0x00)
+#define ADC_V1_TSC(x) ((x) + 0x04)
#define ADC_V1_DLY(x) ((x) + 0x08)
#define ADC_V1_DATX(x) ((x) + 0x0C)
+#define ADC_V1_DATY(x) ((x) + 0x10)
+#define ADC_V1_UPDN(x) ((x) + 0x14)
#define ADC_V1_INTCLR(x) ((x) + 0x18)
#define ADC_V1_MUX(x) ((x) + 0x1c)
+#define ADC_V1_CLRINTPNDNUP(x) ((x) + 0x20)
/* Future ADC_V2 registers definitions */
#define ADC_V2_CON1(x) ((x) + 0x00)
@@ -61,6 +65,9 @@
#define ADC_V1_CON_PRSCLV(x) (((x) 0xFF) 6)
#define ADC_V1_CON_STANDBY (1u 2)
+/* Bit definitions for S3C2410 ADC */
+#define ADC_S3C2410_CON_SELMUX(x) (((x) 7) 3)
+
/* Bit definitions for ADC_V2 */
#define ADC_V2_CON1_SOFT_RESET (1u 2)
@@ -217,6 +224,26 @@ static const struct exynos_adc_data const
exynos_adc_v1_data = {
.start_conv = exynos_adc_v1_start_conv,
};
+static void exynos_adc_s3c64xx_start_conv(struct exynos_adc *info,
+ unsigned long addr)
+{
+ u32 con1;
+
+ con1 = readl(ADC_V1_CON(info-regs));
+ con1 = ~ADC_S3C2410_CON_SELMUX(7);
+ con1 |= ADC_S3C2410_CON_SELMUX(addr);
+ writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info-regs));
+}
+
+static struct exynos_adc_data const exynos_adc_s3c64xx_data = {
+ .num_channels = MAX_ADC_V1_CHANNELS,
+
+ .init_hw= exynos_adc_v1_init_hw,
+ .exit_hw= exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_s3c64xx_start_conv,
+};
+
static void exynos_adc_v2_init_hw(struct exynos_adc *info)
{
u32 con1, con2;
@@ -285,6 +312,9 @@ static const struct exynos_adc_data const
exynos3250_adc_data = {
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = samsung,s3c6410-adc,
+ .data = exynos_adc_s3c64xx_data,
+ }, {
.compatible = samsung,exynos-adc-v1,
.data = exynos_adc_v1_data,
}, {
--
1.8.0
--
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 v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
Hi,
On 07/22/2014 10:23 AM, Inki Dae wrote:
On 2014년 07월 21일 23:01, Andrzej Hajda wrote:
On 07/17/2014 11:01 AM, YoungJun Cho wrote:
To support LCD I80 interface, the DSI host should register
TE interrupt handler from the TE GPIO of attached panel.
So the panel generates a tearing effect synchronization signal
then the DSI host calls the CRTC device manager to trigger
to transfer video image.
This whole patch seems to be a hack.
I think it is not a good idea to parse property of one device by another
device's driver.
Especially here TE GPIO belongs to the panel. The panel driver should
know how to configure it and how to use it or not. The panel driver will
generate TE signal based on this GPIO, DSI/BTA mechanism or any other
mechanism provided by the panel.
TE signal should be delivered to the display controller. The only role
of DSIM here is that it is between the panel and the display controller
so it should be used to route this signal to DC.
It looks like DSIM transfers only TE signal to FIMD, but there is one
thing important role, DSIM transfers TE signal only it is activated.
Without this thing, a broken screen would be showed at booting time.
According to specs TE signal should/can be generated by DBI and DSI
command mode panels, so its handling should be more generic, not Exynos
specific.
Right. However, it seems that there are no much users using command mode
panel so we would need more times to discuss the generic way. I think we
can have this feature in specific to Exynos drm - it doesn't affect
other SoC -. Actually, I know OMAP people handle this feature in a way
For your information, there is a dsicm_te_isr() in
drivers/video/fbdev/omap2/displays-new.
It seems like that panel - dsi - display controller.
Thank you.
Best regards YJ
specific to OMAP SoC. If other users need more generic way to this
feature then we could have a discussion about the generic way at that time.
That is why Mr. Cho implemented TE feature like this. Do you have more
good idea? I wish the idea would be specific so that Mr. Cho can
implement it.
P.s. Thierry already opposed the use of mipi_dsi_host_ops, I agree with
him. And also it seems not good to use crtc and encoder/connector
because these frameworks are common to all architecture including x86 so
other architectures wouldn't need TE feature.
Thanks,
Inki Dae
Regards
Andrzej
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 95 -
1 file changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 58bfb2a..4997bfe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -16,7 +16,9 @@
#include drm/drm_panel.h
#include linux/clk.h
+#include linux/gpio/consumer.h
#include linux/irq.h
+#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
#include linux/component.h
@@ -24,6 +26,7 @@
#include video/mipi_display.h
#include video/videomode.h
+#include exynos_drm_crtc.h
#include exynos_drm_drv.h
/* returns true iff both arguments logically differs */
@@ -247,6 +250,7 @@ struct exynos_dsi {
struct clk *bus_clk;
struct regulator_bulk_data supplies[2];
int irq;
+ int te_gpio;
u32 pll_clk_rate;
u32 burst_clk_rate;
@@ -954,17 +958,89 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
+{
+ struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
+ struct drm_encoder *encoder = dsi-encoder;
+
+ if (dsi-state DSIM_STATE_ENABLED)
+ exynos_drm_crtc_te_handler(encoder-crtc);
+
+ return IRQ_HANDLED;
+}
+
+static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+{
+ enable_irq(dsi-irq);
+
+ if (gpio_is_valid(dsi-te_gpio))
+ enable_irq(gpio_to_irq(dsi-te_gpio));
+}
+
+static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+{
+ if (gpio_is_valid(dsi-te_gpio))
+ disable_irq(gpio_to_irq(dsi-te_gpio));
+
+ disable_irq(dsi-irq);
+}
+
static int exynos_dsi_init(struct exynos_dsi *dsi)
{
exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
- enable_irq(dsi-irq);
+ exynos_dsi_enable_irq(dsi);
exynos_dsi_wait_for_reset(dsi);
exynos_dsi_init_link(dsi);
return 0;
}
+static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
+{
+ int ret;
+
+ dsi-te_gpio = of_get_named_gpio(dsi-panel_node, te-gpios, 0);
+ if (!gpio_is_valid(dsi-te_gpio)) {
+ dev_err(dsi-dev, no te-gpios specified\n);
+ ret = dsi-te_gpio;
+ goto out;
+ }
+
+ ret =
Re: [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
Hi Arnd,
On 07/21/2014 05:58 PM, Arnd Bergmann wrote:
On Monday 21 July 2014 17:17:44 Chanwoo Choi wrote:
On 07/21/2014 05:11 PM, Chanwoo Choi wrote:
On 07/21/2014 04:38 PM, Arnd Bergmann wrote:
On Monday 21 July 2014 11:17:44 Chanwoo Choi wrote:
This patchset support Exynos3250 ADC (Analog Digital Converter) because
Exynos3250 has additional special clock for ADC IP.
Changes from v6:
- Use exynos3250-adc compatible string instead of exynos3250-adc-v2
- Use sclk clock name instead of sclk_adc
- Remove un-necessary macro for exyno-adc-data-v2 structure.
- Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
- Change the number of ADC channels (Exynos3250 has only two channels for
ADC)
Looks good to me. Two small requests:
a) if you don't mind, can you add my patch (1/2) to add support for
s3c64xx to
your series, adding your Signed-off-by line in addition to mine? I think
that one was noncontroversial, while the second patch (2/2) need some
more
work to address the comments and do testing.
OK, I'll add this patch.
But, I have a question.
Your patch add following compatible string.
s3c64100-adc is right?
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = samsung,s3c64100-adc,
+ .data = exynos_adc_s3c64xx_data,
+ }, {
Additionally,
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt has not included
samsung,s3c6410-adc compatible string. Should I add this string in
exynos-adc.txt?
drivers/iio/adc/exynos-adc.c has not includeded following compatible string.
Should I add this compatible string on exynos-adc.c?
+Must be samsung,s3c2410-adc for
+the ADC in s3c2410 and compatibles
+Must be samsung,s3c2416-adc for
+the ADC in s3c2416 and compatibles
+Must be samsung,s3c2440-adc for
+the ADC in s3c2440 and compatibles
+Must be samsung,s3c2440-adc for
+the ADC in s3c2440 and compatibles
+Must be samsung,s3c2443-adc for
+the ADC in s3c2443 and compatibles
Yes, please.
I send following patchset[1] to support s3c24xx/s3c64xx ADC.
[1] http://www.spinics.net/lists/kernel/msg1791305.html
Thanks,
Chanwoo Choi
--
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 v6 10/14] drm/panel: add S6E3FA0 driver
Hi,
On 07/21/2014 08:18 PM, Andrzej Hajda wrote:
On 07/21/2014 11:19 AM, Thierry Reding wrote:
On Mon, Jul 21, 2014 at 10:56:08AM +0200, Andrzej Hajda wrote:
On 07/18/2014 03:49 AM, YoungJun Cho wrote:
Hi Thierry,
Thank you a lot for kind comments.
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
[...]
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER 0xb0
+#define MCS_AID0xb2
+#define MCS_ELVSSOPT 0xb6
+#define MCS_TEMPERATURE_SET0xb8
+#define MCS_PENTILE_CTRL 0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM 0xd7
+#define MCS_ALS0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1 0xf0
+#define MCS_GAMMA_UPDATE 0xf7
+#define MCS_KEY_LEV2 0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
Is this not a manufacturer specific command? I couldn't find it in the
DSI or DCS specifications, but it sounds like something standard (also
indicated by the DCS_ prefix). Can you point out the specification for
this?
Andrzej commented before and decided it as DCS one because if the value
is less than 0xb0, it is DCS one and the others are MCS one.
But still I'm not sure it is correct.
I would not say 'decided'. I have just stated that according to DCS
specification
it should be DCS command (below 0xb0), but it is not present in mipi dcs
specs.
On the other side many panels have it [1]:
[1]:
https://www.google.com/search?q=%22Write+Content+Adaptive+Brightness+Control%22
Yeah, my search yielded similar results. I wonder if this is perhaps
part of a draft future specification. I'll try to ask around some more
if anybody knows what the status of this is.
+static void s6e3fa0_read_mtp_id(struct s6e3fa0 *ctx)
+{
+ unsigned char id[MTP_ID_LEN];
+ int ret;
+
+ s6e3fa0_set_maximum_return_packet_size(ctx, MTP_ID_LEN);
+ ret = s6e3fa0_dcs_read(ctx, MIPI_DCS_GET_DISPLAY_ID, id, MTP_ID_LEN);
This also looks like a standard DCS command. I can't find it in either
v1.01 nor v1.02 of the specification, though. Do you know where it's
specified?
Yes, I also can't find it in DCS specification and there is no special
description in panel datasheet.
But as it is declared in include/video/mipi_display.h, so I think it
is a standard one.
On page 9 of the Introduction of MIPI by Renesas [2] there is info
it is a part of Nokia I/F command list, I guess it is kind of alpha
version of MIPI DCS.
[2]: http://wenku.baidu.com/view/658fab68af1ffc4ffe47acbe.html
That link is the only one which contains Nokia I/F command list on the
internet (that is, according to Google). But since this is already part
of the mipi_display.h header file we may as well use it.
I wonder if perhaps the READ_DDB_START and READ_DDB_CONTINUE commands
could be used as a replacement for this display ID.
There is a simple description for Read DDB Start(A1H) like below.
- This command returns supplier identification and display module model
/ revision information.
- NOTE: This information is not the same what Read IDs(04H) command is
returning.
For reference, Read IDs(04H) description is like below.
- This read command returns 24-bit display identification information.
- The first read byte identifies the OLED module's manufacturer.
- The Second read byte is used to track the OLED module/driver version.
- The third read byte identifies the OLED module/driver.
Adding Guennadi, Tomi, Paul and Imre on Cc since they were involved with
the original patch that added mipi_display.h. Perhaps they remember what
the origin of this command is.
I guess it was PCF8833 used in Nokia 6100 [1][2].
[1]: http://www.vintagecomputercables.com/datasheet/PCF8833_1.pdf
[2]:
http://www.elecfreaks.com/store/download/datasheet/shield/6100_Display_Driver.pdf
Yes, this command is related with Nokia.
Last Friday, I met panel vendor guy for some issues.
At the break time, I asked him for about this Read IDs(04H), why it is
not included in DCS specification.
He said that this command was originated by Nokia.
In feature phone times, most of panel vendors wanted their panels to be
used by Nokia and Nokia wanted this command, so most of panel vendors
still provide this command traditionally.
Thank you.
Best regards YJ
Regards
Andrzej
Thierry
--
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] cpufreq: tests: Providing cpufreq regression test
Hi Lukasz, On Fri, Jul 18, 2014 at 5:29 PM, Lukasz Majewski l.majew...@samsung.com wrote: Hi Sachin, Hi Lukasz, I tested this script on 4210 based Origen board. This is the output: ./cpufreq_freq_test.sh CURRENT GOVERNOR: performance SET GOVERNOR: performance ## TEST AVAILABLE FREQS ## FREQ: 120 sleep: invalid number '0.1' [5.918347] random: gzip urandom read with 61 bits of entropy available OK FREQ: 100 sleep: invalid number '0.1' OK FREQ: 80 sleep: invalid number '0.1' OK FREQ: 50 sleep: invalid number '0.1' OK FREQ: 20 sleep: invalid number '0.1' OK ## TEST FREQS SWITCHING ## REFERENCE FREQ: 120 FREQ: 120 FREQ: 120 sleep: invalid number '0.1' OK FREQ: 120 FREQ: 100 sleep: invalid number '0.1' OK FREQ: 120 FREQ: 80 sleep: invalid number '0.1' OK FREQ: 120 FREQ: 50 sleep: invalid number '0.1' OK FREQ: 120 FREQ: 20 sleep: invalid number '0.1' OK REFERENCE FREQ: 100 FREQ: 100 FREQ: 120 sleep: invalid number '0.1' OK FREQ: 100 FREQ: 100 sleep: invalid number '0.1' OK FREQ: 100 FREQ: 80 sleep: invalid number '0.1' OK FREQ: 100 FREQ: 50 sleep: invalid number '0.1' OK FREQ: 100 FREQ: 20 sleep: invalid number '0.1' OK REFERENCE FREQ: 80 FREQ: 80 FREQ: 120 sleep: invalid number '0.1' OK FREQ: 80 FREQ: 100 sleep: invalid number '0.1' OK FREQ: 80 FREQ: 80 sleep: invalid number '0.1' OK FREQ: 80 FREQ: 50 sleep: invalid number '0.1' OK FREQ: 80 FREQ: 20 sleep: invalid number '0.1' OK REFERENCE FREQ: 50 FREQ: 50 FREQ: 120 sleep: invalid number '0.1' OK FREQ: 50 FREQ: 100 sleep: invalid number '0.1' OK FREQ: 50 FREQ: 80 sleep: invalid number '0.1' OK FREQ: 50 FREQ: 50 sleep: invalid number '0.1' OK FREQ: 50 FREQ: 20 sleep: invalid number '0.1' OK REFERENCE FREQ: 20 FREQ: 20 FREQ: 120 sleep: invalid number '0.1' OK FREQ: 20 FREQ: 100 sleep: invalid number '0.1' OK FREQ: 20 FREQ: 80 sleep: invalid number '0.1' OK FREQ: 20 FREQ: 50 sleep: invalid number '0.1' OK FREQ: 20 FREQ: 20 sleep: invalid number '0.1' OK ## ERRORS: 0 ## Though it says 0 errors, what does the invalid number... signify? I guess that this message is caused by your default sleep implementation. Could you type 'sleep 0.1' and then 'sleep 1' in your console on the target system? Is the invalid number not present with the second case? Only with first case (sleep 0.1) I get the invalid number message. sleep 1 seems to be OK. -- Regards, Sachin. -- 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
