Re: [PATCH v3 1/2] i.MX27: Add clock support for SAHARA2.

2013-03-10 Thread Herbert Xu 
On Tue, Mar 05, 2013 at 08:48:19AM +0100, javier Martin wrote:
 Hi Sascha,
 
 On 4 March 2013 08:53, Sascha Hauer s.ha...@pengutronix.de wrote:
  On Fri, Mar 01, 2013 at 12:37:52PM +0100, Javier Martin wrote:
 
  Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
  ---
   arch/arm/mach-imx/clk-imx27.c |2 ++
   1 file changed, 2 insertions(+)
 
  diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
  index 4c1d1e4..0b9664a 100644
  --- a/arch/arm/mach-imx/clk-imx27.c
  +++ b/arch/arm/mach-imx/clk-imx27.c
  @@ -253,6 +253,8 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[nfc_baud_gate], NULL, imx27-nand.0);
clk_register_clkdev(clk[vpu_baud_gate], per, coda-imx27.0);
clk_register_clkdev(clk[vpu_ahb_gate], ahb, coda-imx27.0);
  + clk_register_clkdev(clk[sahara_ahb_gate], ahb, sahara-imx27.0);
  + clk_register_clkdev(clk[sahara_ipg_gate], ipg, sahara-imx27.0);
 
  One of the first patches I want to push upstream for the next merge
  window is this one:
 
  https://patchwork.kernel.org/patch/1817741/
 
  So the change above becomes unnecessary
 
 Very good. Then this patch can be safely dropped.

So should I take this patch or not?

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: plat-nand DT support

2013-03-10 Thread Alexander Clouter 

Thanks for replying!

On Sat, Mar 09, 2013 at 12:29:00PM -0300, Ezequiel Garcia wrote:



[2] could also support the NAND used by arch/arm/mach-ep93xx/ts72xx.c but
the whole SoC has not been ported to DT


Okey, here I think you're going in the wrong direction. The current trend -and there are very 
good reasons for this- is to NOT litter arch/arm/mach-foo/ but rather put drivers handling in 
drivers/ where they rightfully belong.


I would agree.  However, what nags at me is that this driver would be rather board specific and 
not SoC/platform so the option for re-use is low; the NAND is implemented in an FPGA.


I'm trying to get a feeling of what the lesser evil is so that I can avoid no, please write a 
proper driver to live in 'drivers' or jeez, not another near-identical driver, use plat-nand. 
:)


Whats are the thoughts from the MTD world?
 * plat-nand provides all the common boilerplate NAND code that each driver needs and then has 
the platform specific non-reusable cases hook in via platform_device

 * if the SoC has be DT'd, then a unique non-reusable driver is the correct 
approach

The only possible other user of the driver is arm/mach-ep93xx (not a DT enabled SoC yet though), 
but it was made to work with plat-nand:


http://lists.infradead.org/pipermail/linux-mtd/2009-October/027563.html

That year it was also suggested I go with plat-nand, which then got accepted upstream, so I guess 
everyone was happy with it :)


http://lists.infradead.org/pipermail/linux-mtd/2009-February/024556.html

On a passing note, the plat-nand DT hooks do not work.  One core component is that 
part_probe_types missed 'ofpart' so that is a bit depressing, but the other 
nr-chips/chip-delay/bank-width/bbt-use-flash options do mean that all the maintainer needs to do 
is write the ready/cmd hooks.



In other words, the right direction is to write a nand driver if you need one.
For instance, I find a bit mixed up to have functions like
ts7800_nand_write/read_buf() in your board.c file.


Maybe there is an appetite for a hybrid?

I could write a drivers/mtd/nand/ts7xxx.c, a DT enabled NAND driver that shims around plat-nand 
which has my new DT extending patches.  Means it is all pure DT over in arch/arm and there is 
still where possible re-use of boilerplate code.


plat-nand, to me, makes sense to save code.  With a DT shim, others could crib 
from it too.

Never-the-less, I am happy to do whatever the MTD folk want, I just really do not want to go down 
one path and then told to burn everything and do plan B instead.


BTW, it could be great if you could upstream your work. Also, it could be much easier for you to 
get support and answers if you try to upstream.


This is what I am trying to do.  I am currently trying to port my board 
arch/arm/mach-orion5x/ts78xx-setup.c (that I am the maintainer for) to DT, the github page is 
just where I do development on.


Cheers, and thanks again for the reply.

--
Alexander Clouter
.sigmonster says: He who foresees calamities suffers them twice over.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems

2013-03-10 Thread Thomas Petazzoni 
Dear Mitch Bradley,

On Sat, 09 Mar 2013 19:04:51 -1000, Mitch Bradley wrote:
 
 As stated in my recent reply to Jason, I thing the correct property is
 ranges.  Ranges translates mappable child address space addresses
 into parent addresses, and that is exactly what is going on.  A specific
 subset of config addresses is mappable into parent MMIO space.

The PCI configuration space is *not* mapped in the MMIO space on
Marvell hardware. In the MMIO space of each PCIe interface, there are
many registers, only *two* of which are dedicated to accessing the PCI
configuration space:

 * One register to set the offset in the PCI configuration space.

 * One register to read or write a value in the PCI configuration, at
   the offset specified in the first register.

See the implementation of mvebu_pcie_hw_rd_conf() and
mvebu_pcie_hw_wr_conf() in the driver.

So really, the values specified in the reg = ... property are *not*
the PCI configuration spaces mapped in the MMIO space. They represent a
bunch of per PCIe interface registers used to configure them, get the
status of the link... and access, through an indirect mechanism, the
PCI configuration space.

Does this helps?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems

2013-03-10 Thread Thomas Petazzoni 
Dear Thierry Reding,

On Fri, 8 Mar 2013 21:13:40 +0100, Thierry Reding wrote:
 On Fri, Mar 08, 2013 at 01:02:46PM -0700, Jason Gunthorpe wrote:
  On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
 [...]
   2) The @0,0 and @1,0 suffixes do not correspond to the reg values
   0x0800 0 0 0 0 and 0x1000 0 0 0 0 using any rule that I know.
  
  @0,1,0 (bus,device,fn) could be more appropriate, but that is
  cosmetic?
 
 The OF PCI specification is pretty strict about this as well. It says in
 section 2.2.1.3. that only the DD and DD,FF forms can appear in a device
 path.

Note that in the case of my driver, the @X,Y represent the port and
lane of the PCIe interface. Not sure if it is correct, I can change the
names to whatever is appropriate, those names aren't used anywhere in
the driver.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips

2013-03-10 Thread Javier Martinez Canillas 
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the GPMC as a data bus.

The actual mapping between the GPMC address space and OMAP2+
address space is made using the GPMC DT ranges property.
But also a explicit call to gpmc_cs_request() is needed.

So, this patch allows an ethernet chip to be defined as an
GPMC child node an its chip-select memory address be requested.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Jon,

This patch assumes that we have solved somehow the issue that a
call to request_irq() is needed before before using a GPIO as an
IRQ and this is no longer the case when using from Device Trees.

Anyway, this is independent as how we solve this, whether is
using Jan's patch [1], adding a .request function pointer to
irq_chip as suggested by Stephen [2], or any other approach.

[1]: https://patchwork.kernel.org/patch/2009331/
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html

 arch/arm/mach-omap2/gpmc.c |   45 
 1 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4fe9ee7..d1bf48b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,6 +29,7 @@
 #include linux/of.h
 #include linux/of_mtd.h
 #include linux/of_device.h
+#include linux/of_address.h
 #include linux/mtd/nand.h
 
 #include linux/platform_data/mtd-nand-omap2.h
@@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct 
platform_device *pdev,
 }
 #endif
 
+static int gpmc_probe_ethernet_child(struct platform_device *pdev,
+struct device_node *child)
+{
+   int ret, cs;
+   unsigned long base;
+   struct resource res;
+   struct platform_device *of_dev;
+
+   if (of_property_read_u32(child, reg, cs)  0) {
+   dev_err(pdev-dev, %s has no 'reg' property\n,
+   child-full_name);
+   return -ENODEV;
+   }
+
+   if (of_address_to_resource(child, 0, res)) {
+   dev_err(pdev-dev, %s has malformed 'reg' property\n,
+   child-full_name);
+   return -ENODEV;
+   }
+
+   ret = gpmc_cs_request(cs, resource_size(res), base);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(pdev-dev, cannot request GPMC CS %d\n, cs);
+   return ret;
+   }
+
+   of_dev = of_platform_device_create(child, NULL, pdev-dev);
+   if (!of_dev) {
+   dev_err(pdev-dev, cannot create platform device for %s\n,
+   child-full_name);
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
 static int gpmc_probe_dt(struct platform_device *pdev)
 {
int ret;
@@ -1326,6 +1363,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
}
+
+   for_each_node_by_name(child, ethernet) {
+   ret = gpmc_probe_ethernet_child(pdev, child);
+   if (ret  0) {
+   of_node_put(child);
+   return ret;
+   }
+   }
return 0;
 }
 #else
