Re: [RFC PATCH 0/4] Common Display Framework-TF
On 2013-02-08 16:54, Marcus Lorentzon wrote: On 02/08/2013 03:02 PM, Tomi Valkeinen wrote: On 2013-02-08 15:28, Marcus Lorentzon wrote: When we do that we stop-setup-start during blanking. So our DSS is optimized to be able to do that without getting blocked. All DSI video mode panels (and DPI) products we have done so far have not had any issue with that (as long as DSI HS clock is set to continuous). I think this approach is less platform dependant, as long as there is no SoC that take more than a blanking period to reconfigure. So do you stop, setup and start the link with CPU, and this has to be happen during blanking? Isn't that prone to errors? Or did you mean that the hardware handles that automatically? In OMAP DSS there are so called shadow registers, that can be programmed at any time. The you set a bit (GO bit), which tells the hardware to take the new settings into use at the next vblank. From DSI driver's perspective the link is never stopped when reconfiguring the video timings. However, many other settings have to be configured when the link is disabled. Yeah, you lucky guys with the GO bit ;). No, we actually do CPU stop,setup,start. But since it is video mode, master is driving the sync so it is not a hard deadline. It is enough to restart before pixels start to degrade. On an LCD that is not so much time, but on an OLED it could be 10 secs :). Anyway, we have had several mass products with this soft solution and it has worked well. Ah, ok. But in that case what you said in an earlier mail is not quite correct: I think this approach is less platform dependant, as long as there is no SoC that take more than a blanking period to reconfigure.. So in your approach the reconfiguration doesn't have to be done inside the blanking period, but before the panel's picture starts to fade? I don't know... It's early Monday morning, and not enough coffee yet, but I get a bit uneasy feeling if I think that your method of reconfiguring would be the only think allowed by the CDF API. Some SoCs do support reconfiguring on the fly, without disabling the link. It would not be nice if we didn't allow this to happen. And actually, we're not only talking about SoCs here, but also any display devices, like external buffer chips etc. They may also offer means to change configs on the fly. Well, I don't have any hard point about this at the moment, but I think we should think different approaches how the configuration can be done. I understand, but removing the omap prefix doesn't mean it has to go in the panel slave port/bus settings. I still can't see why this should be configuration on the panel driver and not the DSI master driver. Number of pins might be useful since you might start with one lane and then activate the rest. But partial muxing (pre pinmux) doesn't seem to be something the panel should control or know anything about. Sounds like normal platform/DT data per product/board. I think one case where this kind of pin configuration is needed, and which also dictates that all panel related configuration has to be in the panel's data, not in the DSI master's data, is hotplug. If you have a board that has two panels connected to the same video output, probably via some kind of mux, at least for the sensitive pins like DSI, only one of the panels can be enabled at a time. The panels can have different wiring, and thus the panel driver would need to configure everything related to the bus when it's starting up. The same also happens if you have a true hotplug, i.e. you can remove the panel totally and plug in a new one. Again the wiring can be different, and needs to be set up. And, as I said, this means that all relevant data about the video bus has to be in the panel's data, so that each panel can have its own set of, say, pin configuration. Hotplug is not a use case we should aim to support for the CDF v1, but I think we should strive not to prevent hotplug either. So if we can design the API so that hotplug is possible, I say let's do that. Tomi signature.asc Description: OpenPGP digital signature
[PATCH V4 0/5] Add generic DMA DT binding support
Changes since V3: - Make dma-cells property optional as suggested by Rob Herring - Add dma-requests and dma-channels properties to DMA controller as suggested by Arnd for future-proof - Add Acked-by for some of the patches Changes since V2: - Add new filter function for DT case as suggested by Arnd - Add xlate as static function - Use newly added filter function in xlate. - Add Acked-by for some of the patches Changes since V1: - Address the review comments by Arnd Bergmann as below - Wording of the properties. - Pass pdmac as third parameter to of_dma_controller_register - Filter the dma channel based on channel number and dma_device This patch set adds support for generic dma device tree bindings for Samsung platforms and is dependent on the following patches from Vinod Koul next branch 1)of: Add generic device tree DMA helpers 2)dmaengine: add helper function to request a slave DMA channel This patch set is made based Mark Brown next branch Padmavathi Venna (5): DMA: PL330: Add new pl330 filter for DT case. DMA: PL330: Add xlate function DMA: PL330: Register the DMA controller with the generic DMA helpers ARM: dts: pl330: Add #dma-cells for generic dma binding support ARM: SAMSUNG: dma: Remove unnecessary code .../devicetree/bindings/dma/arm-pl330.txt | 21 +-- arch/arm/boot/dts/exynos5250.dtsi | 12 arch/arm/mach-s3c24xx/include/mach/dma.h |1 - arch/arm/mach-s3c64xx/include/mach/dma.h |1 - arch/arm/plat-samsung/dma-ops.c| 10 +--- arch/arm/plat-samsung/include/plat/dma-ops.h |1 - arch/arm/plat-samsung/include/plat/dma-pl330.h |1 - drivers/dma/pl330.c| 64 +++ 8 files changed, 79 insertions(+), 32 deletions(-) -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 1/5] DMA: PL330: Add new pl330 filter for DT case.
This patch adds a new pl330_dt_filter for DT case to filter the
required channel based on the new filter params and modifies the
old filter only for non-DT case as suggested by Arnd Bergmann.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/dma/pl330.c | 29 +++--
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 80680ee..87110f2 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -606,6 +606,11 @@ struct dma_pl330_desc {
struct dma_pl330_chan *pchan;
};
+struct dma_pl330_filter_args {
+ struct dma_pl330_dmac *pdmac;
+ unsigned int chan_id;
+};
+
static inline void _callback(struct pl330_req *r, enum pl330_op_err err)
{
if (r r-xfer_cb)
@@ -2352,6 +2357,16 @@ static void dma_pl330_rqcb(void *token, enum
pl330_op_err err)
tasklet_schedule(pch-task);
}
+static bool pl330_dt_filter(struct dma_chan *chan, void *param)
+{
+ struct dma_pl330_filter_args *fargs = param;
+
+ if (chan-device != fargs-pdmac-ddma)
+ return false;
+
+ return (chan-chan_id == fargs-chan_id);
+}
+
bool pl330_filter(struct dma_chan *chan, void *param)
{
u8 *peri_id;
@@ -2359,20 +2374,6 @@ bool pl330_filter(struct dma_chan *chan, void *param)
if (chan-device-dev-driver != pl330_driver.drv)
return false;
-#ifdef CONFIG_OF
- if (chan-device-dev-of_node) {
- const __be32 *prop_value;
- phandle phandle;
- struct device_node *node;
-
- prop_value = ((struct property *)param)-value;
- phandle = be32_to_cpup(prop_value++);
- node = of_find_node_by_phandle(phandle);
- return ((chan-private == node)
- (chan-chan_id == be32_to_cpup(prop_value)));
- }
-#endif
-
peri_id = chan-private;
return *peri_id == (unsigned)param;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 2/5] DMA: PL330: Add xlate function
Add xlate to translate the device-tree binding information into
the appropriate format. The filter function requires the dma
controller device and dma channel number as filter_params.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/dma/pl330.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 87110f2..e68c83b 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -25,6 +25,7 @@
#include linux/amba/pl330.h
#include linux/scatterlist.h
#include linux/of.h
+#include linux/of_dma.h
#include dmaengine.h
#define PL330_MAX_CHAN 8
@@ -2379,6 +2380,30 @@ bool pl330_filter(struct dma_chan *chan, void *param)
}
EXPORT_SYMBOL(pl330_filter);
+static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ int count = dma_spec-args_count;
+ struct dma_pl330_dmac *pdmac = ofdma-of_dma_data;
+ struct dma_pl330_filter_args fargs;
+ dma_cap_mask_t cap;
+
+ if (!pdmac)
+ return NULL;
+
+ if (count != 1)
+ return NULL;
+
+ fargs.pdmac = pdmac;
+ fargs.chan_id = dma_spec-args[0];
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+ dma_cap_set(DMA_CYCLIC, cap);
+
+ return dma_request_channel(cap, pl330_dt_filter, fargs);
+}
+
static int pl330_alloc_chan_resources(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 3/5] DMA: PL330: Register the DMA controller with the generic DMA helpers
This patch registers the pl330 dma controller driver with the generic
device tree dma helper functions.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/dma/pl330.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index e68c83b..3fca247 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2999,6 +2999,14 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pi-pcfg.data_bus_width / 8, pi-pcfg.num_chan,
pi-pcfg.num_peri, pi-pcfg.num_events);
+ ret = of_dma_controller_register(adev-dev.of_node,
+of_dma_pl330_xlate, pdmac);
+ if (ret) {
+ dev_err(adev-dev,
+ unable to register DMA to the generic DT DMA helpers\n);
+ goto probe_err2;
+ }
+
return 0;
probe_err4:
@@ -3025,6 +3033,8 @@ static int pl330_remove(struct amba_device *adev)
if (!pdmac)
return 0;
+ of_dma_controller_free(adev-dev.of_node);
+
amba_set_drvdata(adev, NULL);
/* Idle the DMAC */
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 4/5] ARM: dts: pl330: Add #dma-cells for generic dma binding support
This patch adds #dma-cells property to PL330 DMA controller
nodes for supporting generic dma dt bindings on samsung
exynos5250 platform.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/dma/arm-pl330.txt | 21 +++
arch/arm/boot/dts/exynos5250.dtsi | 12 +++
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
index 36e27d5..2675658 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -10,7 +10,11 @@ Required properties:
- interrupts: interrupt number to the cpu.
Optional properties:
-- dma-coherent : Present if dma operations are coherent
+ - dma-coherent : Present if dma operations are coherent
+ - #dma-cells: must be 1. used to represent the number of integer
+cells in the dmas property of client device.
+ - dma-channels: contains the total number of DMA channels supported by the
DMAC
+ - dma-requests: contains the total number of DMA requests supported by the
DMAC
Example:
@@ -18,16 +22,23 @@ Example:
compatible = arm,pl330, arm,primecell;
reg = 0x1268 0x1000;
interrupts = 99;
+ #dma-cells = 1;
+ #dma-channels = 8;
+ #dma-requests = 32;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
-mem-to-dev) should specify the DMA channel numbers using a two-value pair
+mem-to-dev) should specify the DMA channel numbers and dma channel names
as shown below.
[property name] = [phandle of the dma controller] [dma request id];
+ [property name] = [dma channel name]
where 'dma request id' is the dma request number which is connected
- to the client controller. The 'property name' is recommended to be
- of the form name-dma-channel.
+ to the client controller. The 'property name' 'dmas' and 'dma-names'
+ as required by the generic dma device tree binding helpers. The dma
+ names correspond 1:1 with the dma request ids in the dmas property.
- Example: tx-dma-channel = pdma0 12;
+ Example: dmas = pdma0 12
+ pdma1 11;
+ dma-names = tx, rx;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index f50b4e8..b1ac73e 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -312,24 +312,36 @@
compatible = arm,pl330, arm,primecell;
reg = 0x121A 0x1000;
interrupts = 0 34 0;
+ #dma-cells = 1;
+ #dma-channels = 8;
+ #dma-requests = 32;
};
pdma1: pdma@121B {
compatible = arm,pl330, arm,primecell;
reg = 0x121B 0x1000;
interrupts = 0 35 0;
+ #dma-cells = 1;
+ #dma-channels = 8;
+ #dma-requests = 32;
};
mdma0: mdma@1080 {
compatible = arm,pl330, arm,primecell;
reg = 0x1080 0x1000;
interrupts = 0 33 0;
+ #dma-cells = 1;
+ #dma-channels = 8;
+ #dma-requests = 1;
};
mdma1: mdma@11C1 {
compatible = arm,pl330, arm,primecell;
reg = 0x11C1 0x1000;
interrupts = 0 124 0;
+ #dma-cells = 1;
+ #dma-channels = 8;
+ #dma-requests = 1;
};
};
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 5/5] ARM: SAMSUNG: dma: Remove unnecessary code
This patch removes the usage of DMACH_DT_PROP and dt_dmach_prop
from dma code as the new generic dma dt binding support has been
added.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
---
arch/arm/mach-s3c24xx/include/mach/dma.h |1 -
arch/arm/mach-s3c64xx/include/mach/dma.h |1 -
arch/arm/plat-samsung/dma-ops.c| 10 +-
arch/arm/plat-samsung/include/plat/dma-ops.h |1 -
arch/arm/plat-samsung/include/plat/dma-pl330.h |1 -
5 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/include/mach/dma.h
b/arch/arm/mach-s3c24xx/include/mach/dma.h
index 6b72d5a..b55da1d 100644
--- a/arch/arm/mach-s3c24xx/include/mach/dma.h
+++ b/arch/arm/mach-s3c24xx/include/mach/dma.h
@@ -24,7 +24,6 @@
*/
enum dma_ch {
- DMACH_DT_PROP = -1, /* not yet supported, do not use */
DMACH_XD0 = 0,
DMACH_XD1,
DMACH_SDI,
diff --git a/arch/arm/mach-s3c64xx/include/mach/dma.h
b/arch/arm/mach-s3c64xx/include/mach/dma.h
index 57b1ff4..fe1a98c 100644
--- a/arch/arm/mach-s3c64xx/include/mach/dma.h
+++ b/arch/arm/mach-s3c64xx/include/mach/dma.h
@@ -21,7 +21,6 @@
*/
enum dma_ch {
/* DMA0/SDMA0 */
- DMACH_DT_PROP = -1, /* not yet supported, do not use */
DMACH_UART0 = 0,
DMACH_UART0_SRC2,
DMACH_UART1,
diff --git a/arch/arm/plat-samsung/dma-ops.c b/arch/arm/plat-samsung/dma-ops.c
index 71d58dd..ec0d731 100644
--- a/arch/arm/plat-samsung/dma-ops.c
+++ b/arch/arm/plat-samsung/dma-ops.c
@@ -23,23 +23,15 @@ static unsigned samsung_dmadev_request(enum dma_ch dma_ch,
struct device *dev, char *ch_name)
{
dma_cap_mask_t mask;
- void *filter_param;
dma_cap_zero(mask);
dma_cap_set(param-cap, mask);
- /*
-* If a dma channel property of a device node from device tree is
-* specified, use that as the fliter parameter.
-*/
- filter_param = (dma_ch == DMACH_DT_PROP) ?
- (void *)param-dt_dmach_prop : (void *)dma_ch;
-
if (dev-of_node)
return (unsigned)dma_request_slave_channel(dev, ch_name);
else
return (unsigned)dma_request_channel(mask, pl330_filter,
- filter_param);
+ (void *)dma_ch);
}
static int samsung_dmadev_release(unsigned ch, void *param)
diff --git a/arch/arm/plat-samsung/include/plat/dma-ops.h
b/arch/arm/plat-samsung/include/plat/dma-ops.h
index 1141782..ce6d763 100644
--- a/arch/arm/plat-samsung/include/plat/dma-ops.h
+++ b/arch/arm/plat-samsung/include/plat/dma-ops.h
@@ -18,7 +18,6 @@
struct samsung_dma_req {
enum dma_transaction_type cap;
- struct property *dt_dmach_prop;
struct s3c2410_dma_client *client;
};
diff --git a/arch/arm/plat-samsung/include/plat/dma-pl330.h
b/arch/arm/plat-samsung/include/plat/dma-pl330.h
index d384a80..abe07fa 100644
--- a/arch/arm/plat-samsung/include/plat/dma-pl330.h
+++ b/arch/arm/plat-samsung/include/plat/dma-pl330.h
@@ -21,7 +21,6 @@
* use these just as IDs.
*/
enum dma_ch {
- DMACH_DT_PROP = -1,
DMACH_UART0_RX = 0,
DMACH_UART0_TX,
DMACH_UART1_RX,
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] Common Display Framework-TF
On 02/11/2013 09:21 AM, Tomi Valkeinen wrote: On 2013-02-08 16:54, Marcus Lorentzon wrote: On 02/08/2013 03:02 PM, Tomi Valkeinen wrote: On 2013-02-08 15:28, Marcus Lorentzon wrote: When we do that we stop-setup-start during blanking. So our DSS is optimized to be able to do that without getting blocked. All DSI video mode panels (and DPI) products we have done so far have not had any issue with that (as long as DSI HS clock is set to continuous). I think this approach is less platform dependant, as long as there is no SoC that take more than a blanking period to reconfigure. So do you stop, setup and start the link with CPU, and this has to be happen during blanking? Isn't that prone to errors? Or did you mean that the hardware handles that automatically? In OMAP DSS there are so called shadow registers, that can be programmed at any time. The you set a bit (GO bit), which tells the hardware to take the new settings into use at the next vblank. From DSI driver's perspective the link is never stopped when reconfiguring the video timings. However, many other settings have to be configured when the link is disabled. Yeah, you lucky guys with the GO bit ;). No, we actually do CPU stop,setup,start. But since it is video mode, master is driving the sync so it is not a hard deadline. It is enough to restart before pixels start to degrade. On an LCD that is not so much time, but on an OLED it could be 10 secs :). Anyway, we have had several mass products with this soft solution and it has worked well. Ah, ok. But in that case what you said in an earlier mail is not quite correct: I think this approach is less platform dependant, as long as there is no SoC that take more than a blanking period to reconfigure.. So in your approach the reconfiguration doesn't have to be done inside the blanking period, but before the panel's picture starts to fade? I don't know... It's early Monday morning, and not enough coffee yet, but I get a bit uneasy feeling if I think that your method of reconfiguring would be the only think allowed by the CDF API. Some SoCs do support reconfiguring on the fly, without disabling the link. It would not be nice if we didn't allow this to happen. And actually, we're not only talking about SoCs here, but also any display devices, like external buffer chips etc. They may also offer means to change configs on the fly. Well, I don't have any hard point about this at the moment, but I think we should think different approaches how the configuration can be done. Ok, so what about a compromise which I think would work for both HWs ... we allow the configure operation during video on, then each HW driver could decide if this means you have to stop or not to do the changes required. But then it is also important that we keep all config in one struct and not split it up. Otherwise HW like ours that has so be stopped could need to stop once for each setting/operation called. So in short, allow configure(bus_params) during video on, keep all bus_params in the struct. It is in kernel struct so it can easily be changed/refactored. I understand, but removing the omap prefix doesn't mean it has to go in the panel slave port/bus settings. I still can't see why this should be configuration on the panel driver and not the DSI master driver. Number of pins might be useful since you might start with one lane and then activate the rest. But partial muxing (pre pinmux) doesn't seem to be something the panel should control or know anything about. Sounds like normal platform/DT data per product/board. I think one case where this kind of pin configuration is needed, and which also dictates that all panel related configuration has to be in the panel's data, not in the DSI master's data, is hotplug. If you have a board that has two panels connected to the same video output, probably via some kind of mux, at least for the sensitive pins like DSI, only one of the panels can be enabled at a time. The panels can have different wiring, and thus the panel driver would need to configure everything related to the bus when it's starting up. The same also happens if you have a true hotplug, i.e. you can remove the panel totally and plug in a new one. Again the wiring can be different, and needs to be set up. And, as I said, this means that all relevant data about the video bus has to be in the panel's data, so that each panel can have its own set of, say, pin configuration. Hotplug is not a use case we should aim to support for the CDF v1, but I think we should strive not to prevent hotplug either. So if we can design the API so that hotplug is possible, I say let's do that. Again, this probing and bus muxing is platform/bus specific and not panel specific. Any panel of that type will only ever work on Omap (or someone else implementing the same muxing features) as I see it. So why not just put that config on the bus master, dispc? I still can't see how this is panel config. You are only
[PATCH] ARM: dts: Correct the pin configuration for eMMC
This patch corrects the pin function value of sd4_bus8 from 3
to 4.
This is verified on origen board for testing eMMC on
dw_mci controller.
Signed-off-by: Shirish S s.shir...@samsung.com
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 8e6115a..099cec7 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -661,7 +661,7 @@
sd4_bus8: sd4-bus-width8 {
samsung,pins = gpk1-3, gpk1-4, gpk1-5, gpk1-6;
- samsung,pin-function = 3;
+ samsung,pin-function = 4;
samsung,pin-pud = 4;
samsung,pin-drv = 3;
};
--
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] ARM: dts: Correct the pin configuration for eMMC
Hi Shirish,
On Monday 11 of February 2013 05:01:28 Shirish S wrote:
This patch corrects the pin function value of sd4_bus8 from 3
to 4.
This is verified on origen board for testing eMMC on
dw_mci controller.
Signed-off-by: Shirish S s.shir...@samsung.com
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi index 8e6115a..099cec7
100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -661,7 +661,7 @@
sd4_bus8: sd4-bus-width8 {
samsung,pins = gpk1-3, gpk1-4, gpk1-5, gpk1-6;
- samsung,pin-function = 3;
+ samsung,pin-function = 4;
samsung,pin-pud = 4;
samsung,pin-drv = 3;
};
IMHO name of the patch is a bit misleading, as on many Exynos4x12-based
boards sdhci-s3c is used for eMMC. I think following would be better:
ARM: dts: exynos4x12-pinctrl: Correct pin configuration of SD 4
Best regards,
--
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: exynos4x12-pinctrl: Correct pin configuration of SD 4
This patch corrects the pin function value of sd4_bus8 from 3
to 4.
This is verified on origen board for testing eMMC on
dw_mci controller.
Signed-off-by: Shirish S s.shir...@samsung.com
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 8e6115a..099cec7 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -661,7 +661,7 @@
sd4_bus8: sd4-bus-width8 {
samsung,pins = gpk1-3, gpk1-4, gpk1-5, gpk1-6;
- samsung,pin-function = 3;
+ samsung,pin-function = 4;
samsung,pin-pud = 4;
samsung,pin-drv = 3;
};
--
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: Re: [PATCH] ARM: dts: Correct the pin configuration for eMMC
Done!
--- Original Message ---
Sender : Tomasz Figat.f...@samsung.com Junior Software Engineer/SRPOL-Linux
Platform (SSD)/Samsung Electronics
Date : Feb 11, 2013 15:20 (GMT+05:30)
Title : Re: [PATCH] ARM: dts: Correct the pin configuration for eMMC
Hi Shirish,
On Monday 11 of February 2013 05:01:28 Shirish S wrote:
This patch corrects the pin function value of sd4_bus8 from 3
to 4.
This is verified on origen board for testing eMMC on
dw_mci controller.
Signed-off-by: Shirish S s.shir...@samsung.com
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi index 8e6115a..099cec7
100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -661,7 +661,7 @@
sd4_bus8: sd4-bus-width8 {
samsung,pins = gpk1-3, gpk1-4, gpk1-5, gpk1-6;
- samsung,pin-function = 3;
+ samsung,pin-function = 4;
samsung,pin-pud = 4;
samsung,pin-drv = 3;
};
IMHO name of the patch is a bit misleading, as on many Exynos4x12-based
boards sdhci-s3c is used for eMMC. I think following would be better:
ARM: dts: exynos4x12-pinctrl: Correct pin configuration of SD 4
Best regards,
--
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform
pnbsp;/ppnbsp;/p
Re: [RFC PATCH 0/4] Common Display Framework-TF
On 2013-02-11 11:31, Marcus Lorentzon wrote: Ok, so what about a compromise which I think would work for both HWs ... we allow the configure operation during video on, then each HW driver could decide if this means you have to stop or not to do the changes required. But then it is also important that we keep all config in one struct and not split it up. Otherwise HW like ours that has so be stopped could need to stop once for each setting/operation called. So in short, allow configure(bus_params) during video on, keep all bus_params in the struct. It is in kernel struct so it can easily be changed/refactored. Right, we need some way to group the configuration parameters. Either one big struct, or something like start_config() and end_config(). I think we could also think what parameters make no sense to be configured on the fly, and possibly have those separately. Although it may be a bit difficult to think of all the (weird) use cases. Again, this probing and bus muxing is platform/bus specific and not panel specific. Any panel of that type will only ever work on Omap (or The parameters used for configuration itself is platform specific, and that's why it needs to be defined in the DT data. But the API itself is not platform specific. The parameters are information about how the panel is connected, just like, say, number of data lines is for DPI. Which is also something I think should be configured by the panel. someone else implementing the same muxing features) as I see it. So why No, it works for everyone. Well, at least I still don't see anything omap or platform specific in the API. Of course, if the platform/device doesn't support modifying the pin functions, then the function does nothing. not just put that config on the bus master, dispc? I still can't see how this is panel config. You are only pushing CDF API and meta data to describe something that is only needed by one bus master. I have never The information about how the panel is connected (the wiring) has to be somewhere in the DT data. We could have the info in the DSI master or in the DSI slave. Or, in some platforms where the DSS is not involved in the muxing/config, the info could be totally separate, in the boards pinmuxing data. I think all those work ok for normal cases without hotplug. But if you have hotplug, then you need separate pinmuxing/config data for each panel. You could possibly have a list of panels in your DSI master node, containing the muxing data, but that sounds rather hacky, and also very hardcoded, i.e. you need to know each panel that is ever going to be connected. If, on the other hand, you have the info in the panel node, it just works. When a new panel is connected, the relevant panel DT data comes from somewhere (it's not relevant where), and it tells the DSI master how it's connected. Something like this is probably needed for the BeagleBone capes, if you have happened to follow the discussion. Although it could be argued that the capes may perhaps be not runtime hotswappable, and thus the configuration can be done only once during boot after the cape has been probed. But I'd rather not design the API so that we prevent hot swapping. seen any DSI slave that can change their pin config. And since there is Well, if omap is the only SoC/device out there that supports configuring the pin functions, and everybody is against the API, I'm not going to press it. But then again, I think similar configuration support may be needed even for the normal pinmuxing, even in the case where you can't reconfigure the DSI pin functions. You still need to mux the pins (perhaps, say, between DSI and a GPIO), depending on how many lanes the panel uses. In fact, speaking about all pins in general, I'm not very fond of having a static pinmuxing in the board DT data, handled by the board setup code. I think generally the pins should be muxed to safe-mode by the board setup code, and then configured to their proper function by the driver when it is initializing. no generic hot plug detect of DSI panels, at least not before DSI bus is available, I have to assume this probing it very platform specific. We have some products that provide 1-2 gpios to specify what panel is available, some use I2C sensor probing to then assume the panel plugged. Yes, the hotplug mechanism is platform/board specific. But that's not relevant here. At least in the first step I don't think this type of hot plug should be in the API. Then once the base panel driver is in we could discuss different solutions for you hot plug scenario. Yes, as I said, I also think we shouldn't aim for hotplug in the v1. But we also shouldn't prevent it. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: exynos4x12-pinctrl: Correct pin configuration of SD 4
On Monday 11 of February 2013 05:21:13 Shirish S wrote:
This patch corrects the pin function value of sd4_bus8 from 3
to 4.
This is verified on origen board for testing eMMC on
dw_mci controller.
Signed-off-by: Shirish S s.shir...@samsung.com
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi index 8e6115a..099cec7
100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -661,7 +661,7 @@
sd4_bus8: sd4-bus-width8 {
samsung,pins = gpk1-3, gpk1-4, gpk1-5, gpk1-6;
- samsung,pin-function = 3;
+ samsung,pin-function = 4;
samsung,pin-pud = 4;
samsung,pin-drv = 3;
};
Reviewed-by: Tomasz Figa t.f...@samsung.com
Best regards,
--
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/09/2013 03:29 PM, Sylwester Nawrocki wrote: On 02/09/2013 01:32 AM, Stephen Warren wrote: On 02/08/2013 05:05 PM, Sylwester Nawrocki wrote: On 02/09/2013 12:21 AM, Stephen Warren wrote: On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: On 02/07/2013 12:40 AM, Stephen Warren wrote: diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC) +-- ... +For every fimc node a numbered alias should be present in the aliases node. +Aliases are of the form fimcn, wherenis an integer (0...N) specifying +the IP's instance index. ... Different compatible values might not work, when for example there are 3 IPs out of 4 of one type and the fourth one of another type. It wouldn't even by really different types, just quirks/little differences between them, e.g. no data path routed to one of other IPs. I was thinking of using feature-/quirk-oriented properties. For example, if there's a port on 3 of the 4 devices to connect to some other IP block, simply include a boolean property to indicate whether that port is present. It would be in 3 of the nodes but not the 4th. Yes, I could add several properties corresponding to all members of this [3] data structure. But still it is needed to clearly identify the IP block in a set of the hardware instances. Why? What decisions will be made based on the identify of the IP block instance that wouldn't be covered by DT properties that describe which features/bugs/... the IP block instance has? Then to connect e.g. MIPI-CSIS.0 to FIMC.2 at run time an index of the MIPI-CSIS needs to be written to the FIMC.2 data input control register. Even though MIPI-CSIS.N are same in terms of hardware structure they still need to be distinguished as separate instances. Oh, so you're using the alias ID as the value to write into the FIMC.2 register for that. I'm not 100% familiar with aliases, but they seem like a more user-oriented naming thing to me, whereas values for hooking up intra-SoC routing are an unrelated namespace semantically, even if the values happen to line up right now. Perhaps rather than a Boolean property I mentioned above, use a custom property to indicate the ID that the FIMC.2 object knows the MIPI-CSIS.0 object as? While this seems That could be 'reg' property in the MIPI-CSIS.0 'port' subnode that links it to the image sensor node ([4], line 165). Because MIPI-CSIS IP blocks are immutably connected to the SoC camera physical MIPI CSI-2 interfaces, and the physical camera ports have fixed assignment to the MIPI-CSIS devices.. This way we could drop alias ID for the MIPI-CSIS nodes. And their instance index that is required for the top level driver which exposes topology and the routing capabilities to user space could be restored from the reg property value by subtracting a fixed offset. I suppose that would work. It feels a little indirect, and I think means that the driver needs to go find some child node defining its end of some link, then find the node representing the other end of the link, then read properties out of that other node to find the value. That seems a little unusual, but I guess it would work. I'm not sure of the long-term implications of doing that kind of thing. You'd want to run the idea past some DT maintainers/experts. ... I can see aliases used in bindings of multiple devices: uart, spi, sound interfaces, gpio, ... And all bindings seem to impose some rules on how their aliases are created. Do you have specific examples? I really don't think the bindings should be dictating the alias values. After all, what happens in some later SoC where you have two different types of module that feed into the common module, such that type A sources have IDs 0..3 in the common module, and type B sources have IDs 4..7 in the common module - you wouldn't want to require alias ISs 4..7 for the type B DT nodes. There is no need to write alias ID directly into registers, and actually it doesn't really happen. But we need to know that, for example camera A is connected to physical MIPI CSI-2 channel 0 and to capture video with DMA engine of FIMC.2 we need to set FIMC.2 input register to link it to MIPI-CSIS 0. OK, so the IDs are selecting which register to write, or which mux settings to access. That's pretty much semantically the same thing. -- 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: [RFC] i2c: Providing hooks for i2c multimaster bus arbitration.
Wolfram, On Sun, Feb 10, 2013 at 10:17 AM, Wolfram Sang w.s...@pengutronix.de wrote: On Mon, Feb 04, 2013 at 02:33:15PM +0530, Yuvaraj Kumar C D wrote: This RFC patch is w.r.t multimaster bus arbitration which is already being discussing in the mainline. This patch provides hooks for the i2c multimaster bus arbitration and to have the arbitration parameters. I still haven't understood why the arbitration specified in the I2C standard is not enough for you. Or what you would need to make use of it. At the moment perhaps the strongest argument for why this particular arbitration scheme is needed is that's what the EC (embedded controller) on the ARM Chromebook uses. There have been several arguments in-house about whether this was the most ideal way to structure things, but that's what we shipped with. Thus, if we want to be able to talk to i2c devices on this bus (contains the keyboard, battery, and a bunch of power switches) we need something in the system that implements this arbitration scheme. As a side note: I'm trying to code up a quick arbitrator now using the muxing framework as Grant suggested. I will play with this and post it if I can get it to work. It's quite short so far. -Doug -- 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 0/3] ARM: S3C24XX: integrate special s3c2412 eint handling
This series is meant to go on top of the recent basic integration of the s3c2412, s3c2440 and s3c2442 and implements the last necessary change by making the overrides of the eints 0 to 3 on the s3c2412 unnecessary. After this everything is handled using the new structure. Heiko Stuebner (3): ARM: S3C24XX: include first 4 bits of the eint register in irq mapping ARM: S3C24XX: add soc_is_s3c2412 option ARM: S3C24XX: handle s3c2412 eints using new infrastructure arch/arm/mach-s3c24xx/include/mach/irqs.h | 58 +++-- arch/arm/mach-s3c24xx/irq.c | 127 + arch/arm/plat-samsung/include/plat/cpu.h | 10 +++ drivers/gpio/gpio-samsung.c |5 +- 4 files changed, 83 insertions(+), 117 deletions(-) -- 1.7.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
[PATCH 1/3] ARM: S3C24XX: include first 4 bits of the eint register in irq mapping
This patch moves the irq numbers starting with EINT4 4 points down to enable the inclusion of the first 4 bits of EINT register into the mapping removing the need for special offset handling. For most S3C24XX architectures this will simply create 4 additional unused interrupts, but enables the S3C2412 to make use of the new infrastructure to realize its special handling of the EINT0 to EINT3 interrupts. All affected parts of the Samsung code (arch + drivers) seem to use the real interrupt defines (IRQ_something) and not any form of S3C2410_IRQ(x) whose numbering is changed here starting from S3C2410_IRQ(32). This patch was runtime-tested on a s3c2416 based board. Signed-off-by: Heiko Stuebner he...@sntech.de --- arch/arm/mach-s3c24xx/include/mach/irqs.h | 54 ++-- arch/arm/mach-s3c24xx/irq.c |9 + 2 files changed, 29 insertions(+), 34 deletions(-) diff --git a/arch/arm/mach-s3c24xx/include/mach/irqs.h b/arch/arm/mach-s3c24xx/include/mach/irqs.h index b7a9f4d..ea589e4 100644 --- a/arch/arm/mach-s3c24xx/include/mach/irqs.h +++ b/arch/arm/mach-s3c24xx/include/mach/irqs.h @@ -59,49 +59,49 @@ #define IRQ_ADCPARENT S3C2410_IRQ(31) /* interrupts generated from the external interrupts sources */ -#define IRQ_EINT4 S3C2410_IRQ(32)/* 48 */ -#define IRQ_EINT5 S3C2410_IRQ(33) -#define IRQ_EINT6 S3C2410_IRQ(34) -#define IRQ_EINT7 S3C2410_IRQ(35) -#define IRQ_EINT8 S3C2410_IRQ(36) -#define IRQ_EINT9 S3C2410_IRQ(37) -#define IRQ_EINT10 S3C2410_IRQ(38) -#define IRQ_EINT11 S3C2410_IRQ(39) -#define IRQ_EINT12 S3C2410_IRQ(40) -#define IRQ_EINT13 S3C2410_IRQ(41) -#define IRQ_EINT14 S3C2410_IRQ(42) -#define IRQ_EINT15 S3C2410_IRQ(43) -#define IRQ_EINT16 S3C2410_IRQ(44) -#define IRQ_EINT17 S3C2410_IRQ(45) -#define IRQ_EINT18 S3C2410_IRQ(46) -#define IRQ_EINT19 S3C2410_IRQ(47) -#define IRQ_EINT20 S3C2410_IRQ(48)/* 64 */ -#define IRQ_EINT21 S3C2410_IRQ(49) -#define IRQ_EINT22 S3C2410_IRQ(50) -#define IRQ_EINT23 S3C2410_IRQ(51) +#define IRQ_EINT4 S3C2410_IRQ(36)/* 52 */ +#define IRQ_EINT5 S3C2410_IRQ(37) +#define IRQ_EINT6 S3C2410_IRQ(38) +#define IRQ_EINT7 S3C2410_IRQ(39) +#define IRQ_EINT8 S3C2410_IRQ(40) +#define IRQ_EINT9 S3C2410_IRQ(41) +#define IRQ_EINT10 S3C2410_IRQ(42) +#define IRQ_EINT11 S3C2410_IRQ(43) +#define IRQ_EINT12 S3C2410_IRQ(44) +#define IRQ_EINT13 S3C2410_IRQ(45) +#define IRQ_EINT14 S3C2410_IRQ(46) +#define IRQ_EINT15 S3C2410_IRQ(47) +#define IRQ_EINT16 S3C2410_IRQ(48) +#define IRQ_EINT17 S3C2410_IRQ(49) +#define IRQ_EINT18 S3C2410_IRQ(50) +#define IRQ_EINT19 S3C2410_IRQ(51) +#define IRQ_EINT20 S3C2410_IRQ(52)/* 68 */ +#define IRQ_EINT21 S3C2410_IRQ(53) +#define IRQ_EINT22 S3C2410_IRQ(54) +#define IRQ_EINT23 S3C2410_IRQ(55) #define IRQ_EINT_BIT(x)((x) - IRQ_EINT4 + 4) #define IRQ_EINT(x)(((x) = 4) ? (IRQ_EINT4 + (x) - 4) : (IRQ_EINT0 + (x))) -#define IRQ_LCD_FIFO S3C2410_IRQ(52) -#define IRQ_LCD_FRAME S3C2410_IRQ(53) +#define IRQ_LCD_FIFO S3C2410_IRQ(56) +#define IRQ_LCD_FRAME S3C2410_IRQ(57) /* IRQs for the interal UARTs, and ADC * these need to be ordered in number of appearance in the * SUBSRC mask register */ -#define S3C2410_IRQSUB(x) S3C2410_IRQ((x)+54) +#define S3C2410_IRQSUB(x) S3C2410_IRQ((x)+58) -#define IRQ_S3CUART_RX0S3C2410_IRQSUB(0) /* 70 */ +#define IRQ_S3CUART_RX0S3C2410_IRQSUB(0) /* 74 */ #define IRQ_S3CUART_TX0S3C2410_IRQSUB(1) #define IRQ_S3CUART_ERR0 S3C2410_IRQSUB(2) -#define IRQ_S3CUART_RX1S3C2410_IRQSUB(3) /* 73 */ +#define IRQ_S3CUART_RX1S3C2410_IRQSUB(3) /* 77 */ #define IRQ_S3CUART_TX1S3C2410_IRQSUB(4) #define IRQ_S3CUART_ERR1 S3C2410_IRQSUB(5) -#define IRQ_S3CUART_RX2S3C2410_IRQSUB(6) /* 76 */ +#define IRQ_S3CUART_RX2S3C2410_IRQSUB(6) /* 80 */ #define IRQ_S3CUART_TX2S3C2410_IRQSUB(7) #define IRQ_S3CUART_ERR2 S3C2410_IRQSUB(8) @@ -136,7 +136,7 @@ /* second interrupt-register of s3c2416/s3c2450 */ -#define S3C2416_IRQ(x) S3C2410_IRQ((x) + 54 + 29) +#define S3C2416_IRQ(x) S3C2410_IRQ((x) + 58 + 29) #define IRQ_S3C2416_2D S3C2416_IRQ(0) #define IRQ_S3C2416_IIC1 S3C2416_IRQ(1) #define IRQ_S3C2416_RESERVED2 S3C2416_IRQ(2) diff --git a/arch/arm/mach-s3c24xx/irq.c b/arch/arm/mach-s3c24xx/irq.c index 1cb1962..67e8d82 100644 --- a/arch/arm/mach-s3c24xx/irq.c +++ b/arch/arm/mach-s3c24xx/irq.c @@ -452,7 +452,6 @@ struct s3c_irq_intc *s3c24xx_init_intc(struct device_node *np, void __iomem *base = (void *)0xf600; /* static mapping */ int irq_num; int irq_start; - int irq_offset; int ret; intc =
[PATCH 2/3] ARM: S3C24XX: add soc_is_s3c2412 option
Makes it possible to identify s3c2412 SoCs. Signed-off-by: Heiko Stuebner he...@sntech.de --- arch/arm/plat-samsung/include/plat/cpu.h | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h index e126644..0f6c47a 100644 --- a/arch/arm/plat-samsung/include/plat/cpu.h +++ b/arch/arm/plat-samsung/include/plat/cpu.h @@ -23,6 +23,9 @@ extern unsigned long samsung_cpu_id; #define S3C24XX_CPU_ID 0x3240 #define S3C24XX_CPU_MASK 0xFFF0 +#define S3C2412_CPU_ID 0x32412000 +#define S3C2412_CPU_MASK 0xF000 + #define S3C6400_CPU_ID 0x3640 #define S3C6410_CPU_ID 0x3641 #define S3C64XX_CPU_MASK 0xF000 @@ -53,6 +56,7 @@ static inline int is_samsung_##name(void) \ } IS_SAMSUNG_CPU(s3c24xx, S3C24XX_CPU_ID, S3C24XX_CPU_MASK) +IS_SAMSUNG_CPU(s3c2412, S3C2412_CPU_ID, S3C2412_CPU_MASK) IS_SAMSUNG_CPU(s3c6400, S3C6400_CPU_ID, S3C64XX_CPU_MASK) IS_SAMSUNG_CPU(s3c6410, S3C6410_CPU_ID, S3C64XX_CPU_MASK) IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK) @@ -74,6 +78,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK) # define soc_is_s3c24xx() 0 #endif +#if defined(CONFIG_CPU_S3C2412) +# define soc_is_s3c2412() is_samsung_s3c2412() +#else +# define soc_is_s3c2412() 0 +#endif + #if defined(CONFIG_CPU_S3C6400) || defined(CONFIG_CPU_S3C6410) # define soc_is_s3c64xx() (is_samsung_s3c6400() || is_samsung_s3c6410()) #else -- 1.7.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
[PATCH 3/3] ARM: S3C24XX: handle s3c2412 eints using new infrastructure
The s3c2412 handles the eints 0 to 3 different than all the other SoCs
of the 24xx range. These eints must be acked and masked in the regular
bits as well as the bits 0 to 3 of the eint registers, which are unused
on the other SoCs.
This of course can be realized using the new infrastructure with the
eint bits in the main register being the parent interrupts of the
same bits in the eint register.
The s3c2412 therefore gets its own IRQ_EINT0 to 4 constants that
reside in the newly created gap before IRQ_EINT4. gpio-samsung, as the
only user of these is modified to return the correct values when
handling gpio_to_irq requests on s3c2412 based machines.
Due to lack of hardware this is compile tested only, but should
hopefully work as intended.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/include/mach/irqs.h |4 +
arch/arm/mach-s3c24xx/irq.c | 118 +
drivers/gpio/gpio-samsung.c |5 +-
3 files changed, 44 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/include/mach/irqs.h
b/arch/arm/mach-s3c24xx/include/mach/irqs.h
index ea589e4..43cada8 100644
--- a/arch/arm/mach-s3c24xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c24xx/include/mach/irqs.h
@@ -59,6 +59,10 @@
#define IRQ_ADCPARENT S3C2410_IRQ(31)
/* interrupts generated from the external interrupts sources */
+#define IRQ_EINT0_2412 S3C2410_IRQ(32)
+#define IRQ_EINT1_2412 S3C2410_IRQ(33)
+#define IRQ_EINT2_2412 S3C2410_IRQ(34)
+#define IRQ_EINT3_2412 S3C2410_IRQ(35)
#define IRQ_EINT4 S3C2410_IRQ(36)/* 52 */
#define IRQ_EINT5 S3C2410_IRQ(37)
#define IRQ_EINT6 S3C2410_IRQ(38)
diff --git a/arch/arm/mach-s3c24xx/irq.c b/arch/arm/mach-s3c24xx/irq.c
index 67e8d82..debf606 100644
--- a/arch/arm/mach-s3c24xx/irq.c
+++ b/arch/arm/mach-s3c24xx/irq.c
@@ -344,7 +344,10 @@ static int s3c24xx_irq_map(struct irq_domain *h, unsigned
int virq,
case S3C_IRQTYPE_NONE:
return 0;
case S3C_IRQTYPE_EINT:
- if (irq_data-parent_irq)
+ /* On the S3C2412, the EINT0to3 have a parent irq
+* but need the s3c_irq_eint0t4 chip
+*/
+ if (irq_data-parent_irq (!soc_is_s3c2412() || hw = 4))
irq_set_chip_and_handler(virq, s3c_irqext_chip,
handle_edge_irq);
else
@@ -625,10 +628,10 @@ void __init s3c24xx_init_irq(void)
#ifdef CONFIG_CPU_S3C2412
static struct s3c_irq_data init_s3c2412base[32] = {
- { .type = S3C_IRQTYPE_EINT, }, /* EINT0 */
- { .type = S3C_IRQTYPE_EINT, }, /* EINT1 */
- { .type = S3C_IRQTYPE_EINT, }, /* EINT2 */
- { .type = S3C_IRQTYPE_EINT, }, /* EINT3 */
+ { .type = S3C_IRQTYPE_LEVEL, }, /* EINT0 */
+ { .type = S3C_IRQTYPE_LEVEL, }, /* EINT1 */
+ { .type = S3C_IRQTYPE_LEVEL, }, /* EINT2 */
+ { .type = S3C_IRQTYPE_LEVEL, }, /* EINT3 */
{ .type = S3C_IRQTYPE_LEVEL, }, /* EINT4to7 */
{ .type = S3C_IRQTYPE_LEVEL, }, /* EINT8to23 */
{ .type = S3C_IRQTYPE_NONE, }, /* reserved */
@@ -659,6 +662,33 @@ static struct s3c_irq_data init_s3c2412base[32] = {
{ .type = S3C_IRQTYPE_LEVEL, }, /* ADCPARENT */
};
+static struct s3c_irq_data init_s3c2412eint[32] = {
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 0 }, /* EINT0 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 1 }, /* EINT1 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 2 }, /* EINT2 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 3 }, /* EINT3 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 4 }, /* EINT4 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 4 }, /* EINT5 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 4 }, /* EINT6 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 4 }, /* EINT7 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT8 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT9 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT10 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT11 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT12 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT13 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT14 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT15 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT16 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT17 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT18 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT19 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT20 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT21 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT22 */
+ { .type = S3C_IRQTYPE_EINT, .parent_irq = 5 }, /* EINT23 */
+};
+
static struct
Re: [RFC] i2c: Providing hooks for i2c multimaster bus arbitration.
On Mon, Feb 11, 2013 at 3:53 PM, Doug Anderson diand...@chromium.org wrote: Wolfram, On Sun, Feb 10, 2013 at 10:17 AM, Wolfram Sang w.s...@pengutronix.de wrote: On Mon, Feb 04, 2013 at 02:33:15PM +0530, Yuvaraj Kumar C D wrote: This RFC patch is w.r.t multimaster bus arbitration which is already being discussing in the mainline. This patch provides hooks for the i2c multimaster bus arbitration and to have the arbitration parameters. I still haven't understood why the arbitration specified in the I2C standard is not enough for you. Or what you would need to make use of it. At the moment perhaps the strongest argument for why this particular arbitration scheme is needed is that's what the EC (embedded controller) on the ARM Chromebook uses. There have been several arguments in-house about whether this was the most ideal way to structure things, but that's what we shipped with. Thus, if we want to be able to talk to i2c devices on this bus (contains the keyboard, battery, and a bunch of power switches) we need something in the system that implements this arbitration scheme. There was some discussion about using the built-in I2C multi-master support but no one had had a good experience getting it to work reliably in a real system so we ended up deciding not to rely on this. As a side note: I'm trying to code up a quick arbitrator now using the muxing framework as Grant suggested. I will play with this and post it if I can get it to work. It's quite short so far. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
i2c0 = i2c_0;
i2c1 = i2c_1;
};
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- Addressed Wolfram's feedback; rebased atop idr-cleanup series.
Changes in v2: None
drivers/i2c/i2c-core.c | 54 +-
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 0b599f2..5204818 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -921,13 +921,41 @@ out_list:
}
/**
+ * __i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap-nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int __i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ int id;
+
+ /* Handled by wrappers */
+ if (WARN_ON(adap-nr == -1))
+ return -EINVAL;
+
+ if (adap-nr ~MAX_IDR_MASK)
+ return -EINVAL;
+
+ mutex_lock(core_lock);
+ id = idr_alloc(i2c_adapter_idr, adap, adap-nr, adap-nr + 1,
+ GFP_KERNEL);
+ mutex_unlock(core_lock);
+ if (id 0)
+ return id == -ENOSPC ? -EBUSY : id;
+ return i2c_register_adapter(adap);
+}
+
+/**
* i2c_add_adapter - declare i2c adapter, use dynamic bus number
* @adapter: the adapter to add
* Context: can sleep
*
* This routine is used to declare an I2C adapter when its bus number
- * doesn't matter. Examples: for I2C adapters dynamically added by
- * USB links or PCI plugin cards.
+ * doesn't matter or when its bus number is specified by an dt alias.
+ * Examples of bases when the bus number doesn't matter: I2C adapters
+ * dynamically added by USB links or PCI plugin cards.
*
* When this returns zero, a new bus number was allocated and stored
* in adap-nr, and the specified adapter became available for clients.
@@ -935,8 +963,17 @@ out_list:
*/
int i2c_add_adapter(struct i2c_adapter *adapter)
{
+ struct device *dev = adapter-dev;
int res;
+ if (dev-of_node) {
+ res = of_alias_get_id(dev-of_node, i2c);
+ if (res = 0) {
+ adapter-nr = res;
+ return __i2c_add_numbered_adapter(adapter);
+ }
+ }
+
mutex_lock(core_lock);
res = idr_alloc(i2c_adapter_idr, adapter,
__i2c_first_dynamic_bus_num, 0, GFP_KERNEL);
@@ -974,20 +1011,9 @@ EXPORT_SYMBOL(i2c_add_adapter);
*/
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
{
- int id;
-
if (adap-nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
- if (adap-nr ~MAX_IDR_MASK)
- return -EINVAL;
-
- mutex_lock(core_lock);
- id = idr_alloc(i2c_adapter_idr, adap, adap-nr, adap-nr + 1,
- GFP_KERNEL);
- mutex_unlock(core_lock);
- if (id 0)
- return id == -ENOSPC ? -EBUSY : id;
- return i2c_register_adapter(adap);
+ return __i2c_add_numbered_adapter(adap);
}
EXPORT_SYMBOL_GPL(i2c_add_numbered_adapter);
--
1.8.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 v3 2/2] i2c: pxa: Use i2c-core to get bus number now
The commit: i2c-core: dt: Pick i2c bus number from i2c alias if
present adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3: None
Changes in v2:
- No longer tweak pdev-id as per Sylwester Nawrocki.
- No longer add the dev ID to the adap.name. Other drivers don't
include the device ID here and it doesn't make sense with
dynamically (or automatically) allocated IDs.
- Use dev_name(dev-dev) to register for the IRQ; this matches what
the i2c-s3c2410.c does and handles dynamically allocated IDs.
- This change was only compile-tested (corgi_defconfig), since I don't
have access to a board that uses this driver.
drivers/i2c/busses/i2c-pxa.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..705cc9f 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1053,16 +1053,13 @@ static int i2c_pxa_probe_dt(struct platform_device
*pdev, struct pxa_i2c *i2c,
struct device_node *np = pdev-dev.of_node;
const struct of_device_id *of_id =
of_match_device(i2c_pxa_dt_ids, pdev-dev);
- int ret;
if (!of_id)
return 1;
- ret = of_alias_get_id(np, i2c);
- if (ret 0) {
- dev_err(pdev-dev, failed to get alias id, errno %d\n, ret);
- return ret;
- }
- pdev-id = ret;
+
+ /* For device tree we always use the dynamic or alias-assigned ID */
+ i2c-adap.nr = -1;
+
if (of_get_property(np, mrvl,i2c-polling, NULL))
i2c-use_pio = 1;
if (of_get_property(np, mrvl,i2c-fast-mode, NULL))
@@ -1100,6 +1097,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
goto emalloc;
}
+ /* Default adapter num to device id; i2c_pxa_probe_dt can override. */
+ i2c-adap.nr = dev-id;
+
ret = i2c_pxa_probe_dt(dev, i2c, i2c_type);
if (ret 0)
ret = i2c_pxa_probe_pdata(dev, i2c, i2c_type);
@@ -1124,9 +1124,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
spin_lock_init(i2c-lock);
init_waitqueue_head(i2c-wait);
- i2c-adap.nr = dev-id;
- snprintf(i2c-adap.name, sizeof(i2c-adap.name), pxa_i2c-i2c.%u,
-i2c-adap.nr);
+ strlcpy(i2c-adap.name, pxa_i2c-i2c, sizeof(i2c-adap.name));
i2c-clk = clk_get(dev-dev, NULL);
if (IS_ERR(i2c-clk)) {
@@ -1169,7 +1167,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
} else {
i2c-adap.algo = i2c_pxa_algorithm;
ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
- i2c-adap.name, i2c);
+ dev_name(dev-dev), i2c);
if (ret)
goto ereqirq;
}
--
1.8.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 v2 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
Wolfram,
Thanks for the review. New patch was just sent. :)
On Sun, Feb 10, 2013 at 4:19 AM, Wolfram Sang w.s...@pengutronix.de wrote:
+static int i2c_get_number_from_dt(struct i2c_adapter *adap)
i2c_get_id_from_dt()?
Done.
+ if (!dev-of_node)
+ return -1;
-ESOMETHING?
Function has been removed, as per below.
+
+ id = of_alias_get_id(dev-of_node, i2c);
+ if (id 0)
+ return -1;
+ return id;
Simply 'return of_alias_get_id(...)'? Even more, since this function
boils down to calling of_alias_get_id only and is only used once, I'd
think we can implement that directly and drop this function. That
shouldn't hurt readability.
Good point. Done.
+/**
+ * _i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap-nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int _i2c_add_numbered_adapter(struct i2c_adapter *adap)
All other internal functions are prefixed with '__'.
Done.
+{
+ int id;
+ int status;
+
+ /* Handled by wrappers */
+ BUG_ON(adap-nr == -1);
Is that a reason to halt the kernel? WARN and bailing out would do IMO.
Done.
+
+ if (adap-nr ~MAX_IDR_MASK)
+ return -EINVAL;
Note the idr-cleanup series from Tejun Heo. Given that his series is
scheduled for v3.9, I'd like to have your patches on top of his.
Done.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] Add automatic bus number support for i2c busses with device tree
This was suggested by Mark Brown in response to a patch for adding this functionality only for the s3c2410 bus: https://lkml.org/lkml/2012/11/20/681 I have also modified the i2c-pxa driver to use this new functionality. The i2c-pxa driver changes have only been compile-tested and are just for cleanup purposes. Changes in v3: - Addressed Wolfram's feedback; rebased atop idr-cleanup series. Changes in v2: - No longer tweak pdev-id as per Sylwester Nawrocki. - No longer add the dev ID to the adap.name. Other drivers don't include the device ID here and it doesn't make sense with dynamically (or automatically) allocated IDs. - Use dev_name(dev-dev) to register for the IRQ; this matches what the i2c-s3c2410.c does and handles dynamically allocated IDs. - This change was only compile-tested (corgi_defconfig), since I don't have access to a board that uses this driver. Doug Anderson (2): i2c-core: dt: Pick i2c bus number from i2c alias if present i2c: pxa: Use i2c-core to get bus number now drivers/i2c/busses/i2c-pxa.c | 20 drivers/i2c/i2c-core.c | 54 2 files changed, 49 insertions(+), 25 deletions(-) -- 1.8.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 3/3] dts: Add cpufreq controller node for Exynos5440 SoC
On Fri, Feb 8, 2013 at 8:49 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 8 February 2013 00:03, amit kachhap amit.kach...@gmail.com wrote:
On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com
wrote:
Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 024269d..b20b517 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,15 @@
};
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ cpufreq_tbl = 120 1025000
+ 100 975000
+ 80 925000 ;
+ };
+
I think cpufreq_tbl should be part of the cpu node as it's the
property of the cpu.
Please refer cpufreq-cpu0 and spear-cpufreq.
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15364.
In this thread same discussion followed. I am not sure what is the
correct way but looks like Kukjin concluded this with a timer node
separate from the CPU code.
I am only talking about cpufreq_tbl and its nothing but operating
points for the cpus. It seems its agreed upon to add operating-points
to cpu node as being done by all other platforms like imx6q, am33xx,
cpufreq-cpu0 and spear.
Even timer, GIC, cpufreq tbl, pmu etc are all cpu properties. But the
problem is whether to put them in cpu0 or repeat same information in
all cpu nodes as it is common to all cpu's and not just cpu0. So as
Kukjin kim has put the timer node outside the cpu node so i also
followed the same convention.
Mr Kim,
Any issue in this approach?
Thanks,
Amit Daniel
Thanks,
Inder
Thanks,
Amit Daniel
serial@B {
compatible = samsung,exynos4210-uart;
reg = 0xB 0x1000;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe
linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] iio: adc: add exynos5 adc driver under iio framwork
Hi,
It looks like the bindings here are still completely unsettled, or at least
unimplemented -- there seems to be a preference for an encoding similar to how
interrupts/gpios/clks work. I think that wouldn't be a bad idea.
For the case of this particular driver and connections, it'd just mean you
would need to do the binding slightly differently. You can still have some of
the sensors under the ADC node if they're not sitting on another bus where it
makes sense to locate them.
Some further comments below.
On Thu, Jan 24, 2013 at 10:35:32AM +0530, Naveen Krishna Chatradhi wrote:
This patch add an ADC IP found on EXYNOS5250 and EXYNOS5410 SoCs
from Samsung. Also adds the Documentation for device tree bindings.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v1:
1. Fixed comments from Lars
2. Added support for ADC on EXYNOS5410
Changes since v2:
1. Changed the instance name for (struct iio_dev *) to indio_dev
2. Changed devm_request_irq to request_irq
Few doubts regarding the mappings and child device handling.
Kindly, suggest me better methods.
Changes since v3:
1. Added clk_prepare_disable and regulator_disable calls in _remove()
2. Moved init_completion before irq_request
3. Added NULL pointer check for devm_request_and_ioremap() return value.
4. Use number of channels as per the ADC version
5. Change the define ADC_V1_CHANNEL to ADC_CHANNEL
6. Update the Documentation to include EXYNOS5410 compatible
Changes since v4:
1. if devm_request_and_ioremap() failes, free iio_device before returning
Doug, i've used
chan = iio_channel_get(dev_name(pdev-dev), adc3);
in ntc thermistor driver during probe and
iio_read_channel_raw(chan, val);
for read.
But, then the drivers become kind of coupled. Right.
Lars, Is there an other way.
Thanks for the comments
.../bindings/arm/samsung/exynos5-adc.txt | 38 ++
drivers/iio/adc/Kconfig|7 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/exynos5_adc.c | 477
4 files changed, 523 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
create mode 100644 drivers/iio/adc/exynos5_adc.c
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
new file mode 100644
index 000..0f281d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
@@ -0,0 +1,38 @@
+Samsung Exynos5 Analog to Digital Converter bindings
+
+Required properties:
+- compatible:Must be samsung,exynos5250-adc for exynos5250
controllers.
+ Must be samsung,exynos5410-adc for exynos5410
controllers.
Looking at the out-of-tree patch we have that adds exynos5 support to
arch/arm/plat-samsung/adc.c, this looks like it should be:
samsung,exynos4412-adc should be the base case (this was the first chip with
the new version 4 ADC hardware). Then for 5250 the chip-specific
prefixes should also be there for compatible in case there are SoC-specific
bugs or quirks or features that the driver in the future might need to care
about.
Based on the code below, it looks like 5410 isn't compatible with 4412, since
it needs special init sequences. So that means 5410 shouldn't be claimed to be
compatible.
+- reg: Contains ADC register address range (base
address and
+ length).
+- interrupts:Contains the interrupt information for the
timer. The
+ format is being dependent on which interrupt controller
+ the Samsung device uses.
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc@12D1 {
+ compatible = samsung,exynos5250-adc;
+ reg = 0x12D1 0x100;
+ interrupts = 0 106 0;
+ #address-cells = 1;
+ #size-cells = 1;
This is where something like #channel-cells or something else would be needed
-- not address cells and size cells. And then (see below)...
+ ranges;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D1 {
+
+ /* NTC thermistor is a hwmon device */
+ ncp15wb473@0 {
+ compatible = ntc,ncp15wb473;
+ reg = 0x0;
+ pullup-uV = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
So, here is where the reference to channel should be specified. Even for those
who are located as children to the adc node.
Something like (naming is up in the air):
io-channel = adc 0;
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index fe822a1..33ceabf 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -91,6 +91,13 @@ config AT91_ADC
help
Say yes here to
Re: [PATCH 3/3] dts: Add cpufreq controller node for Exynos5440 SoC
On 12 February 2013 06:42, amit kachhap amit.kach...@gmail.com wrote:
On Fri, Feb 8, 2013 at 8:49 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 8 February 2013 00:03, amit kachhap amit.kach...@gmail.com wrote:
On Wed, Feb 6, 2013 at 8:49 PM, Inderpal Singh
inderpal.si...@linaro.org wrote:
On 7 February 2013 01:09, Amit Daniel Kachhap amit.dan...@samsung.com
wrote:
Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 024269d..b20b517 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,15 @@
};
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ cpufreq_tbl = 120 1025000
+ 100 975000
+ 80 925000 ;
+ };
+
I think cpufreq_tbl should be part of the cpu node as it's the
property of the cpu.
Please refer cpufreq-cpu0 and spear-cpufreq.
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15364.
In this thread same discussion followed. I am not sure what is the
correct way but looks like Kukjin concluded this with a timer node
separate from the CPU code.
I am only talking about cpufreq_tbl and its nothing but operating
points for the cpus. It seems its agreed upon to add operating-points
to cpu node as being done by all other platforms like imx6q, am33xx,
cpufreq-cpu0 and spear.
Even timer, GIC, cpufreq tbl, pmu etc are all cpu properties. But the
problem is whether to put them in cpu0 or repeat same information in
all cpu nodes as it is common to all cpu's and not just cpu0. So as
You don't have to repeat the same cpufreq_tbl for all cpu nodes.
Having table in only cpu0 node is sufficient as being done in other platforms.
Thanks,
Inder
Kukjin kim has put the timer node outside the cpu node so i also
followed the same convention.
Mr Kim,
Any issue in this approach?
Thanks,
Amit Daniel
Thanks,
Inder
Thanks,
Amit Daniel
serial@B {
compatible = samsung,exynos4210-uart;
reg = 0xB 0x1000;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe
linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
[PATCH] ARM: EXYNOS: update secondary startup code to use 24 bits of MPIDR
Commit a0ae0240507... ARM: kernel: add device tree init map function started
using 24 LSBs of MPIDR to calculate the cpu_logical_map. Hence update the same
in exynos_secondary_startup code.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
arch/arm/mach-exynos/headsmp.S |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/headsmp.S b/arch/arm/mach-exynos/headsmp.S
index 5364d4b..5c1c24a 100644
--- a/arch/arm/mach-exynos/headsmp.S
+++ b/arch/arm/mach-exynos/headsmp.S
@@ -22,7 +22,7 @@
*/
ENTRY(exynos4_secondary_startup)
mrc p15, 0, r0, c0, c0, 5
- and r0, r0, #15
+ and r0, r0, #0xff
adr r4, 1f
ldmia r4, {r5, r6}
sub r4, r4, r5
--
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
