Re: [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
On Mon, Jul 21, 2014 at 8:14 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Jul 21, 2014 at 08:06:01PM +0530, Ajay kumar wrote:
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
Re: [RESEND PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
On Mon, Jul 21, 2014 at 11:34 AM, Zhang Rui rui.zh...@intel.com wrote:
On Fri, 2014-07-18 at 09:00 +0900, Chanwoo Choi wrote:
This patch adds the registers, bit fields and compatible strings
required to support for the 1 TMU channels on Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
[Add MUX address setting bits by Jonghwa Lee]
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
Eduardo and Amit,
do you have any comments on this?
The changes looks fine to me. I already reviewed these patches earlier.
thanks,
Amit
thanks,
rui
---
.../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
drivers/thermal/samsung/exynos_tmu.c | 7 +-
drivers/thermal/samsung/exynos_tmu.h | 3 +-
drivers/thermal/samsung/exynos_tmu_data.c | 89
++
drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
5 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index c949092..ae738f5 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -3,6 +3,7 @@
** Required properties:
- compatible : One of the following:
+samsung,exynos3250-tmu
samsung,exynos4412-tmu
samsung,exynos4210-tmu
samsung,exynos5250-tmu
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index d7ca9f4..a2a08ea 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -505,6 +505,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static const struct of_device_id exynos_tmu_match[] = {
{
+ .compatible = samsung,exynos3250-tmu,
+ .data = (void *)EXYNOS3250_TMU_DRV_DATA,
+ },
+ {
.compatible = samsung,exynos4210-tmu,
.data = (void *)EXYNOS4210_TMU_DRV_DATA,
},
@@ -677,7 +681,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
goto err_clk_sec;
}
- if (pdata-type == SOC_ARCH_EXYNOS4210 ||
+ if (pdata-type == SOC_ARCH_EXYNOS3250 ||
+ pdata-type == SOC_ARCH_EXYNOS4210 ||
pdata-type == SOC_ARCH_EXYNOS4412 ||
pdata-type == SOC_ARCH_EXYNOS5250 ||
pdata-type == SOC_ARCH_EXYNOS5260 ||
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index edd08cf..1b4a644 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -40,7 +40,8 @@ enum calibration_mode {
};
enum soc_type {
- SOC_ARCH_EXYNOS4210 = 1,
+ SOC_ARCH_EXYNOS3250 = 1,
+ SOC_ARCH_EXYNOS4210,
SOC_ARCH_EXYNOS4412,
SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5260,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index c1d81dc..aa8e0de 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
exynos4210_default_tmu_data = {
};
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+static const struct exynos_tmu_registers exynos3250_tmu_registers = {
+ .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
+ .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
+ .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
+ .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
+ .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
+ .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
+ .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
+ .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
+ .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
+ .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
+ .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
+ .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
+ .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
+ .tmu_status = EXYNOS_TMU_REG_STATUS,
+ .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
+ .threshold_th0 = EXYNOS_THD_TEMP_RISE,
+ .threshold_th1 = EXYNOS_THD_TEMP_FALL,
+ .tmu_inten = EXYNOS_TMU_REG_INTEN,
+ .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
+ .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
+ .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
+ .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
+ .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
+ .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
+ .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
+ .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
+ .intclr_fall_mask =
Re: [RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining
On Mon, Jul 21, 2014 at 6:10 PM, Thierry Reding thierry.red...@gmail.com wrote: 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 Going with Thierry's opinion, if the bridge is allowed to do panel integration, there is no need for a bridge_chain. I mean a bridge_chain doesn't exist in my case at all. I have just one bridge which integrates a panel. Is it really necessary to keep next_bridge pointer and other helpers? 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 v6 10/14] drm/panel: add S6E3FA0 driver
On Tue, Jul 22, 2014 at 12:41:21PM +0900, YoungJun Cho wrote:
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:
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
+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.
Okay, that explains things a little better. Can you point me to the
document that this is from?
But what I was trying to say is that if the Read IDs command isn't an
official DCS command, maybe it would be a better idea to use the DDB
instead. I assume that even if it isn't the same information it would
at least be a superset and therefore a suitable replacement.
Thierry
pgpNovaPZL3cI.pgp
Description: PGP signature
Re: [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
On Tue, Jul 22, 2014 at 11:35:52AM +0530, Ajay kumar wrote:
On Mon, Jul 21, 2014 at 8:14 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Jul 21, 2014 at 08:06:01PM +0530, Ajay kumar wrote:
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
Re: [PATCH 2/2] iio: adc: exynos_adc: Add support for S3C24xx ADC
On Tuesday 22 July 2014 11:11:14 Chanwoo Choi wrote:
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)
Very good, thanks for doing this patch!
(adding Heiko to Cc, he's probably interested in seeing this as well.
One comment:
@@ -101,12 +107,14 @@ struct exynos_adc {
struct completion completion;
u32 value;
+ u32 value2;
unsigned intversion;
};
...
@@ -365,7 +448,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
ret = -ETIMEDOUT;
} else {
*val = info-value;
- *val2 = 0;
+ *val2 = info-value2;
ret = IIO_VAL_INT;
}
@@ -377,9 +460,11 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
{
struct exynos_adc *info = (struct exynos_adc *)dev_id;
+ u32 mask = info-data-mask;
/* Read value */
- info-value = readl(ADC_V1_DATX(info-regs)) ADC_DATX_MASK;
+ info-value = readl(ADC_V1_DATX(info-regs)) mask;
+ info-value2 = readl(ADC_V1_DATY(info-regs)) mask;
/* clear irq */
if (info-data-clear_irq)
If I understand it right, this would only be necessary if we want
to do the touchscreen driver as a separate iio client using the
in-kernel interfaces. As Jonathan Cameron commented, we probably
don't want to do that though. Even if we do, it should be a separate
patch and not mixed in with the s3c24xx support.
Aside from this:
Acked-by: Arnd Bergmann a...@arndb.de
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 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
On 07/22/2014 03: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.
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.
The good thing is that DT bindings in this case are OK, TE GPIO is in
panel node.
Maybe we can leave it this way for now, but at least lets add a comment to
the code describing that it is temporary solution and should be make
more generic in the future.
Regards
Andrzej
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);
+
Re: [PATCH v6 10/14] drm/panel: add S6E3FA0 driver
Hi Thierry,
On 07/22/2014 04:49 PM, Thierry Reding wrote:
On Tue, Jul 22, 2014 at 12:41:21PM +0900, YoungJun Cho wrote:
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:
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
+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.
Okay, that explains things a little better. Can you point me to the
document that this is from?
Sorry, I forgot to write specification name.
This specification is s6e3fa0 data sheet and it is confidential.
So I quoted only that portion.
But what I was trying to say is that if the Read IDs command isn't an
official DCS command, maybe it would be a better idea to use the DDB
instead. I assume that even if it isn't the same information it would
at least be a superset and therefore a suitable replacement.
This panel has several versions and each should set specific tuning
value especially for AID, ELVSS and etc.
(Current is suitable for id[2] == 0x23).
I'll check READ_DDB_START READ_DDB_CONTINUE result and try to use them
if it is possible.
Thank you.
Best regards YJ
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 v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
Hi Andrzej,
On 07/22/2014 07:12 PM, Andrzej Hajda wrote:
On 07/22/2014 03: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.
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.
The good thing is that DT bindings in this case are OK, TE GPIO is in
panel node.
Maybe we can leave it this way for now, but at least lets add a comment to
the code describing that it is temporary solution and should be make
more generic in the future.
Okay, I'll leave this comment at exynos_dsi_host_attach() before current
exynos_dsi_register_te_irq() relevant comment.
Thank you.
Best regards YJ
Regards
Andrzej
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);
+
Re: [PATCH 2/2] iio: adc: exynos_adc: Add support for S3C24xx ADC
Am Dienstag, 22. Juli 2014, 10:39:38 schrieb Arnd Bergmann:
On Tuesday 22 July 2014 11:11:14 Chanwoo Choi wrote:
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)
Very good, thanks for doing this patch!
(adding Heiko to Cc, he's probably interested in seeing this as well.
indeed. Thanks for implementing this.
While trying to build a test setup for this, I noticed two points:
(1) I'm not sure what the second register (a phy enable register according
to the binding) is supposed to be.
According to binding and adc code it is mandatory, but I didn't find any
lone adc register in the s3c2416 manual.
(2) You might need something along the lines of:
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 11b048a..088c99a 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -129,7 +129,7 @@ config AT91_ADC
config EXYNOS_ADC
tristate Exynos ADC driver support
- depends on ARCH_EXYNOS || (OF COMPILE_TEST)
+ depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF
COMPILE_TEST)
help
Core support for the ADC block found in the Samsung EXYNOS series
of SoCs for drivers such as the touchscreen and hwmon to use to share
Thanks
Heiko
One comment:
@@ -101,12 +107,14 @@ struct exynos_adc {
struct completion completion;
u32 value;
+ u32 value2;
unsigned intversion;
};
...
@@ -365,7 +448,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
ret = -ETIMEDOUT;
} else {
*val = info-value;
- *val2 = 0;
+ *val2 = info-value2;
ret = IIO_VAL_INT;
}
@@ -377,9 +460,11 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
{
struct exynos_adc *info = (struct exynos_adc *)dev_id;
+ u32 mask = info-data-mask;
/* Read value */
- info-value = readl(ADC_V1_DATX(info-regs)) ADC_DATX_MASK;
+ info-value = readl(ADC_V1_DATX(info-regs)) mask;
+ info-value2 = readl(ADC_V1_DATY(info-regs)) mask;
/* clear irq */
if (info-data-clear_irq)
If I understand it right, this would only be necessary if we want
to do the touchscreen driver as a separate iio client using the
in-kernel interfaces. As Jonathan Cameron commented, we probably
don't want to do that though. Even if we do, it should be a separate
patch and not mixed in with the s3c24xx support.
Aside from this:
Acked-by: Arnd Bergmann a...@arndb.de
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
[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
This is a temporary solution and should be made by more
generic way.
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.
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 | 97 -
1 file changed, 95 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..3adad44 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,18 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
if (dsi-connector.dev)
drm_helper_hpd_irq_event(dsi-connector.dev);
+ /*
+* This is a temporary solution and should be made by more generic way.
+*
+* If attached panel device is for command mode one, dsi should register
+* TE interrupt handler.
+*/
+ if (!(dsi-mode_flags MIPI_DSI_MODE_VIDEO)) {
+ int ret = exynos_dsi_register_te_irq(dsi);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
@@ -986,6 +1074,8 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host
*host,
{
struct exynos_dsi *dsi = host_to_dsi(host);
+
RE: [GIT PULL 4/5] Samsung exynos_mct update for v3.17
Daniel Lezcano wrote: 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. Olof, you're right. The branch has no dependency with arm-soc so I agreed. Yes, that's right. Furthermore I have been discussing with Doug about these patches before. Kukjin, is there any dependency on these patches ? Yeah, Daniel, it should be handled in the clocksource tree so how should I do for it? Thanks, Kukjin -- 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/22/2014 04:19 PM, YoungJun Cho wrote:
(...)
+ ret = gpio_request_one(dsi-te_gpio, GPIOF_IN, te_gpio);
devm_* APIs..?
+ 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);
why don't we use devm_request_threaded_irq()..?
--
Regards,
Varka Bhadram.
--
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 1/5] Samsung non-critical-fixes for v3.17
Olof Johansson wrote: On Sat, Jul 19, 2014 at 09:51:45AM +0900, Kukjin Kim wrote: 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/fixes-for-3.17 for you to fetch changes up to 042b687f880adcca77847688aac35e2e16927944: ARM: EXYNOS: Fix build breakge with PM_SLEEP=n (2014-07-19 04:45:02 +0900) Samsung non critical fixes for v3.17 - update exynos_defconfig for remove outdated configs and enable most of the configs used on latest exynos platforms - fix build breakge for exynos_defconfig with PM_SLEEP=n Hi, Hi, Olof, We now separate out defconfigs (as you might have noticed if you looked at our tree). I don't see any dependencies between these changes and the rest so I'll cherry-pick the patches into fixes-non-critical (for the build fix) and defconfig for that patch. OK, I'm fine and I will follow the way next time. Thanks for your cherry-pick and pulling other trees. - Kukjin -- 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 Varka,
This irq handler should be registered in attach() and unregistered in
detach().
The devm_* APIs are released(freed) in remove(), right?
Logically the panel could be attached and detached several times after
dsi is probed and not removed.
So I don't use devm_* APIs.
Thank you.
Best regards YJ
On 07/22/2014 07:57 PM, Varka Bhadram wrote:
On 07/22/2014 04:19 PM, YoungJun Cho wrote:
(...)
+ret = gpio_request_one(dsi-te_gpio, GPIOF_IN, te_gpio);
devm_* APIs..?
+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);
why don't we use devm_request_threaded_irq()..?
--
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/22/2014 04:40 PM, YoungJun Cho wrote: Hi Varka, This irq handler should be registered in attach() and unregistered in detach(). The devm_* APIs are released(freed) in remove(), right? Logically the panel could be attached and detached several times after dsi is probed and not removed. So I don't use devm_* APIs. You meant to say that in-case of GPIOs also you are following the same thing ..? Means requesting the GPIOs and Releasing several times ..? -- Regards, Varka Bhadram. -- 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 Varka, On 07/22/2014 08:14 PM, Varka Bhadram wrote: On 07/22/2014 04:40 PM, YoungJun Cho wrote: Hi Varka, This irq handler should be registered in attach() and unregistered in detach(). The devm_* APIs are released(freed) in remove(), right? Logically the panel could be attached and detached several times after dsi is probed and not removed. So I don't use devm_* APIs. You meant to say that in-case of GPIOs also you are following the same thing ..? Means requesting the GPIOs and Releasing several times ..? Yes, this TE gpio is came from panel. So it should be refresh whenever a (new) panel is attached. Thank you. Best regards YJ -- 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/22/2014 05:23 PM, YoungJun Cho wrote: Hi Varka, On 07/22/2014 08:14 PM, Varka Bhadram wrote: On 07/22/2014 04:40 PM, YoungJun Cho wrote: Hi Varka, This irq handler should be registered in attach() and unregistered in detach(). The devm_* APIs are released(freed) in remove(), right? Logically the panel could be attached and detached several times after dsi is probed and not removed. So I don't use devm_* APIs. You meant to say that in-case of GPIOs also you are following the same thing ..? Means requesting the GPIOs and Releasing several times ..? Yes, this TE gpio is came from panel. So it should be refresh whenever a (new) panel is attached. In this case it would be fine. Thanks for the clarity. -- Regards, Varka Bhadram. -- 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: adc: exynos_adc: Add support for S3C24xx ADC
On Tuesday 22 July 2014 11:11:14 Chanwoo Choi wrote: 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 While looking at the driver again to see if the touchscreen patch needs an update for this, I noticed that the s3c24xx variants don't have the ADC_V1_INTCLR and ADC_V1_CLRINTPNDNUP registers, so I assume your patch will have to be updated not to acknowledge the interrupts. It's possible that writing to the missing registers is harmless though and that you don't need that change. 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
[PATCH v2] iio: exynos-adc: add experimental touchscreen support
This adds support for the touchscreen on Samsung s3c64xx.
The driver is completely untested but shows roughly how
it could be done, following the example of the at91 driver.
Open questions include:
- compared to the old plat-samsung/adc driver, there is
no support for prioritizing ts over other clients, nor
for oversampling. From my reading of the code, the
priorities didn't actually have any effect at all, but
the oversampling might be needed. Maybe the original
authors have some insight.
- We probably need to add support for platform_data as well,
I've skipped this so far.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This should address all previous comments, and I've also added
a write to ADC_V1_DLY() as the old driver does.
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index cad81b666a67..ba30836c73cb 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -43,6 +43,10 @@ Required properties:
and compatible ADC block)
- vdd-supply VDD input supply.
+Optional properties:
+- has-touchscreen: If present, indicates that a touchscreen is
+ connected an usable.
+
Note: child nodes can be added for auto probing from device tree.
Example: adding device info in dtsi file
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 420c5cda09c3..3b684a117b9c 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
#include linux/iio/iio.h
#include linux/iio/machine.h
@@ -66,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)
@@ -103,24 +107,32 @@
/* Bit definitions common for ADC_V1 and ADC_V2 */
#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))
struct exynos_adc {
struct exynos_adc_data *data;
struct device *dev;
+ struct input_dev*input;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
struct clk *sclk;
unsigned intirq;
+ unsigned inttsirq;
struct regulator*vdd;
struct completion completion;
u32 value;
unsigned intversion;
+
+ boolread_ts;
+ u32 ts_x;
+ u32 ts_y;
};
struct exynos_adc_data {
@@ -205,6 +217,9 @@ static void exynos_adc_v1_init_hw(struct exynos_adc *info)
/* Enable 12-bit ADC resolution */
con1 |= ADC_V1_CON_RES;
writel(con1, ADC_V1_CON(info-regs));
+
+ /* set default touchscreen delay */
+ writel(1, ADC_V1_DLY(info-regs));
}
static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
@@ -390,12 +405,54 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return ret;
}
+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;
+
+ mutex_lock(indio_dev-mlock);
+ info-read_ts = true;
+
+ 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, ADC_S3C2410_MUX_TS);
+
+ 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 {
+ *x = info-ts_x;
+ *y = info-ts_y;
+ ret = 0;
+ }
+
+ info-read_ts = false;
+ mutex_unlock(indio_dev-mlock);
+
+ return ret;
+}
+
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
{
struct exynos_adc *info = (struct exynos_adc *)dev_id;
/* Read value */
- info-value = readl(ADC_V1_DATX(info-regs)) ADC_DATX_MASK;
+ if (info-read_ts) {
+ info-ts_x = readl(ADC_V1_DATX(info-regs));
+ info-ts_y = readl(ADC_V1_DATY(info-regs));
Re: [PATCH 00/12] drm/exynos/ipp: image post processing improvements, part three
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. Applied. 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 00/14] drm/exynos: support LCD I80 interface display
On 2014년 07월 17일 18:01, YoungJun Cho wrote: Hi, This series adds LCD I80 interface display support for Exynos DRM driver. The FIMD(display controller) specification describes it as LCD I80 interface and the DSI specification describes it as Command mode interface. This is based on exynos-drm-next branch. The previous patches, RFC: http://www.spinics.net/lists/dri-devel/msg58898.html V1: http://www.spinics.net/lists/dri-devel/msg59291.html V2: http://www.spinics.net/lists/dri-devel/msg59867.html V3: http://www.spinics.net/lists/dri-devel/msg60708.html V4: http://www.spinics.net/lists/dri-devel/msg60943.html V5: http://www.spinics.net/lists/dri-devel/msg62956.html Changelog v2: - Fixes typo and removes unnecessary error log. (commented by Andrzej Hazda) - Adds missed pendlig_flip flag clear points. (commented by Daniel Kurtz) Changelog v3: - Removes generic command mode and command mode display timing interface. - Moves I80 interface timings from panel DT to the FIMD(display controller) DT. Changelog v4: - Removes exynos5 sysreg(syscon) DT bindings and node from dtsi because it was already updated by linux-samsung-soc. (commented by Vivek Gautam) Changelog v5: - Fixes FIMD vidcon0 register relevant code. - Fixes panel gamma table, disable sequence. - Slitely updates for code cleanup. Changelog v6: - Removes pass TE host ops in dsi and exynos dsi uses TE irq handler instead, and it is related with the TE GPIO of panel. (commented by Thierry Reding) Patches 1 and 2 fix trivial bugs. Patches 3, 4, 5 and 6 implement FIMD(display controller) I80 interface. The MIPI DSI command mode based panel generates Tearing Effect synchronization signal between MCU and FB to display video image, and FIMD should trigger to transfer video image at this signal. So the panel generates it and the dsi should receive the TE IRQ and call TE handler chains to notify it to the FIMD. Patches 7 and 8 implement to use Exynos5410 / 5420 / 5440 SoC DSI driver which is different from previous Exynos4 SoCs for some registers control. Patches 9 and 10 introduce MIPI DSI command mode based Samsung S6E3FA0 AMOLED 5.7 LCD drm panel driver. The ohters add DT property nodes to support MIPI DSI command mode. I welcome any comments. Thank you. Best regards YJ YoungJun Cho (14): drm/exynos: dsi: move the EoT packets configuration point drm/exynos: use wait_event_timeout() for safety usage ARM: dts: samsung-fimd: add LCD I80 interface specific properties drm/exynos: add TE handler to support LCD I80 interface drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface drm/exynos: fimd: support LCD I80 interface ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs ARM: dts: s6e3fa0: add DT bindings drm/panel: add S6E3FA0 driver ARM: dts: exynos4: add system register property ARM: dts: exynos5: add system register property ARM: dts: exynos5420: add mipi-phy node ARM: dts: exynos5420: add dsi node Piked them up except patch 9 and 10. The two patches are needed for more review and consensus Thanks, Inki Dae .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 46 ++ .../devicetree/bindings/video/exynos_dsim.txt | 4 +- .../devicetree/bindings/video/samsung-fimd.txt | 28 ++ arch/arm/boot/dts/exynos4.dtsi | 1 + arch/arm/boot/dts/exynos5.dtsi | 1 + arch/arm/boot/dts/exynos5420.dtsi | 20 + drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 +- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 + drivers/gpu/drm/exynos/exynos_drm_drv.h| 3 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 266 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 276 +-- drivers/gpu/drm/panel/Kconfig | 7 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-s6e3fa0.c | 541 + include/video/samsung_fimd.h | 3 +- 16 files changed, 1146 insertions(+), 74 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c -- 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] iio: exynos-adc: add experimental touchscreen support
On Tuesday 22 July 2014 06:33 PM, Arnd Bergmann wrote:
(...)
+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;
+
+ mutex_lock(indio_dev-mlock);
+ info-read_ts = true;
+
+ 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, ADC_S3C2410_MUX_TS);
+
+ timeout = wait_for_completion_timeout
+ (info-completion, EXYNOS_ADC_TIMEOUT);
Should be properly aligned:
wait_for_completion_timeout(info-completion,
EXYNOS_ADC_TIMEOUT);
--
Regards,
Varka Bhadram
--
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/22/2014 12:59 PM, Kukjin Kim wrote: Daniel Lezcano wrote: 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. Olof, you're right. The branch has no dependency with arm-soc so I agreed. Yes, that's right. Furthermore I have been discussing with Doug about these patches before. Kukjin, is there any dependency on these patches ? Yeah, Daniel, it should be handled in the clocksource tree so how should I do for it? I can pull your branch v3.17-next/mct-exynos and you drop the merge from this branch in your master ? -- 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] iio: exynos-adc: add experimental touchscreen support
On Tue, Jul 22, 2014 at 03:03:12PM +0200, Arnd Bergmann wrote:
This adds support for the touchscreen on Samsung s3c64xx.
The driver is completely untested but shows roughly how
it could be done, following the example of the at91 driver.
Open questions include:
- compared to the old plat-samsung/adc driver, there is
no support for prioritizing ts over other clients, nor
for oversampling. From my reading of the code, the
priorities didn't actually have any effect at all, but
the oversampling might be needed. Maybe the original
authors have some insight.
- We probably need to add support for platform_data as well,
I've skipped this so far.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This should address all previous comments, and I've also added
a write to ADC_V1_DLY() as the old driver does.
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index cad81b666a67..ba30836c73cb 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -43,6 +43,10 @@ Required properties:
and compatible ADC block)
- vdd-supply VDD input supply.
+Optional properties:
+- has-touchscreen: If present, indicates that a touchscreen is
+ connected an usable.
+
Note: child nodes can be added for auto probing from device tree.
Example: adding device info in dtsi file
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 420c5cda09c3..3b684a117b9c 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
#include linux/iio/iio.h
#include linux/iio/machine.h
@@ -66,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)
@@ -103,24 +107,32 @@
/* Bit definitions common for ADC_V1 and ADC_V2 */
#define ADC_CON_EN_START (1u 0)
+#define ADC_DATX_PRESSED (1u 15)
#define ADC_DATX_MASK0xFFF
+#define ADC_DATY_MASK0xFFF
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
struct exynos_adc {
struct exynos_adc_data *data;
struct device *dev;
+ struct input_dev*input;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
struct clk *sclk;
unsigned intirq;
+ unsigned inttsirq;
struct regulator*vdd;
struct completion completion;
u32 value;
unsigned intversion;
+
+ boolread_ts;
+ u32 ts_x;
+ u32 ts_y;
};
struct exynos_adc_data {
@@ -205,6 +217,9 @@ static void exynos_adc_v1_init_hw(struct exynos_adc *info)
/* Enable 12-bit ADC resolution */
con1 |= ADC_V1_CON_RES;
writel(con1, ADC_V1_CON(info-regs));
+
+ /* set default touchscreen delay */
+ writel(1, ADC_V1_DLY(info-regs));
}
static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
@@ -390,12 +405,54 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return ret;
}
+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;
+
+ mutex_lock(indio_dev-mlock);
+ info-read_ts = true;
+
+ 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, ADC_S3C2410_MUX_TS);
+
+ 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 {
+ *x = info-ts_x;
+ *y = info-ts_y;
+ ret = 0;
+ }
+
+ info-read_ts = false;
+ mutex_unlock(indio_dev-mlock);
+
+ return ret;
+}
+
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
{
struct exynos_adc *info = (struct exynos_adc *)dev_id;
/* Read value */
- info-value = readl(ADC_V1_DATX(info-regs)) ADC_DATX_MASK;
+ if (info-read_ts) {
Re: [PATCH v2] iio: exynos-adc: add experimental touchscreen support
On Tuesday 22 July 2014 11:09:04 Dmitry Torokhov wrote: @@ -565,6 +722,15 @@ static int exynos_adc_probe(struct platform_device *pdev) if (info-data-init_hw) info-data-init_hw(info); + /* leave out any TS related code if unreachable */ + if (IS_BUILTIN(CONFIG_INPUT) || + (IS_MODULE(CONFIG_INPUT) config_enabled(MODULE))) This is ugly... We need IS_SUBSYSTEM_AVAILABLE() wrapper for this... Anyway, Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com I actually have a patch to introduce IS_REACHABLE() for this purpose, but I haven't sent it out for review yet. The main user of this would be drivers/media, which had the correct logic earlier until someone tried to simplify it by replacing it all with IS_ENABLED()... 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 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
Hello Yuvaraj,
On Sat, Jun 28, 2014 at 12:47 AM, Doug Anderson diand...@chromium.org wrote:
On Fri, Jun 27, 2014 at 3:59 AM, Yuvaraj Kumar yuvaraj...@gmail.com wrote:
mmc_regulator_set_ocr() is failing as its a fixed-regulator.
Can you explain more about what's failing? It sure looks like mmc
core is supposed to handle this given comments below
/*
* If we're using a fixed/static regulator, don't call
* regulator_set_voltage; it would fail.
*/
tps65090 driver does not register through fixed regulator framework.It
uses normal regulator framework and supports only
enable/disable/is_enabled callbacks.Also it lacks certain callbacks
for list_voltage, get_voltage ,set_voltage etc.
[2.306476] dwmmc_exynos 1222.mmc: Failed getting OCR mask: -22
[2.393403] dwmmc_exynos 1222.mmc: could not set regulator OCR (-22)
For the above reason,regulator framework treats fet4 as unused
regulator and disables the vmmc regulator.
Ah. Perhaps tps65090 needs to be fixed then... I'm not sure any
other drivers cared before so maybe that's why it was never caught?
I've been looking at this and as Doug and you said it seems that
nobody cared and since the tps65090 fets are actually just load
switches the driver only implementes the .enable and .disable
functions handlers. Also since their output voltage is just equal to
their input supply, that information was not present neither in the
driver nor in the Device Tree.
But when fet4 is used as the vmmc-supply phandle,
mmc_regulator_get_supply() calls mmc_regulator_get_ocrmask() [0] which
expects to fetch the regulator voltage count and current voltage as
you had explained so the function was failing.
Now I don't think that the driver needs to implement the
{get,set,list}_voltage callbacks. If a tps65090 regulator has both
regulator-min-microvolt and regulator-max-microvolt properties from
the generic regulator DT binding, and the value is the same, it can be
assumed that the regulator is fixed and the fixed_uV field can be set
to the output voltage and n_voltages to 1. That's everything that the
regulator core needs from a fixed regulator in order to make
regulator_get_voltage() to succeed:
static int _regulator_get_voltage(struct regulator_dev *rdev)
{
...
if (rdev-desc-ops-get_voltage_sel) {
sel = rdev-desc-ops-get_voltage_sel(rdev);
if (sel 0)
return sel;
ret = rdev-desc-ops-list_voltage(rdev, sel);
} else if (rdev-desc-ops-get_voltage) {
ret = rdev-desc-ops-get_voltage(rdev);
} else if (rdev-desc-ops-list_voltage) {
ret = rdev-desc-ops-list_voltage(rdev, 0);
} else if (rdev-desc-fixed_uV (rdev-desc-n_voltages == 1)) {
ret = rdev-desc-fixed_uV;
} else {
return -EINVAL;
}
...
}
What do you think about patch [1]?
So, with that patch mmc_regulator_get_supply() does not fail anymore
and also does not break DT backward compatibility since it only has
effect on the regulators that define their min and max voltage and not
in the ones that don't like is the case in old DTB.
Now, it is an RFC since I don't know if this is the correct solution.
Even though I've seen that min == max seems to imply that the
regulator is fixed, I wonder if is better to have an explicit generic
DT property (regulator-fixed-microvolt?) that is used to set fixed_uV
in of_get_regulation_constraints(). Since this seems to be a general
problem and not only related to the tps65090 device or the Peach
Pit/Pi use case. If you agree that it's a good solution then I can
post it as a proper patch.
I've also pushed this patch and the ones adding the needed DTS bits
for Peach Pit and Pi DTS to my personal repository so you can test it.
The branch is:
http://cgit.collabora.com/git/user/javier/linux.git/log/?h=tps65090-fixes
You also need to replace regulator_enable(mmc-supply.vmmc) and
regulator_disable(mmc-supply.vmmc) by mmc_regulator_set_ocr(mmc,
mmc-supply.vmmc, ios-vdd) and mmc_regulator_set_ocr(mmc,
mmc-supply.vmmc, 0) respectively in your original patch.
Best regards,
Javier
[0]: http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L1215
[1]:
From 3d2e6079cc8c372da946d430d43d36af99e7a582 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Tue, 22 Jul 2014 19:16:47 +0200
Subject: [RFC] regulator: tps65090: Allow regulators voltage to be
queried
The tps65090 device has some regulators with a fixed output
voltage and others with an adjustable output voltage. But the
regulators with adjustable output just provide the voltage of
their input supply so they really are fixed regulators within
a supported voltage range that depends on their input voltage.
That is why the driver only provides an .enable and .disable
function handlers and not a .{get,set,list}_voltage handlers.
But there is code in the kernel that expects to query the
output voltage for all regulators. For example the function
mmc_regulator_get_ocrmask() is executed
Re: [GIT PULL 4/5] Samsung exynos_mct update for v3.17
On 07/23/14 02:32, Daniel Lezcano wrote: On 07/22/2014 12:59 PM, Kukjin Kim wrote: Daniel Lezcano wrote: 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. Olof, you're right. The branch has no dependency with arm-soc so I agreed. Yes, that's right. Furthermore I have been discussing with Doug about these patches before. Kukjin, is there any dependency on these patches ? Yeah, Daniel, it should be handled in the clocksource tree so how should I do for it? I can pull your branch v3.17-next/mct-exynos and you drop the merge from this branch in your master ? Yes please and I did drop the merge in my -next just now. Thanks, Kukjin -- 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/3] ARM: exynos: remove unused mach/memory.h
On 07/23/14 01:14, Olof Johansson wrote: On Tue, Jul 22, 2014 at 12:51 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: Hello, who takes care of this series? In fact they are all orthogonal to each other. The first patch ARM: exynos: remove unusedmach/memory.h has been reviewed and tested by Tomasz Figa and Sachin Kamat. Can the Samsung people pick it up? Or armsoc? Kukjin should apply this one. Oh, thanks for gentle reminder and I've applied into 2nd cleanup. Thanks, Kukjin Patch 2 (v2!) ARM: remove remaining definitions of PLAT_PHYS_OFFSET frommach/memory.h touches several arch/arm/mach-*/include/mach/memory.h and arch/arm/Kconfig. armsoc? Russell? This can go through either, but Russell has already reviewed it once so send it to his patch tracker. Patch 3 fixes a warning regarding nommu and touches the Kconfig entry for Integrator and Renesas (non-multiplatform). armsoc? Don't know without seeing the patch. What's the patch subject so I can find it? -- 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] media: s5p_mfc: remove unnecessary calling to function video_devdata()
Since we have get vdev by calling video_devdata() at the beginning of s5p_mfc_open(), we should just use vdev instead of calling video_devdata() again in the following code. Change-Id: I869051762d33b50a7c0dbc8149b072e70b89c6b9 Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index d57b306..d508cbc 100755 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -709,7 +709,7 @@ static int s5p_mfc_open(struct file *file) ret = -ENOMEM; goto err_alloc; } - v4l2_fh_init(ctx-fh, video_devdata(file)); + v4l2_fh_init(ctx-fh, vdev); file-private_data = ctx-fh; v4l2_fh_add(ctx-fh); ctx-dev = dev; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: s5p_mfc: Check the right pointer after allocation
It should be bank2_virt to be checked after dma allocation
instead of dev-fw_virt_addr.
Change-Id: I03ed5603de3ef1d97bf76d7d42097d9489b6b003
Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index dc1fc94..55ad881 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -50,7 +50,7 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
bank2_virt = dma_alloc_coherent(dev-mem_dev_r, 1
MFC_BASE_ALIGN_ORDER,
bank2_dma_addr, GFP_KERNEL);
- if (IS_ERR(dev-fw_virt_addr)) {
+ if (IS_ERR(bank2_virt)) {
mfc_err(Allocating bank2 base failed\n);
dma_free_coherent(dev-mem_dev_l, dev-fw_size,
dev-fw_virt_addr, dev-bank1);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
Dear Jonathan, Could you please pick this patchset for 3.17? Best Regards, Chanwoo Choi On 07/22/2014 11:04 AM, Chanwoo Choi wrote: 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(-) -- 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] media: s5p_mfc: remove unnecessary calling to function video_devdata()
Hi Zhaowei, On 07/23/2014 09:49 AM, Zhaowei Yuan wrote: Since we have get vdev by calling video_devdata() at the beginning of s5p_mfc_open(), we should just use vdev instead of calling video_devdata() again in the following code. Change-Id: I869051762d33b50a7c0dbc8149b072e70b89c6b9 Please don't put this in patch when you submit at upstream. Change-Id means nothing to us. Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index d57b306..d508cbc 100755 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -709,7 +709,7 @@ static int s5p_mfc_open(struct file *file) ret = -ENOMEM; goto err_alloc; } - v4l2_fh_init(ctx-fh, video_devdata(file)); + v4l2_fh_init(ctx-fh, vdev); file-private_data = ctx-fh; v4l2_fh_add(ctx-fh); ctx-dev = dev; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media 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
[PATCH] media: s5p_mfc: Check the right pointer after allocation
It should be bank2_virt to be checked after dma allocation
instead of dev-fw_virt_addr.
Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index dc1fc94..55ad881 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -50,7 +50,7 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
bank2_virt = dma_alloc_coherent(dev-mem_dev_r, 1
MFC_BASE_ALIGN_ORDER,
bank2_dma_addr, GFP_KERNEL);
- if (IS_ERR(dev-fw_virt_addr)) {
+ if (IS_ERR(bank2_virt)) {
mfc_err(Allocating bank2 base failed\n);
dma_free_coherent(dev-mem_dev_l, dev-fw_size,
dev-fw_virt_addr, dev-bank1);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: s5p_mfc: remove unnecessary calling to function video_devdata()
Since we have get vdev by calling video_devdata() at the beginning of s5p_mfc_open(), we should just use vdev instead of calling video_devdata() again in the following code. Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index d57b306..d508cbc 100755 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -709,7 +709,7 @@ static int s5p_mfc_open(struct file *file) ret = -ENOMEM; goto err_alloc; } - v4l2_fh_init(ctx-fh, video_devdata(file)); + v4l2_fh_init(ctx-fh, vdev); file-private_data = ctx-fh; v4l2_fh_add(ctx-fh); ctx-dev = dev; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: tests: Providing cpufreq regression test
Hi Lukasz, I haven't replied yet as I wanted to see what the general feed of Rafael is going to be :) As this is something new and wasn't sure if we really want this.. On 21 July 2014 12:32, Lukasz Majewski l.majew...@samsung.com wrote: This commit adds first regression test cpufreq_freq_test.sh for the cpufreq subsystem. That's not enough, Tell us why we should continue reading this mail.. Signed-off-by: Lukasz Majewski l.majew...@samsung.com --- Changes for v2: - Replace *_PATCH with *_PATH for variables names - Corrected mistakes in the README file - Providing detailed explanation of the patch in the README file --- drivers/cpufreq/tests/README | 33 +++ drivers/cpufreq/tests/cpufreq_freq_test.sh | 149 + Probably a better place would be tools/power/cpufreq/ @Rafael? 2 files changed, 182 insertions(+) create mode 100644 drivers/cpufreq/tests/README create mode 100755 drivers/cpufreq/tests/cpufreq_freq_test.sh diff --git a/drivers/cpufreq/tests/README b/drivers/cpufreq/tests/README new file mode 100644 index 000..3e9cd80 --- /dev/null +++ b/drivers/cpufreq/tests/README @@ -0,0 +1,33 @@ +This file contains list of cpufreq's available regression tests with a short +usage description. + +1. cpufreq_freq_test.sh + +Description: + +This script is supposed to test if cpufreq attributes exported by sysfs are +exposing correct values. + +To achieve this goal it saves the current governor and changes it to +performance. Afterwards, it reads the scaling_available_frequencies +property. With the list of supported frequencies it is able to enforce each of +them by writing to scaling_max_freq attribute. To make the test more reliable +a superfluous load with gzip is created to be sure that we are running with +highest possible frequency. This high load is regulated with the 'sleep' +duration. After this time the cpufreq_cur_freq is read and compared with the +original value. As the last step the original governor is restored. I couldn't make out the purpose of this test and why we need it. How do we ensure that cpufreq attributes exported by sysfs are exposing correct values? And actually what do we mean by this statement even? What kind of errors can be there in exposing these values. I want to understand the purpose of this script very clearly first and then only will look at the details. -- 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