-- 
1.7.7.6

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems

2013-03-10 Thread Mitch Bradley 
On 3/10/2013 5:06 AM, Thomas Petazzoni wrote:
 Dear Mitch Bradley,
 
 On Sat, 09 Mar 2013 19:04:51 -1000, Mitch Bradley wrote:
  
 As stated in my recent reply to Jason, I thing the correct property is
 ranges.  Ranges translates mappable child address space addresses
 into parent addresses, and that is exactly what is going on.  A specific
 subset of config addresses is mappable into parent MMIO space.
 
 The PCI configuration space is *not* mapped in the MMIO space on
 Marvell hardware. In the MMIO space of each PCIe interface, there are
 many registers, only *two* of which are dedicated to accessing the PCI
 configuration space:
 
  * One register to set the offset in the PCI configuration space.
 
  * One register to read or write a value in the PCI configuration, at
the offset specified in the first register.
 
 See the implementation of mvebu_pcie_hw_rd_conf() and
 mvebu_pcie_hw_wr_conf() in the driver.
 
 So really, the values specified in the reg = ... property are *not*
 the PCI configuration spaces mapped in the MMIO space. They represent a
 bunch of per PCIe interface registers used to configure them, get the
 status of the link... and access, through an indirect mechanism, the
 PCI configuration space.
 
 Does this helps?

I agree that PCI config space accesses to *downstream* devices is via an
indirect-access register pair.

The question is, does that indirect-access mechanism apply also to the
internal config headers for the root port bridges?

According to section 20.15 of the MV78230 functional spec that I am
looking at, the configuration header registers are mapped to the
internal memory space.  That section is unclear about whether those
registers are CPU-accessible via indirect-access config transactions.
When the PCIe hardware is configured for endpoint mode, the internal
headers can be accessed via PCIe config transactions from an external
port, but in root complex mode, the possibility of indirect access from
the CPU is not mentioned.

The manual is a little vague in some respects, but it does say quite
clearly that MMIO access to the root port bridge config header is
possible, and it lists the MMIO addresses thereof (section A.10).

So we all agree that access to external (downstream) config registers is
via the indirect register pair.  The unclear thing is whether the
internal config registers for the root port bridges can be indirectly
accessed.

Do we have empirical evidence that indirect-access works to the internal
root port bridge config headers?

 
 Thanks,
 
 Thomas
 
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 08/10] ASoC: dmaengine_pcm: Add open function for DT DMA request

2013-03-10 Thread Markus Pargmann 
Add a function to open a DMA PCM substream using devicetree data
provided via the client device node. The patch introduces a public
function and a private subfunction that is called by both open
functions.

Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 include/sound/dmaengine_pcm.h |  2 +
 sound/soc/soc-dmaengine-pcm.c | 89 ++-
 2 files changed, 72 insertions(+), 19 deletions(-)

diff --git a/include/sound/dmaengine_pcm.h b/include/sound/dmaengine_pcm.h
index b877334..358951a 100644
--- a/include/sound/dmaengine_pcm.h
+++ b/include/sound/dmaengine_pcm.h
@@ -43,6 +43,8 @@ snd_pcm_uframes_t snd_dmaengine_pcm_pointer_no_residue(struct 
snd_pcm_substream
 
 int snd_dmaengine_pcm_open(struct snd_pcm_substream *substream,
dma_filter_fn filter_fn, void *filter_data);
+int of_snd_dmaengine_pcm_open(struct snd_pcm_substream *substream,
+   struct device_node *client_node, const char *name);
 int snd_dmaengine_pcm_close(struct snd_pcm_substream *substream);
 
 struct dma_chan *snd_dmaengine_pcm_get_chan(struct snd_pcm_substream 
*substream);
diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c
index 111b7d92..017b691 100644
--- a/sound/soc/soc-dmaengine-pcm.c
+++ b/sound/soc/soc-dmaengine-pcm.c
@@ -20,6 +20,8 @@
  */
 #include linux/module.h
 #include linux/init.h
+#include linux/of.h
+#include linux/of_dma.h
 #include linux/dmaengine.h
 #include linux/slab.h
 #include sound/pcm.h
@@ -260,24 +262,21 @@ static int dmaengine_pcm_request_channel(struct 
dmaengine_pcm_runtime_data *prtd
return 0;
 }
 
-/**
- * snd_dmaengine_pcm_open - Open a dmaengine based PCM substream
- * @substream: PCM substream
- * @filter_fn: Filter function used to request the DMA channel
- * @filter_data: Data passed to the DMA filter function
- *
- * Returns 0 on success, a negative error code otherwise.
- *
- * This function will request a DMA channel using the passed filter function 
and
- * data. The function should usually be called from the pcm open callback.
- *
- * Note that this function will use private_data field of the substream's
- * runtime. So it is not availabe to your pcm driver implementation. If you 
need
- * to keep additional data attached to a substream use
- * snd_dmaengine_pcm_{set,get}_data.
- */
-int snd_dmaengine_pcm_open(struct snd_pcm_substream *substream,
-   dma_filter_fn filter_fn, void *filter_data)
+static int of_dmaengine_pcm_request_channel(
+   struct dmaengine_pcm_runtime_data *prtd, struct device_node *np,
+   const char *name)
+{
+   prtd-dma_chan = of_dma_request_slave_channel(np, name);
+
+   if (!prtd-dma_chan)
+   return -ENXIO;
+
+   return 0;
+}
+
+static int _snd_dmaengine_pcm_open(struct snd_pcm_substream *substream,
+   dma_filter_fn filter_fn, void *filter_data,
+   struct device_node *np, const char *slave_name)
 {
struct dmaengine_pcm_runtime_data *prtd;
int ret;
@@ -291,7 +290,11 @@ int snd_dmaengine_pcm_open(struct snd_pcm_substream 
*substream,
if (!prtd)
return -ENOMEM;
 
-   ret = dmaengine_pcm_request_channel(prtd, filter_fn, filter_data);
+   if (np)
+   ret = of_dmaengine_pcm_request_channel(prtd, np, slave_name);
+   else
+   ret = dmaengine_pcm_request_channel(prtd, filter_fn,
+   filter_data);
if (ret  0) {
kfree(prtd);
return ret;
@@ -301,9 +304,57 @@ int snd_dmaengine_pcm_open(struct snd_pcm_substream 
*substream,
 
return 0;
 }
+
+/**
+ * snd_dmaengine_pcm_open - Open a dmaengine based PCM substream
+ * @substream: PCM substream
+ * @filter_fn: Filter function used to request the DMA channel
+ * @filter_data: Data passed to the DMA filter function
+ *
+ * Returns 0 on success, a negative error code otherwise.
+ *
+ * This function will request a DMA channel using the passed filter function 
and
+ * data. The function should usually be called from the pcm open callback.
+ *
+ * Note that this function will use private_data field of the substream's
+ * runtime. So it is not availabe to your pcm driver implementation. If you 
need
+ * to keep additional data attached to a substream use
+ * snd_dmaengine_pcm_{set,get}_data.
+ */
+int snd_dmaengine_pcm_open(struct snd_pcm_substream *substream,
+   dma_filter_fn filter_fn, void *filter_data)
+{
+   return _snd_dmaengine_pcm_open(substream, filter_fn, filter_data, NULL,
+   NULL);
+}
 EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_open);
 
 /**
+ * of_snd_dmaengine_pcm_open - Open a dmaengine based PCM substream using 
oftree data
+ * @substream: PCM substream
+ * @client_node: DMA client oftree node used to request a DMA channel
+ * @name: DMA request name
+ *
+ * Returns 0 on success, a negative error code otherwise.
+ *
+ * This function will request a DMA channel

[PATCH 00/10] ASoC: imx sound: Add DT support

2013-03-10 Thread Markus Pargmann 
Hi,

This series adds DT support for imx-ssi and phycore-ac97. It also
contains some fixes for imx-ssi and phycore-ac97.

Patch 8 introduces a seperated function 'of_snd_dmaengine_pcm_open'
to create a DMA PCM substream using the generic DMA DT bindings.

Regards,
Markus


Sascha Hauer (3):
 imx-ssi: Fix AC97 rates
 imx-ssi: Fix occasional AC97 reset failure
 mx-ssi: flush fifos

Markus Pargmann (7):
 ASoC: Kconfig: imx-ssi needs imx-fiq and imx-dma
 ASoC: pcm030 audio fabric: remove __init from probe
 ARM: soc-audio phycore-ac97: fix driver init order
 ASoC: phycore-ac97: Add DT support
 ASoC: dmaengine_pcm: Add open function for DT DMA
 ASoC: imx-pcm-dma: Add support for DMA init by device
 ASoC: imx-ssi: Add imx27 and pca100 DT support

 b/Documentation/devicetree/bindings/sound/fsl-imx-ssi |   34 
 b/arch/arm/mach-imx/mach-pca100.c |7 
 b/include/sound/dmaengine_pcm.h   |2 
 b/sound/soc/fsl/Kconfig   |2 
 b/sound/soc/fsl/imx-pcm-dma.c |   31 ++-
 b/sound/soc/fsl/imx-pcm.h |6 
 b/sound/soc/fsl/imx-ssi.c |2 
 b/sound/soc/fsl/pcm030-audio-fabric.c |2 
 b/sound/soc/fsl/phycore-ac97.c|   33 ++--
 b/sound/soc/soc-dmaengine-pcm.c   |   89 --
 sound/soc/fsl/imx-ssi.c   |   95 ++-
 sound/soc/fsl/phycore-ac97.c  |  148 +++---
 12 files changed, 371 insertions(+), 80 deletions(-)

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 09/10] ASoC: imx-pcm-dma: Add support for DMA init by device node

2013-03-10 Thread Markus Pargmann 
Add support for DMA initialization using devicetree node.

This patch adds two fields to imx_pcm_dma_params to pass device node
information from other imx drivers to this one. If the dma_node is set,
this driver tries to initialize a PCM DMA substream based on the
dma_node and name.

Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 sound/soc/fsl/imx-pcm-dma.c | 31 ---
 sound/soc/fsl/imx-pcm.h |  6 ++
 2 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index 500f8ce..794103b 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -101,26 +101,35 @@ static int snd_imx_open(struct snd_pcm_substream 
*substream)
 {
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct imx_pcm_dma_params *dma_params;
-   struct imx_dma_data *dma_data;
+   struct imx_dma_data *dma_data = NULL;
int ret;
 
snd_soc_set_runtime_hwparams(substream, snd_imx_hardware);
 
dma_params = snd_soc_dai_get_dma_data(rtd-cpu_dai, substream);
 
-   dma_data = kzalloc(sizeof(*dma_data), GFP_KERNEL);
-   if (!dma_data)
-   return -ENOMEM;
+   if (dma_params-dma_client_node) {
+   ret = of_snd_dmaengine_pcm_open(substream,
+   dma_params-dma_client_node,
+   dma_params-dma_req_name);
+   if (ret)
+   return ret;
+   } else {
+   dma_data = kzalloc(sizeof(*dma_data), GFP_KERNEL);
+   if (!dma_data)
+   return -ENOMEM;
 
-   dma_data-peripheral_type = dma_params-shared_peripheral ?
+   dma_data-peripheral_type = dma_params-shared_peripheral ?
IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI;
-   dma_data-priority = DMA_PRIO_HIGH;
-   dma_data-dma_request = dma_params-dma;
+   dma_data-priority = DMA_PRIO_HIGH;
+   dma_data-dma_request = dma_params-dma;
 
-   ret = snd_dmaengine_pcm_open(substream, filter, dma_data);
-   if (ret) {
-   kfree(dma_data);
-   return ret;
+   ret = snd_dmaengine_pcm_open(substream, filter, dma_data);
+
+   if (ret) {
+   kfree(dma_data);
+   return ret;
+   }
}
 
snd_dmaengine_pcm_set_data(substream, dma_data);
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index 5ae13a1..d281fe2 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -23,6 +23,12 @@ struct imx_pcm_dma_params {
unsigned long dma_addr;
int burstsize;
bool shared_peripheral; /* The peripheral is on SPBA bus */
+
+   /* If set, the DMA channel is requested using this devicetree node while
+* ignoring fields 'dma' and 'shared_peripheral'. They have to be set
+* in devicetree according to the DMA Controller devicetree bindings. */
+   struct device_node *dma_client_node;
+   const char *dma_req_name; /* DMA Request name from devicetree */
 };
 
 int snd_imx_pcm_mmap(struct snd_pcm_substream *substream,
-- 
1.8.1.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 02/10] imx-ssi: Fix occasional AC97 reset failure

2013-03-10 Thread Markus Pargmann 
From: Sascha Hauer s.ha...@pengutronix.de

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 sound/soc/fsl/imx-ssi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index 7ee0147..0e3fc8d 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -496,6 +496,8 @@ static void imx_ssi_ac97_reset(struct snd_ac97 *ac97)
 
if (imx_ssi-ac97_reset)
imx_ssi-ac97_reset(ac97);
+   /* First read sometimes fails, do a dummy read */
+   imx_ssi_ac97_read(ac97, 0);
 }
 
 static void imx_ssi_ac97_warm_reset(struct snd_ac97 *ac97)
@@ -504,6 +506,9 @@ static void imx_ssi_ac97_warm_reset(struct snd_ac97 *ac97)
 
if (imx_ssi-ac97_warm_reset)
imx_ssi-ac97_warm_reset(ac97);
+
+   /* First read sometimes fails, do a dummy read */
+   imx_ssi_ac97_read(ac97, 0);
 }
 
 struct snd_ac97_bus_ops soc_ac97_ops = {
-- 
1.8.1.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 01/10] imx-ssi: Fix AC97 rates

2013-03-10 Thread Markus Pargmann 
From: Sascha Hauer s.ha...@pengutronix.de

This device supports multiple rates as described in later AC97
standards. This patch allows playback of different sample frequencies
without conversion.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 sound/soc/fsl/imx-ssi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index 55464a5..7ee0147 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -400,7 +400,7 @@ static struct snd_soc_dai_driver imx_ac97_dai = {
.stream_name = AC97 Playback,
.channels_min = 2,
.channels_max = 2,
-   .rates = SNDRV_PCM_RATE_48000,
+   .rates = SNDRV_PCM_RATE_8000_48000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
.capture = {
-- 
1.8.1.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 03/10] mx-ssi: flush fifos

2013-03-10 Thread Markus Pargmann 
From: Sascha Hauer s.ha...@pengutronix.de

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 sound/soc/fsl/imx-ssi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index 0e3fc8d..96e24a3 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -347,6 +347,11 @@ static int imx_ssi_trigger(struct snd_pcm_substream 
*substream, int cmd,
/* rx/tx are always enabled to access ac97 registers */
writel(scr, ssi-base + SSI_SCR);
 
+   if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+   writel(SSI_SOR_TX_CLR, ssi-base + SSI_SOR);
+   else
+   writel(SSI_SOR_RX_CLR, ssi-base + SSI_SOR);
+
writel(sier, ssi-base + SSI_SIER);
 
return 0;
-- 
1.8.1.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 04/10] ASoC: Kconfig: imx-ssi needs imx-fiq and imx-dma

2013-03-10 Thread Markus Pargmann 
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 sound/soc/fsl/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3b98159..42d3047 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -106,6 +106,8 @@ menuconfig SND_IMX_SOC
 if SND_IMX_SOC
 
 config SND_SOC_IMX_SSI
+   select SND_SOC_IMX_PCM_DMA
+   select SND_SOC_IMX_PCM_FIQ
tristate
 
 config SND_SOC_IMX_PCM
-- 
1.8.1.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 01/10] imx-ssi: Fix AC97 rates

2013-03-10 Thread Fabio Estevam 
Hi Markus,

On Sun, Mar 10, 2013 at 3:33 PM, Markus Pargmann m...@pengutronix.de wrote:
 From: Sascha Hauer s.ha...@pengutronix.de

 This device supports multiple rates as described in later AC97
 standards. This patch allows playback of different sample frequencies
 without conversion.

 Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
 Signed-off-by: Markus Pargmann m...@pengutronix.de
 ---
  sound/soc/fsl/imx-ssi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Currently we have the following ssi drivers for imx:

sound/soc/fsl/imx-ssi.c: for i.mx SoCs running on non-dt platform
sound/soc/fsl/fsl_ssi.c: for PowerPC and i.mx SoCs running on dt platforms

I see that in this series you convert sound/soc/fsl/imx-ssi.c into dt.

Shouldn't we use sound/soc/fsl/fsl_ssi.c instead and maybe even get
rid of sound/soc/fsl/imx-ssi.c when all imx become converted to dt?
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 10/10] ASoC: imx-ssi: Add imx27 and pca100 DT support

2013-03-10 Thread Alexander Shiyan 
Hello.

 Add devicetree bindings for generic imx-ssi support and specifically for
 pca100 with two custom reset functions. At the moment those functions
 are defined in mach-pca100.c. So until DT is the only method for
 booting, the ac97 reset functions have to be exported in mach-pca100.c.
 
 Signed-off-by: Markus Pargmann m...@pengutronix.de
...
 + if (of_property_read_bool(pdev-dev.of_node, imx-ssi-net))
 + ssi-flags |= IMX_SSI_NET;

This line does not make sense until the patch is not applied:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/106482.html

---
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC 00/12] Adding media device driver for Exynos imaging subsystem

2013-03-10 Thread Sylwester Nawrocki 

On 03/06/2013 12:53 PM, Shaik Ameer Basha wrote:

The following patchset features:

1] Creating a common pipeline framework which can be used by all
Exynos series SoCs for developing media device drivers.
2] Modified the existing fimc-mdevice for exynos4 to use the common
pipeline framework.
3] Adding of media device driver for Exynos5 Imaging subsystem.
4] Upgrading mipi-csis and fimc-lite drivers for Exynos5 SoCs.
5] Adding DT support to m5mols driver and tested with Exynos5 media
device driver.

Current changes are not tested on exynos4 series SoCs. Current media
device driver only support one pipeline (pipeline0) which consists of
Sensor --  MIPI-CSIS --  FIMC-LITE
Sensor --  FIMC-LITE


Thanks Shaik. My quick review to follow. I'll focus on most significant
issues for now.

And here is my updated patch series adding device tree support to
s5p-fimc driver [1]. I hope it gets merged to v3.10 without significant
changes. Sorry, for now we need to use that private branch.

[1] http://git.linuxtv.org/snawrocki/samsung.git/devicetree-fimc

Regards,
Sylwester
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC 03/12] media: fimc-lite: Adding support for Exynos5

2013-03-10 Thread Sylwester Nawrocki 

On 03/06/2013 12:53 PM, Shaik Ameer Basha wrote:

This patch adds the following functionalities to existing driver

1] FIMC-LITE supports multiple DMA shadow registers from Exynos5 onwards.
This patch adds the functionality of using shadow registers by
checking the current FIMC-LITE hardware version.
2] Fixes Buffer corruption on DMA output from fimc-lite
3] Modified the driver to be used as pipeline endpoint


There seems to be too many things done in this single patch. Can
we have it split for example to the parts adding:
- registers definitions and hardware interface helpers
  for exynos5
- the DMA handling fix

So it is easier to apply it and test incrementally ?


Signed-off-by: Shaik Ameer Bashashaik.am...@samsung.com
Signed-off-by: Arun Kumar Karun...@samsung.com
---
  drivers/media/platform/s5p-fimc/fimc-lite-reg.c |   16 +-
  drivers/media/platform/s5p-fimc/fimc-lite-reg.h |   41 -
  drivers/media/platform/s5p-fimc/fimc-lite.c |  196 +--
  drivers/media/platform/s5p-fimc/fimc-lite.h |3 +-
  4 files changed, 236 insertions(+), 20 deletions(-)

...

  void flite_hw_dump_regs(struct fimc_lite *dev, const char *label)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite-reg.h 
b/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
index 0e34584..716df6c 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
+++ b/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
@@ -120,6 +120,10 @@
  /* b0: 1 - camera B, 0 - camera A */
  #define FLITE_REG_CIGENERAL_CAM_B (1  0)

+
+#define FLITE_REG_CIFCNTSEQ0x100
+#define FLITE_REG_CIOSAN(x)(0x200 + (4 * (x)))
+
  /* 

   * Function declarations
   */
@@ -143,8 +147,41 @@ void flite_hw_set_dma_window(struct fimc_lite *dev, struct 
flite_frame *f);
  void flite_hw_set_test_pattern(struct fimc_lite *dev, bool on);
  void flite_hw_dump_regs(struct fimc_lite *dev, const char *label);

-static inline void flite_hw_set_output_addr(struct fimc_lite *dev, u32 paddr)
+static inline void flite_hw_set_output_addr(struct fimc_lite *dev,
+   u32 paddr, u32 index)
+{
+   u32 config;
+
+   /* FLITE in EXYNOS4 has only one DMA register */
+   if (dev-variant-version == FLITE_VER_EXYNOS4)
+   index = 0;
+
+   config = readl(dev-regs + FLITE_REG_CIFCNTSEQ);
+   config |= 1  index;
+   writel(config, dev-regs + FLITE_REG_CIFCNTSEQ);
+
+   if (index == 0)
+   writel(paddr, dev-regs + FLITE_REG_CIOSA);
+   else
+   writel(paddr, dev-regs + FLITE_REG_CIOSAN(index-1));
+}
+
+static inline void flite_hw_clear_output_addr(struct fimc_lite *dev, u32 index)
  {
-   writel(paddr, dev-regs + FLITE_REG_CIOSA);
+   u32 config;
+
+   /* FLITE in EXYNOS4 has only one DMA register */
+   if (dev-variant-version == FLITE_VER_EXYNOS4)
+   index = 0;


I'm planning to remove struct flite_variant and put everything what's
needed in the driver data structure. Are there any differences between
FIMC-LITE IP block instances or Exynos5250 ? Or are these all same ?

That said it seems better to me to add a field like out_dma_bufs to the
driver data structure and embed a pointer to this structure in struct
fimc_lite. The driver data matching would be done automatically, based
on the compatible property and those unpleasant checks
if (variant-version == FLITE_VER_EXYNOS4) ...


+
+   config = readl(dev-regs + FLITE_REG_CIFCNTSEQ);
+   config= ~(1  index);
+   writel(config, dev-regs + FLITE_REG_CIFCNTSEQ);
  }
+
+static inline void flite_hw_clear_output_index(struct fimc_lite *dev)
+{
+   writel(0, dev-regs + FLITE_REG_CIFCNTSEQ);
+}
+
  #endif /* FIMC_LITE_REG_H */
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c 
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index eb64f87..1edc5ce 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -136,6 +136,8 @@ static int fimc_lite_hw_init(struct fimc_lite *fimc, bool 
isp_output)
if (fimc-fmt == NULL)
return -EINVAL;

+   flite_hw_clear_output_index(fimc);
+
/* Get sensor configuration data from the sensor subdev */
src_info = v4l2_get_subdev_hostdata(sensor);
spin_lock_irqsave(fimc-slock, flags);
@@ -266,19 +268,24 @@ static irqreturn_t flite_irq_handler(int irq, void *priv)

if ((intsrc  FLITE_REG_CISTATUS_IRQ_SRC_FRMSTART)
test_bit(ST_FLITE_RUN,fimc-state)
-   !list_empty(fimc-active_buf_q)
!list_empty(fimc-pending_buf_q)) {
+   vbuf = fimc_lite_pending_queue_pop(fimc);
+   flite_hw_set_output_addr(fimc, vbuf-paddr,
+   vbuf-vb.v4l2_buf.index);
+   fimc_lite_active_queue_add(fimc, vbuf);
+   }
+
+   if ((intsrc  FLITE_REG_CISTATUS_IRQ_SRC_FRMEND)
+

Re: [RFC 05/12] ARM: EXYNOS: Add devicetree node for mipi-csis driver for exynos5

2013-03-10 Thread Sylwester Nawrocki 

On 03/06/2013 12:53 PM, Shaik Ameer Basha wrote:

This patch adds necessary source definations needed for mipi-csis
driver and adds devicetree node for exynos5250.

Signed-off-by: Shaik Ameer Bashashaik.am...@samsung.com
---
  arch/arm/boot/dts/exynos5250.dtsi   |   18 ++
  arch/arm/mach-exynos/clock-exynos5.c|   16 ++--
  arch/arm/mach-exynos/include/mach/map.h |3 +++
  arch/arm/mach-exynos/mach-exynos5-dt.c  |4 
  4 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 3a2cd9a..4fff98b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -47,6 +47,8 @@
i2c6 =i2c_6;
i2c7 =i2c_7;
i2c8 =i2c_8;
+   csis0 =csis_0;
+   csis1 =csis_1;
};

gic:interrupt-controller@10481000 {
@@ -357,4 +359,20 @@
reg =0x1445 0x1;
interrupts =0 94 0;
};
+
+   csis_0: csis@13C2 {
+   compatible = samsung,exynos5250-csis;
+   reg =0x13C2 0x4000;
+   interrupts =0 79 0;
+   bus-width =4;
+   status = disabled;
+   };
+
+   csis_1: csis@13C3 {
+   compatible = samsung,exynos5250-csis;
+   reg =0x13C3 0x4000;
+   interrupts =0 80 0;
+   bus-width =4;


Shouldn't this be 2 ? Anyway what's the point of adding this node here
only to move it in a subsequent patch ? I guess you should first add
'camera' node and then have further patches adding relevant device nodes.


+   status = disabled;
+   };
  };



diff --git a/arch/arm/mach-exynos/clock-exynos5.c 
b/arch/arm/mach-exynos/clock-exynos5.c
index e9d7b80..34a22ff 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c


This file is already removed in Kukjin's for-next tree.
And for dts changes I would start the patch summary line with ARM: dts:.


@@ -859,6 +859,16 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_gscl_ctrl,
.ctrlbit= (1  3),
}, {
+   .name   = csis,
+   .devname= s5p-mipi-csis.0,
+   .enable = exynos5_clk_ip_gscl_ctrl,
+   .ctrlbit= (1  5),
+   }, {
+   .name   = csis,
+   .devname= s5p-mipi-csis.1,
+   .enable = exynos5_clk_ip_gscl_ctrl,
+   .ctrlbit= (1  6),
+   }, {

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC 05/12] ARM: EXYNOS: Add devicetree node for mipi-csis driver for exynos5

2013-03-10 Thread Sylwester Nawrocki 

On 03/06/2013 12:53 PM, Shaik Ameer Basha wrote:

--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -47,6 +47,8 @@
i2c6 =i2c_6;
i2c7 =i2c_7;
i2c8 =i2c_8;
+   csis0 =csis_0;
+   csis1 =csis_1;


You can drop these aliases if you use my latest patches as indicated
in the comment to patch 00/12.


diff --git a/arch/arm/mach-exynos/clock-exynos5.c 
b/arch/arm/mach-exynos/clock-exynos5.c
index e9d7b80..34a22ff 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -859,6 +859,16 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_gscl_ctrl,
.ctrlbit= (1  3),
}, {
+   .name   = csis,
+   .devname= s5p-mipi-csis.0,
+   .enable = exynos5_clk_ip_gscl_ctrl,
+   .ctrlbit= (1  5),
+   }, {


Instead you should add relevant clock definitions to the Samsung clocks 
driver,

it's already merged in Kukjin's tree.





___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC 01/12] media: s5p-fimc: modify existing mdev to use common pipeline

2013-03-10 Thread Sylwester Nawrocki 

On 03/06/2013 12:53 PM, Shaik Ameer Basha wrote:

This patch modifies the current fimc_pipeline to exynos_pipeline,


I think we could leave it as fimc_pipeline, exynos_pipeline seems
too generic to me.


which can be used across multiple media device drivers.
Signed-off-by: Shaik Ameer Bashashaik.am...@samsung.com
---
  drivers/media/platform/s5p-fimc/fimc-capture.c |   96 +++-
  drivers/media/platform/s5p-fimc/fimc-core.h|4 +-
  drivers/media/platform/s5p-fimc/fimc-lite.c|   73 --
  drivers/media/platform/s5p-fimc/fimc-lite.h|4 +-
  drivers/media/platform/s5p-fimc/fimc-mdevice.c |  186 ++--
  drivers/media/platform/s5p-fimc/fimc-mdevice.h |   41 +++---
  include/media/s5p_fimc.h   |   66 ++---
  7 files changed, 326 insertions(+), 144 deletions(-)

diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c 
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 4cbaf46..106466e 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -27,24 +27,26 @@
  #includemedia/videobuf2-core.h
  #includemedia/videobuf2-dma-contig.h

-#include fimc-mdevice.h
  #include fimc-core.h
  #include fimc-reg.h

  static int fimc_capture_hw_init(struct fimc_dev *fimc)
  {
struct fimc_ctx *ctx = fimc-vid_cap.ctx;
-   struct fimc_pipeline *p =fimc-pipeline;
+   struct exynos_pipeline *p =fimc-pipeline;
struct fimc_sensor_info *sensor;
unsigned long flags;
+   struct v4l2_subdev *sd;
int ret = 0;

-   if (p-subdevs[IDX_SENSOR] == NULL || ctx == NULL)
+   sd = exynos_pipeline_get_subdev(fimc-pipeline_ops,
+   get_subdev_sensor, p);


Hmm, it feels it is going wrong path this way. I would keep changes
to the s5p-fimc driver as small as possible. And the modules that
are shared across the exynos4 and exynos5 driver should use generic
media graph walking routines where possible.


+   if (sd == NULL || ctx == NULL)
return -ENXIO;
if (ctx-s_frame.fmt == NULL)
return -EINVAL;

-   sensor = v4l2_get_subdev_hostdata(p-subdevs[IDX_SENSOR]);
+   sensor = v4l2_get_subdev_hostdata(sd);

spin_lock_irqsave(fimc-slock, flags);
fimc_prepare_dma_offset(ctx,ctx-d_frame);

...

@@ -486,9 +491,12 @@ static struct vb2_ops fimc_capture_qops = {
  int fimc_capture_ctrls_create(struct fimc_dev *fimc)
  {
struct fimc_vid_cap *vid_cap =fimc-vid_cap;
-   struct v4l2_subdev *sensor = fimc-pipeline.subdevs[IDX_SENSOR];
+   struct v4l2_subdev *sensor;
int ret;

+   sensor = exynos_pipeline_get_subdev(fimc-pipeline_ops,
+   get_subdev_sensor,fimc-pipeline);
+
if (WARN_ON(vid_cap-ctx == NULL))
return -ENXIO;
if (vid_cap-ctx-ctrls.ready)
@@ -513,7 +521,7 @@ static int fimc_capture_open(struct file *file)

dbg(pid: %d, state: 0x%lx, task_pid_nr(current), fimc-state);

-   fimc_md_graph_lock(fimc);
+   exynos_pipeline_graph_lock(fimc-pipeline_ops,fimc-pipeline);


Hmm, this look pretty scary to me. But I suspect this change is not
needed at all. The graph lock is _not_ the pipeline lock. It protects
all media entities registered to the media device, and links between
them. Not only entities linked into specific video processing pipeline
at a moment.


mutex_lock(fimc-lock);

if (fimc_m2m_active(fimc))
@@ -531,7 +539,7 @@ static int fimc_capture_open(struct file *file)
}

if (++fimc-vid_cap.refcnt == 1) {
-   ret = fimc_pipeline_call(fimc, open,fimc-pipeline,
+   ret = exynos_pipeline_call(fimc, open,fimc-pipeline,
fimc-vid_cap.vfd.entity, true);

if (!ret  !fimc-vid_cap.user_subdev_api)
@@ -549,7 +557,7 @@ static int fimc_capture_open(struct file *file)
}
  unlock:
mutex_unlock(fimc-lock);
-   fimc_md_graph_unlock(fimc);
+   exynos_pipeline_graph_unlock(fimc-pipeline_ops,fimc-pipeline);
return ret;
  }

...

  /**
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c 
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index 3266c3f..122cf95 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c

...

-/* Called with the media graph mutex held */
-static struct v4l2_subdev *__find_remote_sensor(struct media_entity *me)
-{
-   struct media_pad *pad =me-pads[0];
-   struct v4l2_subdev *sd;
-
-   while (pad-flags  MEDIA_PAD_FL_SINK) {
-   /* source pad */
-   pad = media_entity_remote_source(pad);
-   if (pad == NULL ||
-   media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
-   break;
-
-   sd = media_entity_to_v4l2_subdev(pad-entity);
-
-   if (sd-grp_id ==

Re: [RFC 07/12] media: exynos5-is: Adding media device driver for exynos5

2013-03-10 Thread Sylwester Nawrocki 

On 03/06/2013 12:53 PM, Shaik Ameer Basha wrote:

This patch adds support for media device for EXYNOS5 SoCs.
The current media device supports the following ips to connect
through the media controller framework.

* MIPI-CSIS
   Support interconnection(subdev interface) between devices

* FIMC-LITE
   Support capture interface from device(Sensor, MIPI-CSIS) to memory
   Support interconnection(subdev interface) between devices

G-Scaler will be added later to the current media device.

* Gscaler: general scaler
   Support memory to memory interface
   Support output interface from memory to display device(LCD, TV)
   Support capture interface from device(FIMC-LITE, FIMD) to memory

--  media 0
   Camera Capture path consists of MIPI-CSIS, FIMC-LITE and G-Scaler
   ++ +---+ +-+
   | Sensor | --  | FIMC-LITE | --  | G-Scaler-capture |
   ++ +---+ +-+

   ++ +---+ +---+ +-+
   | Sensor | --  | MIPI-CSIS | --  | FIMC-LITE | --  | G-Scaler-capture |
   ++ +---+ +---+ +-+

Signed-off-by: Shaik Ameer Bashashaik.am...@samsung.com
---
  drivers/media/platform/Kconfig   |1 +
  drivers/media/platform/Makefile  |1 +
  drivers/media/platform/exynos5-is/Kconfig|7 +
  drivers/media/platform/exynos5-is/Makefile   |4 +
  drivers/media/platform/exynos5-is/exynos5-mdev.c | 1309 ++
  drivers/media/platform/exynos5-is/exynos5-mdev.h |  107 ++
  6 files changed, 1429 insertions(+)
  create mode 100644 drivers/media/platform/exynos5-is/Kconfig
  create mode 100644 drivers/media/platform/exynos5-is/Makefile
  create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.c
  create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.h


...

diff --git a/drivers/media/platform/exynos5-is/exynos5-mdev.c 
b/drivers/media/platform/exynos5-is/exynos5-mdev.c
new file mode 100644
index 000..1158696
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/exynos5-mdev.c
@@ -0,0 +1,1309 @@
+/*
+ * S5P/EXYNOS4 SoC series camera host interface media device driver


EXYNOS5


+ * Copyright (C) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * Sylwester Nawrockis.nawro...@samsung.com


This is incorrect too, you should add your authorship and a note it
is based on other code, with a proper copyright notice.


+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#includelinux/bug.h
+#includelinux/device.h
+#includelinux/errno.h
+#includelinux/i2c.h
+#includelinux/kernel.h
+#includelinux/list.h
+#includelinux/module.h
+#includelinux/of.h
+#includelinux/of_platform.h
+#includelinux/of_device.h
+#includelinux/of_i2c.h
+#includelinux/pinctrl/consumer.h
+#includelinux/platform_device.h
+#includelinux/pm_runtime.h
+#includelinux/types.h
+#includelinux/slab.h
+#includemedia/v4l2-ctrls.h
+#includemedia/v4l2-of.h
+#includemedia/media-device.h
+
+#include exynos5-mdev.h
+
+#define dbg(fmt, args...) \
+   pr_debug(%s:%d:  fmt \n, __func__, __LINE__, ##args)
+
+static struct fimc_md *g_exynos_mdev;
+
+static int fimc_md_set_camclk(struct v4l2_subdev *sd, bool on);
+static int __fimc_md_set_camclk(struct fimc_md *fmd,
+   struct fimc_sensor_info *s_info,
+   bool on);
+/**
+ * fimc_pipeline_prepare - update pipeline information with subdevice pointers
+ * @fimc: fimc device terminating the pipeline
+ *
+ * Caller holds the graph mutex.
+ */
+static void fimc_pipeline_prepare(struct exynos5_pipeline0 *p,
+ struct media_entity *me)
+{
+   struct media_pad *pad =me-pads[0];


This will need to be changed to support subdevs with more than 2 pads.
I should post relevant patch this week.


+   struct v4l2_subdev *sd;
+   int i;
+
+   for (i = 0; i  IDX_MAX; i++)
+   p-subdevs[i] = NULL;
+
+   while (1) {
+
+   if (!(pad-flags  MEDIA_PAD_FL_SINK))
+   break;
+
+   /* source pad */
+   pad = media_entity_remote_source(pad);
+
+   if (pad != NULL)
+   pr_err(entity type: %d, entity name: %s\n,
+   media_entity_type(pad-entity), pad-entity-name);
+
+   if (pad == NULL ||
+   media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
+   break;
+
+   sd = media_entity_to_v4l2_subdev(pad-entity);
+
+   switch (sd-grp_id) {
+   case GRP_ID_FIMC_IS_SENSOR:
+   case GRP_ID_SENSOR:
+   p-subdevs[IDX_SENSOR] = sd;
+   break;
+

Re: [PATCH v3 1/2] i.MX27: Add clock support for SAHARA2.

2013-03-10 Thread Sascha Hauer 
On Sun, Mar 10, 2013 at 04:34:01PM +0800, Herbert Xu wrote:
  
   https://patchwork.kernel.org/patch/1817741/
  
   So the change above becomes unnecessary
  
  Very good. Then this patch can be safely dropped.
 
 So should I take this patch or not?

This clk patch, no. The sahara patch, yes, if it is fine for you.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V2] cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue

2013-03-10 Thread Viresh Kumar 
On 10 March 2013 23:58, Francesco Lavra francescolavra...@gmail.com wrote:
 On 03/07/2013 06:14 PM, Viresh Kumar wrote:
 +void bL_cpufreq_unregister(struct cpufreq_arm_bL_ops *ops)
 +{
 + if (arm_bL_ops != ops) {
 + pr_info(%s: Registered with: %s, can't unregister, exiting\n,
 + __func__, arm_bL_ops-name);
 + }

 The code is not doing what the info message says.

Yes, following is the improvement:

diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 8b8b07e..9d449cf 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -264,8 +264,9 @@ EXPORT_SYMBOL_GPL(bL_cpufreq_register);
 void bL_cpufreq_unregister(struct cpufreq_arm_bL_ops *ops)
 {
if (arm_bL_ops != ops) {
-   pr_info(%s: Registered with: %s, can't unregister, exiting\n,
+   pr_err(%s: Registered with: %s, can't unregister, exiting\n,
__func__, arm_bL_ops-name);
+   return;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v3 1/2] i.MX27: Add clock support for SAHARA2.

2013-03-10 Thread Herbert Xu 
On Mon, Mar 11, 2013 at 12:08:56AM +0100, Sascha Hauer wrote:
 On Sun, Mar 10, 2013 at 04:34:01PM +0800, Herbert Xu wrote:
   
https://patchwork.kernel.org/patch/1817741/
   
So the change above becomes unnecessary
   
   Very good. Then this patch can be safely dropped.
  
  So should I take this patch or not?
 
 This clk patch, no. The sahara patch, yes, if it is fine for you.

But will the second patch work fine without the first?

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH 1/5] ARM: dts: exynos5250-arndale: Add node entry for gpio-buttons

2013-03-10 Thread Kukjin Kim 
Tomasz Figa wrote:
 
 Hi,
 
 I'm wondering why Exynos5250 has not been migrated to use pinctrl yet.
 
 Support for it in pinctrl-samsung driver has been already merged, but I
 don't see any pinctrl nodes in exynos5250.dtsi.
 
 This is important because the legacy gpio-samsung support is going to be
 dropped, as it already happened in case of Exynos 4.
 
 CC'ing Thomas Abraham as he might know something.
 
Tushar and all,

I agree with Tomasz's opinion to support pinctrl instead of gpio on exynos5250
stuff.

Please re-submit with using pinctrl is in samsung tree.

If any problems, please let us know.

Thanks.

- Kukjin

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH 2/5] ARM: dts: exynos5250-arndale: Add PMIC node entry

2013-03-10 Thread Kukjin Kim 
amit daniel kachhap wrote:
 
 The V2 of this patch is posted with comments suggested by Anil and
 some missing LDO's.
 
OK, I see.

- Kukjin

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 2/2] hwmon: NTC: add IIO get channel and read support

2013-03-10 Thread Naveen Krishna Chatradhi 
This patch adds the support to work as a iio device.
iio_get_channel and iio_raw_read works.

During the probe ntc driver gets the respective channels of ADC
and uses iio_raw_read calls to get the ADC converted value.

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---

Still not sure about the read_uV function parameter change and placement.

There were a few CamelCase warnings during checkpatch run.
I can clean them if anyone insists.

 drivers/hwmon/ntc_thermistor.c   |   36 +-
 include/linux/platform_data/ntc_thermistor.h |7 -
 2 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index cfedbd3..1d31260 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -30,6 +30,11 @@
 
 #include linux/platform_data/ntc_thermistor.h
 
+#include linux/iio/iio.h
+#include linux/iio/machine.h
+#include linux/iio/driver.h
+#include linux/iio/consumer.h
+
 #include linux/hwmon.h
 #include linux/hwmon-sysfs.h
 
@@ -162,6 +167,28 @@ struct ntc_data {
char name[PLATFORM_NAME_SIZE];
 };
 
+static int ntc_adc_read(struct ntc_thermistor_platform_data *pdata)
+{
+   struct iio_channel *channel = pdata-chan;
+   unsigned int result;
+   int val, ret;
+
+   if (!channel)
+   return -EINVAL;
+
+   ret = iio_read_channel_raw(channel, val);
+   if (ret  0) {
+   pr_err(read channel() error: %d\n, ret);
+   return ret;
+   }
+
+   /* unit: mV */
+   result = pdata-pullup_uV * (s64) val;
+   result = 12;
+
+   return result;
+}
+
 #ifdef CONFIG_OF
 static void ntc_thermistor_parse_dt(struct ntc_thermistor_platform_data *pdata,
struct device_node *np)
@@ -173,6 +200,8 @@ static void ntc_thermistor_parse_dt(struct 
ntc_thermistor_platform_data *pdata,
pdata-connect = NTC_CONNECTED_POSITIVE;
else /* status change should be possible if not always on. */
pdata-connect = NTC_CONNECTED_GROUND;
+
+   pdata-read_uV = ntc_adc_read;
 }
 #else
 static void
@@ -317,7 +346,7 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
return data-pdata-read_ohm(data-pdev);
 
if (data-pdata-read_uV) {
-   read_uV = data-pdata-read_uV(data-pdev);
+   read_uV = data-pdata-read_uV(data-pdata);
if (read_uV  0)
return read_uV;
return get_ohm_of_thermistor(data, read_uV);
@@ -417,6 +446,8 @@ static int ntc_thermistor_probe(struct platform_device 
*pdev)
if (!data)
return -ENOMEM;
 
+   pdata-chan = iio_channel_get(pdev-dev, NULL);
+
data-dev = pdev-dev;
data-pdev = pdev;
data-pdata = pdata;
@@ -457,15 +488,18 @@ static int ntc_thermistor_probe(struct platform_device 
*pdev)
return 0;
 err_after_sysfs:
sysfs_remove_group(data-dev-kobj, ntc_attr_group);
+   iio_channel_release(pdata-chan);
return ret;
 }
 
 static int ntc_thermistor_remove(struct platform_device *pdev)
 {
struct ntc_data *data = platform_get_drvdata(pdev);
+   struct ntc_thermistor_platform_data *pdata = data-pdata;
 
hwmon_device_unregister(data-hwmon_dev);
sysfs_remove_group(data-dev-kobj, ntc_attr_group);
+   iio_channel_release(pdata-chan);
platform_set_drvdata(pdev, NULL);
 
return 0;
diff --git a/include/linux/platform_data/ntc_thermistor.h 
b/include/linux/platform_data/ntc_thermistor.h
index 18f3c3a..671d056 100644
--- a/include/linux/platform_data/ntc_thermistor.h
+++ b/include/linux/platform_data/ntc_thermistor.h
@@ -34,19 +34,24 @@ struct ntc_thermistor_platform_data {
 *
 * pullup_uV, pullup_ohm, pulldown_ohm, and connect are required to use
 * read_uV()
+* takes the platform data structure as the parameter
 *
 * How to setup pullup_ohm, pulldown_ohm, and connect is
 * described at Documentation/hwmon/ntc_thermistor
 *
 * pullup/down_ohm: 0 for infinite / not-connected
+*
+* iio_channel to communicate with the ADC which the
+* thermistor is using for conversion of the analog values.
 */
-   int (*read_uV)(struct platform_device *);
+   int (*read_uV)(struct ntc_thermistor_platform_data *);
int (*read_ohm)(struct platform_device *);
unsigned int pullup_uV;
 
unsigned int pullup_ohm;
unsigned int pulldown_ohm;
enum { NTC_CONNECTED_POSITIVE, NTC_CONNECTED_GROUND } connect;
+   struct iio_channel *chan;
 };
 
 #endif /* _LINUX_NTC_H */
-- 
1.7.9.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 1/2] hwmon: ntc: Add DT support to NTC thermistor driver

2013-03-10 Thread Naveen Krishna Chatradhi 
This patch adds the DT support to NTC driver to parse the
platform data.

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
 drivers/hwmon/ntc_thermistor.c |   93 
 1 file changed, 75 insertions(+), 18 deletions(-)

diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index d92b237..cfedbd3 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -26,6 +26,7 @@
 #include linux/math64.h
 #include linux/platform_device.h
 #include linux/err.h
+#include linux/of.h
 
 #include linux/platform_data/ntc_thermistor.h
 
@@ -37,6 +38,41 @@ struct ntc_compensation {
unsigned intohm;
 };
 
+static const struct platform_device_id ntc_thermistor_id[] = {
+   { ncp15wb473, TYPE_NCPXXWB473 },
+   { ncp18wb473, TYPE_NCPXXWB473 },
+   { ncp21wb473, TYPE_NCPXXWB473 },
+   { ncp03wb473, TYPE_NCPXXWB473 },
+   { ncp15wl333, TYPE_NCPXXWL333 },
+   { },
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id ntc_match[] = {
+   { .compatible = ntc,ncp15wb473, .data = (void *)TYPE_NCPXXWB473 },
+   { .compatible = ntc,ncp18wb473, .data = (void *)TYPE_NCPXXWB473 },
+   { .compatible = ntc,ncp21wb473, .data = (void *)TYPE_NCPXXWB473 },
+   { .compatible = ntc,ncp03wb473, .data = (void *)TYPE_NCPXXWB473 },
+   { .compatible = ntc,ncp15wl333, .data = (void *)TYPE_NCPXXWL333 },
+   { },
+};
+MODULE_DEVICE_TABLE(of, ntc_match);
+#endif
+
+/* Get NTC type either from device tree or platform data. */
+static enum ntc_thermistor_type thermistor_get_type
+   (struct platform_device *pdev)
+{
+   if (pdev-dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_node(of_match_ptr(ntc_match),
+   pdev-dev.of_node);
+   return (unsigned int)match-data;
+   }
+
+   return platform_get_device_id(pdev)-driver_data;
+}
+
 /*
  * A compensation table should be sorted by the values of .ohm
  * in descending order.
@@ -126,6 +162,27 @@ struct ntc_data {
char name[PLATFORM_NAME_SIZE];
 };
 
+#ifdef CONFIG_OF
+static void ntc_thermistor_parse_dt(struct ntc_thermistor_platform_data *pdata,
+   struct device_node *np)
+{
+   of_property_read_u32(np, pullup-uV, pdata-pullup_uV);
+   of_property_read_u32(np, pullup-ohm, pdata-pullup_ohm);
+   of_property_read_u32(np, pulldown-ohm, pdata-pulldown_ohm);
+   if (of_find_property(np, connected-positive, NULL))
+   pdata-connect = NTC_CONNECTED_POSITIVE;
+   else /* status change should be possible if not always on. */
+   pdata-connect = NTC_CONNECTED_GROUND;
+}
+#else
+static void
+static void ntc_thermistor_parse_dt(struct ntc_thermistor_platform_data *pdata,
+   struct device_node *np)
+{
+   return;
+}
+#endif
+
 static inline u64 div64_u64_safe(u64 dividend, u64 divisor)
 {
if (divisor == 0  dividend == 0)
@@ -313,9 +370,19 @@ static const struct attribute_group ntc_attr_group = {
 static int ntc_thermistor_probe(struct platform_device *pdev)
 {
struct ntc_data *data;
-   struct ntc_thermistor_platform_data *pdata = pdev-dev.platform_data;
+   struct device_node *np = pdev-dev.of_node;
+   struct ntc_thermistor_platform_data *pdata = NULL;
int ret = 0;
 
+   if (np) {
+   pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   ntc_thermistor_parse_dt(pdata, np);
+   } else
+   pdata = pdev-dev.platform_data;
+
if (!pdata) {
dev_err(pdev-dev, No platform init data supplied.\n);
return -ENODEV;
@@ -353,9 +420,9 @@ static int ntc_thermistor_probe(struct platform_device 
*pdev)
data-dev = pdev-dev;
data-pdev = pdev;
data-pdata = pdata;
-   strlcpy(data-name, pdev-id_entry-name, sizeof(data-name));
+   strncpy(data-name, dev_name(pdev-dev), PLATFORM_NAME_SIZE);
 
-   switch (pdev-id_entry-driver_data) {
+   switch (thermistor_get_type(pdev)) {
case TYPE_NCPXXWB473:
data-comp = ncpXXwb473;
data-n_comp = ARRAY_SIZE(ncpXXwb473);
@@ -365,9 +432,8 @@ static int ntc_thermistor_probe(struct platform_device 
*pdev)
data-n_comp = ARRAY_SIZE(ncpXXwl333);
break;
default:
-   dev_err(pdev-dev, Unknown device type: %lu(%s)\n,
-   pdev-id_entry-driver_data,
-   pdev-id_entry-name);
+   dev_err(pdev-dev, Unknown device type: %u\n,
+   thermistor_get_type(pdev));
return -EINVAL;
}
 
@@ -386,9 +452,8 @@ static int

Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board

2013-03-10 Thread Anil Kumar 
Hi Jon,

On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter jon-hun...@ti.com wrote:
 Adds basic device-tree support for OMAP3430 SDP board which has 256MB
 of RAM and uses the TWL4030 power management IC.

 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  arch/arm/boot/dts/Makefile |1 +
  arch/arm/boot/dts/omap3430-sdp.dts |   46 
 
  2 files changed, 47 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 9c62558..89013ed 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 omap3-beagle-xm.dtb \
 omap3-evm.dtb \
 omap3-tobi.dtb \
 +   omap3430-sdp.dtb \
 omap4-panda.dtb \
 omap4-panda-a4.dtb \
 omap4-panda-es.dtb \
 diff --git a/arch/arm/boot/dts/omap3430-sdp.dts 
 b/arch/arm/boot/dts/omap3430-sdp.dts
 new file mode 100644
 index 000..be0650d
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap3430-sdp.dts
 @@ -0,0 +1,46 @@
 +/*
 + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +/dts-v1/;
 +
 +/include/ omap3.dtsi
 +
 +/ {
 +   model = TI OMAP3430 SDP;
 +   compatible = ti,omap3430-sdp, ti,omap3;
 +
 +   memory {
 +   device_type = memory;
 +   reg = 0x8000 0x1000; /* 256 MB */
 +   };
 +};
 +
 +i2c1 {
 +   clock-frequency = 260;
 +
 +   twl: twl@48 {
 +   reg = 0x48;
 +   interrupts = 7; /* SYS_NIRQ cascaded to intc */
 +   interrupt-parent = intc;

No need of  interrupt-parent = intc as it is with root node
already.

Thanks,
Anil

[...]
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 1/9] ARM: i.MX28: define osc in DT

2013-03-10 Thread Shawn Guo 
On Fri, Mar 08, 2013 at 10:01:36AM +0100, Steffen Trumtrar wrote:
 From: Juergen Beisert j...@pengutronix.de
 
 Instead of hardcoding the ref_xtal in the clk driver, get it from the DT.
 
 Signed-off-by: Juergen Beisert j...@pengutronix.de
 Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
 ---
  arch/arm/boot/dts/imx28.dtsi | 11 +++
  drivers/clk/mxs/clk-imx28.c  | 16 +++-
  2 files changed, 26 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
 index 7ba4966..b9e3712 100644
 --- a/arch/arm/boot/dts/imx28.dtsi
 +++ b/arch/arm/boot/dts/imx28.dtsi
 @@ -37,6 +37,17 @@
   };
   };
  
 + clocks {
 + #address-cells = 1;
 + #size-cells = 0;
 +
 + osc24m: system-oscillator {
 + compatible = fixed-clock;
 + #clock-cells = 0;
 + clock-frequency = 2400;
 + };
 + };
 +
   apb@8000 {
   compatible = simple-bus;
   #address-cells = 1;
 diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
 index 76ce6c6..01048b5 100644
 --- a/drivers/clk/mxs/clk-imx28.c
 +++ b/drivers/clk/mxs/clk-imx28.c
 @@ -158,7 +158,21 @@ int __init mx28_clocks_init(void)
  
   clk_misc_init();
  
 - clks[ref_xtal] = mxs_clk_fixed(ref_xtal, 2400);
 + /* retrieve the crystal's frequencies from device tree */
 + for_each_compatible_node(np, NULL, fixed-clock) {
 + u32 rate;
 +
 + if (of_property_read_u32(np, clock-frequency, rate))
 + continue;
 +
 + if (of_device_is_compatible(np, fsl,mxs-system))

Use node name to save the custom compatible.

But more fundamental question - do you really have a imx28 system
running a ref_xtal that is not 24 MHz?  Or does imx28 actually support
any other frequency ref_xtal other than 24 MHz?

Shawn

 + clks[ref_xtal] = mxs_clk_fixed(ref_xtal, rate);
 + }
 +
 + /* if not set, guess their frequency */
 + if (clks[ref_xtal] == NULL)
 + clks[ref_xtal] = mxs_clk_fixed(ref_xtal, 2400);
 +
   clks[pll0] = mxs_clk_pll(pll0, ref_xtal, PLL0CTRL0, 17, 48000);
   clks[pll1] = mxs_clk_pll(pll1, ref_xtal, PLL1CTRL0, 17, 48000);
   clks[pll2] = mxs_clk_pll(pll2, ref_xtal, PLL2CTRL0, 23, 5000);
 -- 
 1.8.2.rc2
 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems

2013-03-10 Thread Mitch Bradley 
On 3/9/2013 8:55 PM, Jason Gunthorpe wrote:
 On Sat, Mar 09, 2013 at 06:52:13PM -1000, Mitch Bradley wrote:
 
 Okay, I think I finally get it.  The Marvell root port bridge setup
 registers look like standard config headers, even though they aren't
 really in config space (because you need a different access method for
 them, compared to real config accesses to downstream devices).
 
 Well, thats pretty close. On Marvell the MMIO space has a lot of
 stuff, some of it is config related, lots of it isn't. In fact most of
 it isn't. Tegra is different, the MMIO region is exactly the config
 space of the root port bridge.
 
 Tegra could probably happily and sanely do as you've described (well,
 see below), but it is wonky for Marvell. It looks like there are more
 drivers coming that have this need - so I had hoped for a general
 answer to the 'per-port MMIO space' problem that is unrelated to the
 MMIO spaces role in config access.
 
 So, in order for the common code that enumerates the PCI bus to work,
 you need to spoof the config accesses so that when you try to access
 those particular pseudo config headers, it uses the MMIO method
 instead of the real config access method.
 
 There are rules for config access in both Tegra and Marvell that are
 not trivial. Again, the driver takes are of this and all Linux sees is
 a nice compliant config space.

Thanks for explaining that.

So it seems that we are faced with two requirements that are somewhat at
odds with one another.

1) Some of the root port bridge registers have to be accessed via config
space access functions so common PCI enumeration code will work.  To
represent this with the usual DT structure, the top root-complex needs
to define a 3/2 address space so its children
can have standard PCI reg properties.  Presumably, if those registers
are being programmed by common code, Marvell-specific code would
restrict its role to setting up config-space access functions, leaving
the actual touching of the registers to the common code.

2) Marvell chips have additional non-standard per-root-port registers
that generic PCI code would not understand.  These registers would be
touched only by Marvell-specific code.

The two kinds of registers are adjacent in MMIO space.  However, unless
I am misunderstanding this MV78230 manual, the highest config header
register index is 0x134, well below the 0x1000 size limit of a PCIe
config header.  Some of the extra registers are at 0x8xx, and others are
above 0x1800.

That suggests the following:

For the config header registers that use generic PCI code, use a
ranges entry to associate (pass through) MMIO addresses to the config
header portion of the register block.  This parameterizes the code that
sets up the special-case PCI config access.  That specification
technique is general and could be used not only for the Marvell case,
but also for any other chip that has some number of direct-mapped config
headers.

For requirement (2), the top node has a reg property listing the
portions of the address space that are consumed by the driver at the top
level instead of being passed through to the PCI addressing domain.  E.g.

  reg = 0xd0040800 0x1800, 0xd0080800 0x1800;

Thus we have accurately described the two aspects of the true situation.
 The PCI-compliant config header registers are passed through to the
child nodes where they can be dealt with in the normal PCI fashion.  The
non-PCI-compliant register footprint lives within the Marvell-specific
root-complex driver.

The root-complex driver presumably needs associate non-compliant
register blocks with specific child nodes.  That can be done by
requiring that the reg entries are in the same order as the config-space
ranges entries.

Anticipating the possible objection that ARM's 0x1000-byte page size
does not permit virtual-to-physical mapping at 0x800-byte granularity:
The device tree does not guarantee that reg entries are page-aligned; it
simply tries to describe the reality, even though it might be messy.

 
 If that is indeed the case, them I would vote for a slight modification
 of the intermediate patch that I cited earlier - the one in which the
 ranges property includes translations from those special config
 addresses into CPU addresses.  The modification is to fix the sizes,
 changing 0x2000 to 0x800, so those ranges entries do not overlap in the
 child address domain.

BTW I have completely changed my mind about the overlap thing.

I said that it was bogus to use size=0x2000 for a config space header.
 That was based on an interpretation - which I now dislike - of the
meaning of 3-cell config addresses.  By that old interpretation,
size=0x800 would also be bogus, because bits 10-8 of the config address
are for the function number.

Consider the following question, which I have never previously
considered, at least not explicitly:

Q: What would be the 3-cell representation of the Command/Status
register address (offset 4) in device 1, function 1?

One