Re: [PATCH v9 07/16] iommu/exynos: support for device tree

[Cho KyongHo]

On Fri, 09 Aug 2013 00:41:25 +0200, Tomasz Figa wrote:
> Hi KyongHo,
> 
> On Thursday 08 of August 2013 18:38:49 Cho KyongHo wrote:
> > This commit adds device tree support for System MMU.
> > This also include the following changes and enhancements:
> > 
> > * use managed device helper functions.
> > Simplyfies System MMU device driver.
> > 
> > * use only a single clock descriptor.
> > System MMU device descriptor is seperate if it is imposible to make
> > a single clock descriptor to make a device descriptor for a group of
> > System MMUs.
> > 
> > * removed dbgname member from sysmmu_drvdata structure.
> > debugging kernel message for a System MMU is distinguisheable with the
> > name of device descroptors.
> 
> Please put all these three changes in separate patches. This patch is hard 
> to review with all the changes mixed together...
> 

Ok.

> In addition, I believe this is the patch that should be adding device tree 
> binding documentation, not the 6/16 one, as this is where actually support 
> for this binding gets added to the kernel.

Oh, I didn't know that devicetree binding description and implementation need
to be in the same patch.
I will do as you advised.

> 
> > Signed-off-by: Cho KyongHo 
> > ---
> >  drivers/iommu/Kconfig|5 +-
> >  drivers/iommu/exynos-iommu.c |  186
> > - 2 files changed, 75
> > insertions(+), 116 deletions(-)
> > 
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 820d85c..9ad45f1 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -168,16 +168,15 @@ config TEGRA_IOMMU_SMMU
> > 
> >  config EXYNOS_IOMMU
> > bool "Exynos IOMMU Support"
> > -   depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU
> > +   depends on ARCH_EXYNOS
> > select IOMMU_API
> > +   default n
> > help
> >   Support for the IOMMU(System MMU) of Samsung Exynos application
> >   processor family. This enables H/W multimedia accellerators to 
> see
> >   non-linear physical memory chunks as a linear memory in their
> >   address spaces
> > 
> > - If unsure, say N here.
> > -
> >  config EXYNOS_IOMMU_DEBUG
> > bool "Debugging log for Exynos IOMMU"
> > depends on EXYNOS_IOMMU
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index a318049..0ee73e8 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > 
> >  #include 
> >  #include 
> > @@ -170,15 +171,14 @@ struct sysmmu_drvdata {
> > struct list_head node; /* entry of exynos_iommu_domain.clients */
> > struct device *sysmmu;  /* System MMU's device descriptor */
> > struct device *dev; /* Owner of system MMU */
> > -   char *dbgname;
> > int nsfrs;
> > -   void __iomem **sfrbases;
> > -   struct clk *clk[2];
> > +   struct clk *clk;
> > int activations;
> > rwlock_t lock;
> > struct iommu_domain *domain;
> > sysmmu_fault_handler_t fault_handler;
> > unsigned long pgtable;
> > +   void __iomem *sfrbases[0];
> >  };
> > 
> >  static bool set_sysmmu_active(struct sysmmu_drvdata *data)
> > @@ -385,8 +385,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void
> > *dev_id) if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
> > __raw_writel(1 << itype, data->sfrbases[i] + 
> REG_INT_CLEAR);
> > else
> > -   dev_dbg(data->sysmmu, "(%s) %s is not handled.\n",
> > -   data->dbgname, sysmmu_fault_name[itype]);
> > +   dev_dbg(data->sysmmu, "%s is not handled.\n",
> > +   sysmmu_fault_name[itype]);
> > 
> > if (itype != SYSMMU_FAULT_UNKNOWN)
> > sysmmu_unblock(data->sfrbases[i]);
> > @@ -410,10 +410,8 @@ static bool __exynos_sysmmu_disable(struct
> > sysmmu_drvdata *data) for (i = 0; i < data->nsfrs; i++)
> > __raw_writel(CTRL_DISABLE, data->sfrbases[i] + 
> REG_MMU_CTRL);
> > 
> > -   if (data->clk[1])
> > -   clk_disable(data->clk[1]);
> > -   if (data->clk[0])
> > -   clk_disable(data->clk[0]);
> > +   if (data->clk)
> > +   clk_disable(data->clk);
> > 
> > disabled = true;
> > data->pgtable = 0;
> > @@ -422,10 +420,10 @@ finish:
> > write_unlock_irqrestore(&data->lock, flags);
> > 
> > if (disabled)
> > -   dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
> > +   dev_dbg(data->sysmmu, "Disabled\n");
> > else
> > -   dev_dbg(data->sysmmu, "(%s) %d times left to be 
> disabled\n",
> > -   data->dbgname, data->activations);
> > +   dev_dbg(data->sysmmu, "%d times left to be disabled\n",
> > +   data->activations);
> > 
> > return disabled;
> >  }
> > @@ -452,14 +450,12 @@ static int __exynos_sysmmu_enable(struct
> > sysmmu_drvdata *data, ret = 1;
> > }
> > 
> > -   dev_dbg(data->

Re: [PATCH v9 06/16] ARM: dts: Add description of System MMU of Exynos SoCs

[Cho KyongHo]

On Fri, 09 Aug 2013 00:26:51 +0200, Tomasz Figa wrote:
> Hi KyongHo,
> 
> On Thursday 08 of August 2013 18:38:35 Cho KyongHo wrote:
> > Signed-off-by: Cho KyongHo 
> > ---
> >  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
> >  arch/arm/boot/dts/exynos4.dtsi |  122 
> >  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
> >  arch/arm/boot/dts/exynos4x12.dtsi  |   82 ++
> >  arch/arm/boot/dts/exynos5250.dtsi  |  290
> >  5 files changed, 622 insertions(+), 0 deletions(-)
> >  create mode 100644
> > Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > new file mode 100644
> > index 000..92f0a33
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > @@ -0,0 +1,103 @@
> > +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management
> > Unit) +
> > +Samsung's Exynos architecture contains System MMU that enables
> > scattered +physical memory chunks visible as a contiguous region to
> > DMA-capable peripheral +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS
> > and so forth.
> > +
> > +System MMU is a sort of IOMMU and support identical translation table
> > format to +ARMv7 translation tables with minimum set of page properties
> > including access +permissions, shareability and security protection. In
> > addition, System MMU has +another capabilities like L2 TLB or
> > block-fetch buffers to minimize translation +latency.
> > +
> > +A System MMU is dedicated to a single master peripheral device.  Thus,
> > it is +important to specify the correct System MMU in the device node
> > of its master +device. Whereas a System MMU is dedicated to a master
> > device, the master device +may have more than one System MMU.
> 
> This paragraph is still not clear. What about something among these lines:
> 
Yes. It is my fault.
It is still unchanged... even though Grant sugessted clear and simple sentence.
It must be changed :)

> System MMUs are in many to one relation with peripheral devices, i.e. 
> single peripheral device might have multiple System MMUs (usually one for 
> each bus master), but one System MMU can handle only one peripheral 
> device. The relation between a System MMU and the peripheral device it 
> handles needs to be defined in device node of this peripheral device.
> 

That looks good to me.
Please let me use your sentences.

> > +Required properties:
> > +- compatible: Should be "samsung,exynos4210-sysmmu"
> > +- reg: A tuple of base address and size of System MMU registers.
> > +- interrupt-parent: The phandle of the interrupt controller of System
> > MMU +- interrupts: A tuple of numbers that indicates the interrupt
> > source. 
> 
> interrupts: An interrupt specifier for interrupt signal of System MMU, 
> according to format defined for particular interrupt parent.

Yes.. it is not changed.. 
> 
> > +- clock-names: Should be "sysmmu" if the System MMU is needed
> > to gate its clock. +   Please refer to the following
> > documents:
> > +  Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +  Documentation/devicetree/bindings/clock/exynos4-clock.txt
> > +  Documentation/devicetree/bindings/clock/exynos5250-
> clock.txt
> > +  Optional "master" if the clock to the System MMU is gated 
> by
> > +  another gate clock other than "sysmmu". The System MMU 
> driver
> > +  sets "master" the parent of "sysmmu".
> > +  Exynos4 SoCs, there needs no "master" clocks.
> > +  Exynos5 SoCs, some System MMUs must have "master" clocks.
> > +- clocks: Required if the System MMU is needed to gate its clock.
> > + Please refer to the documents listed above.
> > +- samsung,power-domain: Required if the System MMU is needed to gate
> > its power. +  Please refer to the following document:
> > + Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> > +
> > +Required properties for the master peripheral devices:
> > +- iommu: phandles to the System MMUs of the device
> > +
> > +Examples:
> > +A System MMU is dedicated to a single master device.
> > +   gsc_0:  gsc@0x13e0 {
> 
> nit: duplicated space after gsc_0: and incorrect 0x prefix in node unit-
> address.
> 
Ok.

> > +   compatible = "samsung,exynos5-gsc";
> > +   reg = <0x13e0 0x1000>;
> > +   interrupts = <0 85 0>;
> > +   samsung,power-domain = <&pd_gsc>;
> > +   clocks = <&clock 256>;
> > +   clock-names = "gscl";
> > +   iommu = <&sysmmu_gsc1>;
> > +   };
> > +
> > +   sysmmu_gsc0: sysmmu@13E8 {
> > +   compatible = "samsung,exynos4210-sysmmu";
> > +   reg = <0x13E8 0x1000>;
> > +   interrupt-

Re: [PATCH v9 04/16] iommu/exynos: allocate lv2 page table from own slab

[Cho KyongHo]

On Thu, 08 Aug 2013 16:00:18 +0200, Tomasz Figa wrote:
> On Thursday 08 of August 2013 18:38:04 Cho KyongHo wrote:
> > Since kmalloc() does not guarantee that the allignment of 1KiB when it
> > allocates 1KiB, it is required to allocate lv2 page table from own
> > slab that guarantees alignment of 1KiB
> > 
> > Signed-off-by: Cho KyongHo 
> > ---
> >  drivers/iommu/exynos-iommu.c |   24 
> >  1 files changed, 20 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index d90e6fa..a318049 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -100,6 +100,8 @@
> >  #define REG_PB1_SADDR  0x054
> >  #define REG_PB1_EADDR  0x058
> > 
> > +static struct kmem_cache *lv2table_kmem_cache;
> > +
> >  static unsigned long *section_entry(unsigned long *pgtable, unsigned
> > long iova) {
> > return pgtable + lv1ent_offset(iova);
> > @@ -765,7 +767,8 @@ static void exynos_iommu_domain_destroy(struct
> > iommu_domain *domain)
> > 
> > for (i = 0; i < NUM_LV1ENTRIES; i++)
> > if (lv1ent_page(priv->pgtable + i))
> > -   kfree(__va(lv2table_base(priv->pgtable + i)));
> > +   kmem_cache_free(lv2table_kmem_cache,
> > +   __va(lv2table_base(priv->pgtable + i)));
> > 
> > free_pages((unsigned long)priv->pgtable, 2);
> > free_pages((unsigned long)priv->lv2entcnt, 1);
> > @@ -861,7 +864,7 @@ static unsigned long *alloc_lv2entry(unsigned long
> > *sent, unsigned long iova, if (lv1ent_fault(sent)) {
> > unsigned long *pent;
> > 
> > -   pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
> > +   pent = kmem_cache_zalloc(lv2table_kmem_cache, GFP_ATOMIC);
> > BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
> > if (!pent)
> > return ERR_PTR(-ENOMEM);
> > @@ -881,7 +884,7 @@ static int lv1set_section(unsigned long *sent,
> > phys_addr_t paddr, short *pgcnt)
> > 
> > if (lv1ent_page(sent)) {
> > BUG_ON(*pgcnt != NUM_LV2ENTRIES);
> > -   kfree(page_entry(sent, 0));
> > +   kmem_cache_free(lv2table_kmem_cache, page_entry(sent, 0));
> > *pgcnt = 0;
> > }
> > 
> > @@ -1082,10 +1085,23 @@ static int __init exynos_iommu_init(void)
> >  {
> > int ret;
> > 
> > +   lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
> > +   LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
> > +   if (!lv2table_kmem_cache) {
> > +   pr_err("%s: Failed to create kmem cache\n", __func__);
> > +   return -ENOMEM;
> > +   }
> > +
> > ret = platform_driver_register(&exynos_sysmmu_driver);
> > 
> > if (ret == 0)
> > -   bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
> > +   ret = bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
> > +
> > +   if (ret) {
> > +   pr_err("%s: Failed to register exynos-iommu driver.\n",
> > +   __func__);
> > +   kmem_cache_destroy(lv2table_kmem_cache);
> > +   }
> 
> What about making the return value handling here cleaner? For example:
> 
>   lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
>   LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
>   if (!lv2table_kmem_cache) {
>   ...
>   return -ENOMEM;
>   }
> 
>   ret = platform_driver_register(&exynos_sysmmu_driver);
>   if (ret) {
>   ...
>   goto err_destroy_kmem_cache;
>   }
> 
>   ret = bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
>   if (ret) {
>   ...
>   goto err_platform_unregister;
>   }
> 
>   return 0;
> 
> err_platform_unregister:
>   ...
> err_destroy_kmem_cache:
>   ...
>   return ret;
> }
> 

Thank you for suggestion.
I think you are worrying about missing the information who makes 'ret' non-zero.
Ok. I will process it separately.

thanks

KyongHo.
> Best regards,
> Tomasz
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 03/16] iommu/exynos: fix page table maintenance

[Cho KyongHo]

On Thu, 08 Aug 2013 15:54:50 +0200, Tomasz Figa wrote:
> On Thursday 08 of August 2013 18:37:43 Cho KyongHo wrote:
> > This prevents allocating lv2 page table for the lv1 page table entry
>   ^ What this is this this about? :)
> 
As you might indicate, 'this' means this patch :)

> > that already has 1MB page mapping. In addition, changed to BUG_ON
> > instead of returning -EADDRINUSE.
> 
> The change mentioned in last sentence should be a separate patch.
> 
Ok :)

> > Signed-off-by: Cho KyongHo 
> > ---
> >  drivers/iommu/exynos-iommu.c |   68
> > - 1 files changed, 40
> > insertions(+), 28 deletions(-)
> > 
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index d545a25..d90e6fa 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -52,11 +52,11 @@
> >  #define lv2ent_large(pent) ((*(pent) & 3) == 1)
> > 
> >  #define section_phys(sent) (*(sent) & SECT_MASK)
> > -#define section_offs(iova) ((iova) & 0xF)
> > +#define section_offs(iova) ((iova) & ~SECT_MASK)
> >  #define lpage_phys(pent) (*(pent) & LPAGE_MASK)
> > -#define lpage_offs(iova) ((iova) & 0x)
> > +#define lpage_offs(iova) ((iova) & ~LPAGE_MASK)
> >  #define spage_phys(pent) (*(pent) & SPAGE_MASK)
> > -#define spage_offs(iova) ((iova) & 0xFFF)
> > +#define spage_offs(iova) ((iova) & ~SPAGE_MASK)
> > 
> >  #define lv1ent_offset(iova) ((iova) >> SECT_ORDER)
> >  #define lv2ent_offset(iova) (((iova) & 0xFF000) >> SPAGE_ORDER)
> > @@ -856,13 +856,15 @@ finish:
> >  static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long
> > iova, short *pgcounter)
> >  {
> > +   BUG_ON(lv1ent_section(sent));
> 
> Is this condition really a critical one, to the point that the system 
> should not continue execution?
> 
Discussed with Grant. He thought that creating mapping on a valid mapping
is just a BUG and I finally agreed with him. Is there a case that the condition
in BUG_ON is true intentionally?

> > +
> > if (lv1ent_fault(sent)) {
> > unsigned long *pent;
> > 
> > pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
> > BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
> > if (!pent)
> > -   return NULL;
> > +   return ERR_PTR(-ENOMEM);
> > 
> > *sent = mk_lv1ent_page(__pa(pent));
> > *pgcounter = NUM_LV2ENTRIES;
> > @@ -875,15 +877,11 @@ static unsigned long *alloc_lv2entry(unsigned long
> > *sent, unsigned long iova,
> > 
> >  static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short
> > *pgcnt) {
> > -   if (lv1ent_section(sent))
> > -   return -EADDRINUSE;
> > +   BUG_ON(lv1ent_section(sent));
> 
> Ditto.
> 
> > if (lv1ent_page(sent)) {
> > -   if (*pgcnt != NUM_LV2ENTRIES)
> > -   return -EADDRINUSE;
> > -
> > +   BUG_ON(*pgcnt != NUM_LV2ENTRIES);
> 
> Ditto.
> 
> > kfree(page_entry(sent, 0));
> > -
> > *pgcnt = 0;
> > }
> > 
> > @@ -894,24 +892,24 @@ static int lv1set_section(unsigned long *sent,
> > phys_addr_t paddr, short *pgcnt) return 0;
> >  }
> > 
> > +static void clear_page_table(unsigned long *ent, int n)
> > +{
> > +   if (n > 0)
> > +   memset(ent, 0, sizeof(*ent) * n);
> > +}
> 
> I don't see the point of creating this function. It seems to be used only 
> once, in addition with a constant as n, so the check for n > 0 is 
> unnecessary.
> 
> And even if there is a need for this change, it should be done in separate 
> patch, as this one is not about stylistic changes, but fixing page table 
> maintenance (at least based on your commit message).
> 

I know what you are concerning about.
It was introduced in v8 patches to recover previous fault entries before
returning -EADDRINUSE. It is still remained though "return -EADDRINUSE"
is changed into BUG_ON().
I also think that it needs to be removed.

> >  static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t
> > size, short *pgcnt)
> >  {
> > if (size == SPAGE_SIZE) {
> > -   if (!lv2ent_fault(pent))
> > -   return -EADDRINUSE;
> > -
> > +   BUG_ON(!lv2ent_fault(pent));
> 
> Ditto.
> 
> > *pent = mk_lv2ent_spage(paddr);
> > pgtable_flush(pent, pent + 1);
> > *pgcnt -= 1;
> > } else { /* size == LPAGE_SIZE */
> > int i;
> > for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
> > -   if (!lv2ent_fault(pent)) {
> > -   memset(pent, 0, sizeof(*pent) * i);
> > -   return -EADDRINUSE;
> > -   }
> > -
> > +   BUG_ON(!lv2ent_fault(pent));
> 
> Ditto.
> 
> > *pent = mk_lv2ent_lpage(paddr);
> > }
> > pgtable_flush(pent - SPAGES_PER_LPAGE, pent);
> > @@ -944,17 +942,16 @@ static int exynos_iommu_map(struct iommu_domain
> > *domain, unsigne

Re: [PATCH v9 01/16] iommu/exynos: do not include removed header

[Cho KyongHo]

On Thu, 08 Aug 2013 15:42:24 +0200, Tomasz Figa wrote:
> Hi KyongHo,
> 
> On Thursday 08 of August 2013 18:37:25 Cho KyongHo wrote:
> > This commit remove  which is removed.
> 
> I would prefer a more meaningful commit message, something among following 
> lines:
> 
> 8<---
> Commit 25e9d28d92 (ARM: EXYNOS: remove system mmu initialization from 
> exynos tree) removed arch/arm/mach-exynos/mach/sysmmu.h header without 
> removing remaining use of it from exynos-iommu driver, thus causing a 
> compilation error.
> 
> This patch fixes the error by removing respective include line from exynos-
> iommu.c.
> --->8
> 

Ok.

> Also a sentence explaining why linux/kernel.h header must be included would 
> be nice.
> 
> > Signed-off-by: Cho KyongHo 
> 
> Please note that as far as I'm aware of, tags should be made using western 
> name writing convention, i.e. starting with first name.
> 

Oh, I didn't think that the order of family/given names are the matter.
I don't care about changing the order.

Thanks.

KyongHo.

> Best regards,
> Tomasz
> 
> > ---
> >  drivers/iommu/exynos-iommu.c |3 +--
> >  1 files changed, 1 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index 3f32d64..233f382 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -12,6 +12,7 @@
> >  #define DEBUG
> >  #endif
> > 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -29,8 +30,6 @@
> >  #include 
> >  #include 
> > 
> > -#include 
> > -
> >  /* We does not consider super section mapping (16MB) */
> >  #define SECT_ORDER 20
> >  #define LPAGE_ORDER 16
--
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 v9 02/16] iommu/exynos: add missing cache flush for removed page table entries

[Cho KyongHo]

On Thu, 08 Aug 2013 15:44:09 +0200, Tomasz Figa wrote:
> On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote:
> > This commit adds cache flush for removed small and large page entries
> > in exynos_iommu_unmap(). Missing cache flush of removed page table
> > entries can cause missing page fault interrupt when a master IP
> > accesses an unmapped area.
> > 
> > Tested-by: Grant Grundler 
> > Signed-off-by: Cho KyongHo 
> > ---
> >  drivers/iommu/exynos-iommu.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index 233f382..d545a25 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct
> > iommu_domain *domain, if (lv2ent_small(ent)) {
> > *ent = 0;
> > size = SPAGE_SIZE;
> > +   pgtable_flush(ent, ent + 1);
> > priv->lv2entcnt[lv1ent_offset(iova)] += 1;
> > goto done;
> > }
> > @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct
> > iommu_domain *domain, BUG_ON(size < LPAGE_SIZE);
> > 
> > memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
> > +   pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
> > 
> > size = LPAGE_SIZE;
> > priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;
> 
> Looks reasonable.
> 
> Reviewed-by: Tomasz Figa 
> 

Thanks.

KyongHo.
> Best regards,
> Tomasz
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: dw_mmc: Does anyone use multiple slots?

[Seungwon Jeon]

On Fri, August 09, 2013, Chris Ball wrote:
> On Fri, Aug 09 2013, Olof Johansson wrote:
> > On Thu, Aug 8, 2013 at 5:16 PM, Doug Anderson  wrote:
> >
> >> I guess my overall question is: if there are no actual implementations
> >> of multislot, shouldn't we kill it and simplify the code a whole lot?
> >> If someone out there has a real multislot device they can step back in
> >> and do it more correctly?
> >>
> >> Of course we need to find someone to actually go through and do the
> >> killing of multislot, but finding that person might be easier if there
> >> was some agreement that it was good to do.
> >
> > There clearly seems to be no in-tree users of multislot. If someone
> > new comes in, we have the code in the history and can revert the
> > removal (or at least use it as reference for re-introduction).
> >
> > I vote for removing it. It adds really annoying complexity for
> > something that nobody uses.
> 
> I agree with Olof, for what it's worth.  (The maintainers of the
> driver are Jaehoon and Seungwon, though.)

I feel like there is no actual use case for that though origin Synopsys IP 
supports.
Multi-slot  might be not useful in terms of performance because shared bus 
should be allowed.
(At least this is the way I see it, though)
As Exynos's host does so, other hosts which are introduced in Linux seems use 
one card per host.
If it's really not found now, I could agree on this topic.

Thanks,
Seungwon Jeon

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling

[Julius Werner]

> Sorry, I don't understand what is not implemented. Without your patch, the
> PHY driver handles both PMU registers of Exynos4.

I don't have an Exynos4 to actually test this, so please let me know
if I'm missing something here... but in order to hit the right HOST
PHY register in the current upstream code, the Exynos4 code would need
to have a hostphy_reg_offset of 4 somewhere in its
samsung_usbphy_drvdata. In my latest checkout of Linus' tree (6c2580c)
it does not (only Exynos5 sets that attribute), so it would default to
0 (thereby actually hitting the DEVICE register).

If you want I can gladly provide another change on top of my patchset
to fix that in the future... but it looks to me like it had been
broken anyway for now.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs

[Cho KyongHo]

On Thu, 08 Aug 2013 22:43:43 +0100, Will Deacon wrote:
> On Thu, Aug 08, 2013 at 10:38:10PM +0100, Tomasz Figa wrote:
> > On Thursday 08 of August 2013 08:09:49 Rob Herring wrote:
> > > On Thu, Aug 1, 2013 at 8:05 AM, Cho KyongHo  
> > wrote:
> > > > Should this align with ARM System MMU bindings?
> > > > System MMU in Exynos SoC is different from ARM System MMU.
> > > > It does not follows the specifications of ARM System MMU.
> > > 
> > > I'm not saying the h/w is the same or even the same spec, but how you
> > > describe a master to iommu connection needs to be done in the same
> > > way. This should be done in the same way for ALL iommu's. And if what
> > > is defined does not work for you, then we need to understand that and
> > > fix the binding now.
> > 
> > +1
> > 
> > All IOMMUs should use a generic IOMMU Device Tree bindings (and in 
> > general, the same should be true for all Device Tree bindings).
> > 
> > This means that if we already have some bindings for IOMMU, then they 
> > should be reused if possible or extended if there is anything missing.
> > 
> > Of course there might be things that such generic bindings can't specify. 
> > In this case device-specific properties can be introduced, but this is 
> > last resort.
> 
> I'm also happy to discuss and/or review bindings in light of what we did for
> the ARM SMMU.
> 
> Will

Rob, I now understood what you are talking about.
Do you mean the binding description is lack of details about connection
betwen  System MMU and its master?

thanks.

KyongHo.
--
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 v9 00/16] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

[Cho KyongHo]

On Thu, 08 Aug 2013 14:13:57 +0200, Tomasz Figa wrote:

> Hi KyongHo,
> 
> Just a little hint for future:
> 
> To make reviewing your patches easier, please send all patches (01 and 
> further) as a follow up (reply) to cover letter of the series (patch 00).
> 
> This can be achieved by using --thread switch of git send-email for 
> example.
> 

Thank you for advice.
However, git send-email and something like that is prohibitted by the
security policy of my company :(
I used an email client in windows O/S.

I need more consideration to the patches are sent in the order of patches.

Thank you.

KyongHo.

> Best regards,
> Tomasz
> 
> On Thursday 08 of August 2013 18:37:10 Cho KyongHo wrote:
> > The current exynos-iommu(System MMU) driver does not work autonomously
> > since it is lack of support for power management of peripheral blocks.
> > For example, MFC device driver must ensure that its System MMU is
> > disabled before MFC block is power-down not to invalidate IOTLB in the
> > System MMU when I/O memory mapping is changed. Because a System MMU
> > resides in the same H/W block, access to control registers of System MMU
> > while the H/W block is turned off must be prohibited.
> > 
> > This set of changes solves the above problem with setting each System
> > MMUs as the parent of the device which owns the System MMU to receive
> > the information when the device is turned off or turned on.
> > 
> > Another big change to the driver is the support for devicetree.
> > The bindings for System MMU is described in
> > Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
> > 
> > In addition, this patchset also includes several bug fixes and
> > enhancements of the current driver.
> > 
> > Change log:
> > v9:
> > - Rebased on the following branches
> >   git.linaro.org/git-ro/people/mturquette/linux.git/clk-next
> >  
> > git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/samsung-
> > next git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > (3.11-rc4) - Split "add bus notifier for registering System MMU" into 5
> > patches - Call clk_prepare() that was missing in v8.
> > - Fixed base address of sysmmu_tv in exynos4210.dtsi
> > - BUG_ON() instead of return -EADDRINUSE when trying mapping on an mapped
> > area - Moved camif_top to 317 in drivers/clk/samsung/clk-exynos5250.c -
> > Removed 'iommu' property from 'codec'(mfc) node
> > - Does not make 'master' clock to be the parent of 'sysmmu' clock.
> >'master' clock is enabled before accessing control registers of System
> > MMU and disabled after the access.
> > 
> > v8:
> > - Reordered patch list: moved "change rwloc to spinlock" to the last.
> > - Fixed remained bug in "fix page table maintenance".
> > - Always return 0 from exynos_iommu_attach_device().
> > - Removed prefetch buffer setting when System MMU is enabled
> >   due to the restriction of prefetch buffers:
> >   A prefetch buffer must not hit from more than one DMA.
> >   For instance with GScalers, if a single prefetch buffer is initialized
> >   with 0x0 ~ 0x and a GScaler works on source buffer at
> > 0x1000 and target buffer @ 0x2000, the System MMU may be got
> > deadlock. Clients must initialize prefetch buffers with custom function
> > defined in exynos-iommu drivers whenever they need to enable prefetch
> > buffers. - The clock of System MMU has no relationship with the clock of
> > its master H/W. The clock of master H/W is always enabled when
> > exynos-iommu driver needs to access MMIO area and disabled as soon as
> > the access finishes. - Removed err_page variable used in
> > exynos_iommu_unmap() in the previous patch "fix page table maintenance".
> > - Split a big patch "add bus notifier for registering System MMU".
> >Extracted the following 2 patches: 9/12 and 10/12.
> > - And some additional fixes...
> > 
> > v7:
> > - Rebased on the stable 3.10
> > - Registered PM domains and gate clocks with DT
> > - Changed connection method between a System MMU and its master H/W
> >'mmu-master' property in the node of System MMU
> >--> 'iommu' property in the node of master H/W
> > - Marking device descriptor of master H/W of a System MMU with bus
> > notifier. - Power management (PM_RUNTIME, PM_SLEEP) of System MMUs with
> > gpd_dev_ops of Generic IO Powerdomain. gpd_dev_ops are set to the master
> > H/Ws before they are probed in the bus notifier.
> > - Removed additional debugging features like debugfs entries and
> >version names.
> > - Removed support for advanced features of System MMU 3.2 and 3.3
> >the current IOMMU API cannot handle the feature
> >   (A kind of L2 TLB that fetches several consequence page table entries.
> >It must be initialized by the driver of master H/W whenever it works.)
> > 
> > v6:
> > - Rebased on the branch, next/iommu-exynos of
> >   git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> > 
> > v5:
> > - new bugfix: patch 01
> > - Reordered patches
> >   * patch 01 

Re: dw_mmc: Does anyone use multiple slots?

[Chris Ball]

Hi,

On Fri, Aug 09 2013, Olof Johansson wrote:
> On Thu, Aug 8, 2013 at 5:16 PM, Doug Anderson  wrote:
>
>> I guess my overall question is: if there are no actual implementations
>> of multislot, shouldn't we kill it and simplify the code a whole lot?
>> If someone out there has a real multislot device they can step back in
>> and do it more correctly?
>>
>> Of course we need to find someone to actually go through and do the
>> killing of multislot, but finding that person might be easier if there
>> was some agreement that it was good to do.
>
> There clearly seems to be no in-tree users of multislot. If someone
> new comes in, we have the code in the history and can revert the
> removal (or at least use it as reference for re-introduction).
>
> I vote for removing it. It adds really annoying complexity for
> something that nobody uses.

I agree with Olof, for what it's worth.  (The maintainers of the
driver are Jaehoon and Seungwon, though.)

Thanks,

- Chris.
-- 
Chris Ball  
--
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 v9 05/16] clk: exynos: add gate clock descriptions of System MMU

[Cho KyongHo]

On Thu, 08 Aug 2013 13:40:13 +0200, Tomasz Figa wrote:

> On Thursday 08 of August 2013 13:17:34 Sylwester Nawrocki wrote:
> > On 08/08/2013 11:38 AM, Cho KyongHo wrote:
> > > This adds gate clocks of all System MMUs and their master IPs
> > > that are not apeared in clk-exynos5250.c
> > > Also fixes GATE_IP_ACP to 0x18800 and changed GATE_DA to GATE
> > > for System MMU clocks in clk-exynos4.c
> > > 
> > > Signed-off-by: Cho KyongHo 
> > > ---
> > > 
> > >  .../devicetree/bindings/clock/exynos5250-clock.txt |   26 +
> > >  drivers/clk/samsung/clk-exynos4.c  |   27 +++--
> > >  drivers/clk/samsung/clk-exynos5250.c   |   57
> > >   3 files changed, 82 insertions(+), 28
> > >  deletions(-)
> > 
> > [...]
> > 
> > > @@ -349,19 +358,26 @@ static struct samsung_gate_clock
> > > exynos5250_gate_clks[] __initdata = {> 
> > >   GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
> > >   GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
> > >   GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
> > > 
> > > - GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
> > > - GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> > > - GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> > > - GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> > > + GATE(smmu_gscl0, "smmu_gscl0", "none", GATE_IP_GSCL, 7, 0, 0),
> > > + GATE(smmu_gscl1, "smmu_gscl1", "none", GATE_IP_GSCL, 8, 0, 0),
> > > + GATE(smmu_gscl2, "smmu_gscl2", "none", GATE_IP_GSCL, 9, 0, 0),
> > > + GATE(smmu_gscl3, "smmu_gscl3", "none", GATE_IP_GSCL, 10, 0, 0),
> > 
> > Why are the smmu clocks' parent clocks removed ? Shouldn't both the
> > gscaler gate clock and the gscaler smmu clock be still same, as it is in
> > case of exynos4 ?
> 
> I agree with Sylwester.
> 
> In fact, it is not a valid clock setup. A valid clock must be either root 
> clock (indicated by appropriate clock flag and specified frequency) or have 
> a valid parent.
> 

I thought that it does not require parent clock since it is just a gating clock.
Let me check it again.

Thank you.
> Best regards,
> Tomasz
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 06/16] ARM: dts: Add description of System MMU of Exynos SoCs

[Cho KyongHo]

On Thu, 08 Aug 2013 12:45:34 +0200, Sylwester Nawrocki wrote:

> Hi,
> 
> On 08/08/2013 11:38 AM, Cho KyongHo wrote:
> 
> How about something along the lines of:
> 
> "This patch adds dts entries for the SYSMMU devices found on Exynos4
> and Exynos5 SoC series and the SYSMMU binding documentation."
> 
> instead of this empty changelog ?

Ok. I thought that the title of this patch is self-explanatory.
But I agree with you this needs more specific description.

> 
> > Signed-off-by: Cho KyongHo 
> > ---
> >  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
> >  arch/arm/boot/dts/exynos4.dtsi |  122 
> >  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
> >  arch/arm/boot/dts/exynos4x12.dtsi  |   82 ++
> >  arch/arm/boot/dts/exynos5250.dtsi  |  290 
> > 
> >  5 files changed, 622 insertions(+), 0 deletions(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > new file mode 100644
> > index 000..92f0a33
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > @@ -0,0 +1,103 @@
> > +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
> > +
> > +Samsung's Exynos architecture contains System MMU that enables scattered
> > +physical memory chunks visible as a contiguous region to DMA-capable 
> > peripheral
> > +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
> 
> s/so forth/and more ?

Sorry but I think that it is not a matter.

> 
> > +
> > +System MMU is a sort of IOMMU and support identical translation table 
> > format to
> 
> s/support/supports ?

Ok.

> 
> > +ARMv7 translation tables with minimum set of page properties including 
> > access
> > +permissions, shareability and security protection. In addition, System MMU 
> > has
> > +another capabilities like L2 TLB or block-fetch buffers to minimize 
> > translation
> > +latency.
> > +
> > +A System MMU is dedicated to a single master peripheral device.  Thus, it 
> > is
> > +important to specify the correct System MMU in the device node of its 
> > master
> > +device. Whereas a System MMU is dedicated to a master device, the master 
> > device
> > +may have more than one System MMU.
> > +
> > +Required properties:
> > +- compatible: Should be "samsung,exynos4210-sysmmu"
> > +- reg: A tuple of base address and size of System MMU registers.
> > +- interrupt-parent: The phandle of the interrupt controller of System MMU
> > +- interrupts: A tuple of numbers that indicates the interrupt source.
> 
> The interrupt specifier depends on the interrupt controller 
> (interrupt-parent). 
> So it might not always be a "tuple of numbers". It's probably better to say,
> e.g.:
> 
> - interrupts: Should contain the SYSMMU controller interrupt.
> 

Yes.
You are correct.
The description assumes the interrupt controler is Interrupt Combiner in Exynos 
SoCs.
But actually, the interrupt controller can be GIC or something else.
The description needs to be changed.

> > +- clock-names: Should be "sysmmu" if the System MMU is needed to gate its 
> > clock.
> > +   Please refer to the following documents:
> > +  Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +  Documentation/devicetree/bindings/clock/exynos4-clock.txt
> > +  Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> 
> You could replace "Documentation/devicetree/bindings/clock" with "../clock"
> 

Ok.

> > +  Optional "master" if the clock to the System MMU is gated by
> > +  another gate clock other than "sysmmu". The System MMU driver
> > +  sets "master" the parent of "sysmmu".
> > +  Exynos4 SoCs, there needs no "master" clocks.
> > +  Exynos5 SoCs, some System MMUs must have "master" clocks.
> > +- clocks: Required if the System MMU is needed to gate its clock.
> > + Please refer to the documents listed above.
> > +- samsung,power-domain: Required if the System MMU is needed to gate its 
> > power.
> 
> Isn't it required always when an SoC support Power Domains and the SYSMMU
> belongs to a power domain ? Perhaps something like:
> 
> - samsung,power-domain: Required if the System MMU belongs to a Power Domain.
> 
> would be more appropriate ?
> 

Acutally, if System MMU and its master H/W is not registered to a generic IO 
powerdomain,
RPM and APM is not applicable to System MMU because of the implementation of 
System MMU
driver relies on dev_pm_ops callbacks of generic IO powerdomain.
I am still searching a better way like introducing bus_type for System MMU.
Any advice about it is welcome.

> > + Please refer to the following document:
> > + Documentation/devicetree/bindings/arm/exynos/p

Re: dw_mmc: Does anyone use multiple slots?

[Olof Johansson]

On Thu, Aug 8, 2013 at 5:16 PM, Doug Anderson  wrote:

> I guess my overall question is: if there are no actual implementations
> of multislot, shouldn't we kill it and simplify the code a whole lot?
> If someone out there has a real multislot device they can step back in
> and do it more correctly?
>
> Of course we need to find someone to actually go through and do the
> killing of multislot, but finding that person might be easier if there
> was some agreement that it was good to do.

There clearly seems to be no in-tree users of multislot. If someone
new comes in, we have the code in the history and can revert the
removal (or at least use it as reference for re-introduction).

I vote for removing it. It adds really annoying complexity for
something that nobody uses.


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

dw_mmc: Does anyone use multiple slots?

[Doug Anderson]

Hi,

A quick question: does anyone know of any hardware that actually
implements multiple slots per host on the dw_mmc controller?

When working on the driver I often find myself running into questions
about how things should work on the theoretical "multiple slot" dw_mmc
implementation.  ...and I often find bugs where things couldn't
possibly work for a multiple slot implementation.

As an example, recently I sent up (870556a mmc: dw_mmc: Handle late
vmmc regulators with EPROBE_DEFER).  Before that patch the host-global
"host->vmmc" was being set once per slot.  Said another way, if slot 0
set host->mmc to ABC, then slot 1 would come along and clobber
host->mmc to DEF.  After my patch the dw_mmc code assumes one vmmc
regulator per host.  As Tomasz pointed out, that might not be so good
(*), but it was better than what was there before.  Maybe all
multislot implementations don't use vmmc?

Another example, though, is dw_mci_init_slot().  It calls this once per slot:
  mmc_alloc_host(sizeof(struct dw_mci_slot), host->dev);

...where "host->dev" is shared among all the slots.  I haven't tested
it (since I don't have multislot), but that doesn't seem wise to me.
Reading through mmc_alloc_host(), it looks like it assumes that this
host owns host->dev and it feels free to clobber variables.  Sound
familiar?

I guess my overall question is: if there are no actual implementations
of multislot, shouldn't we kill it and simplify the code a whole lot?
If someone out there has a real multislot device they can step back in
and do it more correctly?

Of course we need to find someone to actually go through and do the
killing of multislot, but finding that person might be easier if there
was some agreement that it was good to do.

Cheers?  Flames?

-Doug

---

(*) On the other hand, maybe my patch is OK.  A reasonable way that
multi-slot power might work is with a since vmmc and then it is
multiplexed through with PWREN?  All I know is that exynos says
"PWREN" is not implemented and that exynos only has one slot per host.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 3/3] ASoC: Samsung: I2S: Modify the I2S driver to support I2S on Exynos5420

[Tomasz Figa]

Hi Padmavathi,

On Wednesday 07 of August 2013 14:15:22 Padmavathi Venna wrote:
> Exynos5420 added support for I2S TDM mode. For this, there are some
> register changes in the I2S controller. This patch adds the relevant
> register changes to support I2S in normal mode. This patch adds a
> quirk for TDM mode and if TDM mode is present all the relevent changes
> will be applied.
> 
> Signed-off-by: Padmavathi Venna 
> ---
>  .../devicetree/bindings/sound/samsung-i2s.txt  |4 +
>  include/linux/platform_data/asoc-s3c.h |1 +
>  sound/soc/samsung/i2s-regs.h   |   15 
>  sound/soc/samsung/i2s.c|   81
> ++-- 4 files changed, 93 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
> b/Documentation/devicetree/bindings/sound/samsung-i2s.txt index
> b3f6443..9b5c892 100644
> --- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
> @@ -11,6 +11,10 @@ Required SoC Specific Properties:
>   with secondary fifo and s/w reset control.
> - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
>   secondary fifo, s/w reset control and internal mux for root clk
> src. +   - samsung,exynos5420-i2s: for 8/16/24bit multichannel(7.1) I2S
> with + secondary fifo, s/w reset control, internal mux for root clk
> src and + TDM support. TDM (Time division multiplexing) is to allow
> transfer of + multiple channel audio data on single data line.
> 
>  - reg: physical base address of the controller and length of memory
> mapped region.
> diff --git a/include/linux/platform_data/asoc-s3c.h
> b/include/linux/platform_data/asoc-s3c.h index 8827259..9efc04d 100644
> --- a/include/linux/platform_data/asoc-s3c.h
> +++ b/include/linux/platform_data/asoc-s3c.h
> @@ -36,6 +36,7 @@ struct samsung_i2s {
>   */
>  #define QUIRK_NO_MUXPSR  (1 << 2)
>  #define QUIRK_NEED_RSTCLR(1 << 3)
> +#define QUIRK_SUPPORTS_TDM   (1 << 4)
>   /* Quirks of the I2S controller */
>   u32 quirks;
>   dma_addr_t idma_addr;
> diff --git a/sound/soc/samsung/i2s-regs.h b/sound/soc/samsung/i2s-regs.h
> index 30513b7..821a502 100644
> --- a/sound/soc/samsung/i2s-regs.h
> +++ b/sound/soc/samsung/i2s-regs.h
> @@ -31,6 +31,10 @@
>  #define I2SLVL1ADDR  0x34
>  #define I2SLVL2ADDR  0x38
>  #define I2SLVL3ADDR  0x3c
> +#define I2SSTR1  0x40
> +#define I2SVER   0x44
> +#define I2SFIC2  0x48
> +#define I2STDM   0x4c
> 
>  #define CON_RSTCLR   (1 << 31)
>  #define CON_FRXOFSTATUS  (1 << 26)
> @@ -117,6 +121,17 @@
>  #define MOD_BCLK_MASK3
>  #define MOD_8BIT (1 << 0)
> 
> +#define EXYNOS5420_MOD_LRP_SHIFT 15
> +#define EXYNOS5420_MOD_SDF_SHIFT 6
> +#define EXYNOS5420_MOD_RCLK_SHIFT4
> +#define EXYNOS5420_MOD_BCLK_SHIFT0
> +#define EXYNOS5420_MOD_BCLK_64FS 4
> +#define EXYNOS5420_MOD_BCLK_96FS 5
> +#define EXYNOS5420_MOD_BCLK_128FS6
> +#define EXYNOS5420_MOD_BCLK_192FS7
> +#define EXYNOS5420_MOD_BCLK_256FS8
> +#define EXYNOS5420_MOD_BCLK_MASK 0xf
> +
>  #define MOD_CDCLKCON (1 << 12)
> 
>  #define PSR_PSREN(1 << 15)
> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index 8a5504c..6964672 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -199,7 +199,12 @@ static inline bool is_manager(struct i2s_dai *i2s)
>  /* Read RCLK of I2S (in multiples of LRCLK) */
>  static inline unsigned get_rfs(struct i2s_dai *i2s)
>  {
> - u32 rfs = (readl(i2s->addr + I2SMOD) >> MOD_RCLK_SHIFT);
> + u32 rfs;
> +
> + if (i2s->quirks & QUIRK_SUPPORTS_TDM)
> + rfs = readl(i2s->addr + I2SMOD) >> 
EXYNOS5420_MOD_RCLK_SHIFT;
> + else
> + rfs = (readl(i2s->addr + I2SMOD) >> MOD_RCLK_SHIFT);
>   rfs &= MOD_RCLK_MASK;
> 
>   switch (rfs) {
> @@ -214,8 +219,12 @@ static inline unsigned get_rfs(struct i2s_dai *i2s)
> static inline void set_rfs(struct i2s_dai *i2s, unsigned rfs) {
>   u32 mod = readl(i2s->addr + I2SMOD);
> - int rfs_shift =  MOD_RCLK_SHIFT;
> + int rfs_shift;
> 
> + if (i2s->quirks & QUIRK_SUPPORTS_TDM)
> + rfs_shift = EXYNOS5420_MOD_RCLK_SHIFT;
> + else
> + rfs_shift = MOD_RCLK_SHIFT;
>   mod &= ~(MOD_RCLK_MASK << rfs_shift);
> 
>   switch (rfs) {
> @@ -239,10 +248,22 @@ static inline void set_rfs(struct i2s_dai *i2s,
> unsigned rfs) /* Read Bit-Clock of I2S (in multiples of LRCLK) */
>  static inline unsigned get_bfs(struct i2s_dai *i2s)
>  {
> - u32 bfs =  readl(i2s->addr + I2SMOD) >> MOD_BCLK_SHIFT;
> - bfs &= MOD_BCLK_MASK;
> + u32 bfs;
> +
> + if (i2s->quirks & QUIRK_SUPPORTS_TDM) {
> + bfs = readl(i2s->addr + I2SMOD) >> 
EXYNOS5420_MOD_BCLK_SHIFT;
> + bfs &= EXYNOS5420_MOD_BCLK_MASK;
> +

Re: [PATCH v9 14/16] iommu/exynos: add support for power management subsystems.

[Tomasz Figa]

Hi KyongHo,

nit: Please drop the trailing dot at the end of patch subject.

On Thursday 08 of August 2013 18:41:17 Cho KyongHo wrote:
> This adds support for Advance Power Management and Runtime Power
> Management.

This patch adds support for system-wide and runtime power management.

> Since System MMU is located in the same local power domain of its
> master H/W, System MMU must be initialized before it is working if
> its power domain was ever turned off. TLB invalidation according to
> unmapping on page tables must also be performed while power domain is
> turned on.
> 
> This patch ensures that resume and runtime_resume(restore_state)
> functions in this driver is called before the calls to resume and
> runtime_resume callback functions in the drivers of master H/Ws.
> Likewise, suspend and runtime_suspend(save_state) functions in this
> driver is called after the calls to suspend and runtime_suspend in the
> drivers of master H/Ws.
> 
> In order to get benefit of this support, the master H/W and its System
> MMU must resides in the same power domain in terms of Linux kernel. If
> a master H/W does not use generic I/O power domain, its driver must
> call iommu_attach_device() after its local power domain is turned on,
> iommu_detach_device before turned off.

I don't get the point of this last paragraph. What a power domain can be 
in other terms? Is there any other way to support power domains on Exynos 
than generic power domains?

> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/exynos-iommu.c |  235
> +- 1 files changed, 231
> insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 9e64483..56aead9 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include 
> @@ -186,6 +187,7 @@ struct sysmmu_drvdata {
>   int activations;
>   rwlock_t lock;
>   struct iommu_domain *domain;
> + bool runtime_active;
>   unsigned long pgtable;
>   void __iomem *sfrbases[0];
>  };
> @@ -438,7 +440,8 @@ static bool __sysmmu_disable(struct sysmmu_drvdata
> *data) data->pgtable = 0;
>   data->domain = NULL;
> 
> - __sysmmu_disable_nocount(data);
> + if (data->runtime_active)
> + __sysmmu_disable_nocount(data);
> 
>   dev_dbg(data->sysmmu, "Disabled\n");
>   } else  {
> @@ -505,7 +508,8 @@ static int __sysmmu_enable(struct sysmmu_drvdata
> *data, data->pgtable = pgtable;
>   data->domain = domain;
> 
> - __sysmmu_enable_nocount(data);
> + if (data->runtime_active)
> + __sysmmu_enable_nocount(data);
> 
>   dev_dbg(data->sysmmu, "Enabled\n");
>   } else {
> @@ -609,7 +613,7 @@ static void sysmmu_tlb_invalidate_entry(struct
> device *dev, unsigned long iova) data =
> dev_get_drvdata(client->sysmmu[i]);
> 
>   read_lock_irqsave(&data->lock, flags);
> - if (is_sysmmu_active(data)) {
> + if (is_sysmmu_active(data) && data->runtime_active) {
>   int i;
>   clk_enable(data->clk_master);
>   for (i = 0; i < data->nsfrs; i++)
> @@ -637,7 +641,8 @@ void exynos_sysmmu_tlb_invalidate(struct device
> *dev) data = dev_get_drvdata(client->sysmmu[i]);
> 
>   read_lock_irqsave(&data->lock, flags);
> - if (is_sysmmu_active(data)) {
> + if (is_sysmmu_active(data) &&
> + data->runtime_active) {

nit: The whole if condition fits into single line.

>   int i;
>   for (i = 0; i < data->nsfrs; i++) {
>   clk_enable(data->clk_master);
> @@ -711,6 +716,8 @@ static int __init exynos_sysmmu_probe(struct
> platform_device *pdev) }
>   }
> 
> + pm_runtime_enable(dev);
> +
>   data->sysmmu = dev;
> 
>   data->clk = devm_clk_get(dev, "sysmmu");
> @@ -736,6 +743,8 @@ static int __init exynos_sysmmu_probe(struct
> platform_device *pdev) return ret;
>   }
> 
> + data->runtime_active = !pm_runtime_enabled(dev);
> +
>   rwlock_init(&data->lock);
> 
>   platform_set_drvdata(pdev, data);
> @@ -744,6 +753,34 @@ static int __init exynos_sysmmu_probe(struct
> platform_device *pdev) return ret;
>  }
> 
> +#ifdef CONFIG_PM_SLEEP
> +static int sysmmu_suspend(struct device *dev)
> +{
> + struct sysmmu_drvdata *data = dev_get_drvdata(dev);
> + unsigned long flags;
> + read_lock_irqsave(&data->lock, flags);
> + if (is_sysmmu_active(data) &&
> + (!pm_runtime_enabled(dev) || data->runtime_active))
> + __sysmmu_disable_nocount(data);
> + read_unlock_irqrestore(&data->lock, flags);
> + return 0;
> +}
> +
> +static int sysmmu_resume(struct device *dev)
> +{
> + struct sysmmu_drvd

Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

[Stephen Warren]

On 08/08/2013 04:10 PM, Tomasz Figa wrote:
> On Thursday 08 of August 2013 15:47:19 Stephen Warren wrote:
>> On 08/08/2013 03:19 PM, Tomasz Figa wrote:
>>> On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
 On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
> MFC driver use custom bindings for managing reserved memory. Those
> bindings are not really specific to MFC device and no even well
> discussed. They can be easily replaced with generic, platform
> independent code for handling reserved and contiguous memory.
>
> Two additional child devices for each memory port (AXI master) are
> introduced to let one assign some properties to each of them. Later
> one
> can also use them to assign properties related to SYSMMU
> controllers,
> which can be used to manage the limited dma window provided by those
> memory ports.
...
> +Two child nodes must be defined for MFC device. Their names must be
> +following: "memport-r" and "memport-l" ("right" and "left").
> Required

 Node names shouldn't have semantic meaning.
>>>
>>> What about bus-master-0 and bus-master-1?
>>
>> Just "bus-master" for each might make sense. Use reg properties to
>> differentiate the two?
> 
> What this reg property would mean in this case?
> 
> My understanding of reg property was that it should be used for real 
> addresses or IDs and for all other cases node names should be suffixed 
> with "-ID".

Presumably it would hold the ID of the HW block as defined in the
documentation. Or, it could be somewhat arbitrary.

--
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 v9 08/16] iommu/exynos: gating clocks of master H/W

[Tomasz Figa]

Hi KyongHo,

On Thursday 08 of August 2013 18:39:05 Cho KyongHo wrote:
> This patch gates clocks of master H/W as well as clocks of System MMU
> if master clocks are specified.
> 
> Some Exynos SoCs (i.e. GScalers in Exynos5250) have dependencies in
> the gating clocks of master H/W and its System MMU. If a H/W is the
> case, accessing control registers of System MMU is prohibited unless
> both of the gating clocks of System MMU and its master H/W.
> 
> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/exynos-iommu.c |   38
> ++ 1 files changed, 34
> insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 0ee73e8..005a7ed 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -173,6 +173,7 @@ struct sysmmu_drvdata {
>   struct device *dev; /* Owner of system MMU */
>   int nsfrs;
>   struct clk *clk;
> + struct clk *clk_master;
>   int activations;
>   rwlock_t lock;
>   struct iommu_domain *domain;
> @@ -263,6 +264,8 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
>   if (!is_sysmmu_active(data))
>   goto finish;
> 
> + clk_enable(data->clk_master);
> +
>   for (i = 0; i < data->nsfrs; i++) {
>   if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 
3) {
>   if (!sysmmu_block(data->sfrbases[i]))
> @@ -288,6 +291,8 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
>   sysmmu_unblock(data->sfrbases[i]);
>   }
>   }
> +
> + clk_disable(data->clk_master);
>  finish:
>   read_unlock_irqrestore(&data->lock, flags);
>  }
> @@ -358,6 +363,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void
> *dev_id) break;
>   }
> 
> + clk_enable(data->clk_master);
> +
>   if (i == pdev->num_resources) {
>   itype = SYSMMU_FAULT_UNKNOWN;
>   } else {
> @@ -391,6 +398,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void
> *dev_id) if (itype != SYSMMU_FAULT_UNKNOWN)
>   sysmmu_unblock(data->sfrbases[i]);
> 
> + clk_disable(data->clk_master);
> +
>   read_unlock(&data->lock);
> 
>   return IRQ_HANDLED;
> @@ -407,11 +416,14 @@ static bool __exynos_sysmmu_disable(struct
> sysmmu_drvdata *data) if (!set_sysmmu_inactive(data))
>   goto finish;
> 
> + clk_enable(data->clk_master);
> +
>   for (i = 0; i < data->nsfrs; i++)
>   __raw_writel(CTRL_DISABLE, data->sfrbases[i] + 
REG_MMU_CTRL);
> 
> - if (data->clk)
> - clk_disable(data->clk);
> + clk_disable(data->clk_master);
> +
> + clk_disable(data->clk);
> 
>   disabled = true;
>   data->pgtable = 0;
> @@ -454,11 +466,12 @@ static int __exynos_sysmmu_enable(struct
> sysmmu_drvdata *data, goto finish;
>   }
> 
> - if (data->clk)
> - clk_enable(data->clk);
> + clk_enable(data->clk);
> 
>   data->pgtable = pgtable;
> 
> + clk_enable(data->clk_master);
> +
>   for (i = 0; i < data->nsfrs; i++) {
>   __sysmmu_set_ptbase(data->sfrbases[i], pgtable);
> 
> @@ -473,6 +486,8 @@ static int __exynos_sysmmu_enable(struct
> sysmmu_drvdata *data, __raw_writel(CTRL_ENABLE, data->sfrbases[i] +
> REG_MMU_CTRL); }
> 
> + clk_disable(data->clk_master);
> +
>   data->domain = domain;
> 
>   dev_dbg(data->sysmmu, "Enabled\n");
> @@ -528,6 +543,7 @@ static void sysmmu_tlb_invalidate_entry(struct
> device *dev, unsigned long iova)
> 
>   if (is_sysmmu_active(data)) {
>   int i;
> + clk_enable(data->clk_master);
>   for (i = 0; i < data->nsfrs; i++) {
>   if (sysmmu_block(data->sfrbases[i])) {
>   __sysmmu_tlb_invalidate_entry(
> @@ -535,6 +551,7 @@ static void sysmmu_tlb_invalidate_entry(struct
> device *dev, unsigned long iova) sysmmu_unblock(data->sfrbases[i]);
>   }
>   }
> + clk_disable(data->clk_master);
>   } else {
>   dev_dbg(data->sysmmu, "Disabled. Skipping invalidating 
TLB.\n");
>   }
> @@ -551,12 +568,14 @@ void exynos_sysmmu_tlb_invalidate(struct device
> *dev)
> 
>   if (is_sysmmu_active(data)) {
>   int i;
> + clk_enable(data->clk_master);
>   for (i = 0; i < data->nsfrs; i++) {
>   if (sysmmu_block(data->sfrbases[i])) {
>   __sysmmu_tlb_invalidate(data-
>sfrbases[i]);
>   sysmmu_unblock(data->sfrbases[i]);
>   }
>   }
> + clk_disable(data->clk_master);
>   } else {
>   dev_dbg(data->sysmmu, "Disabled. Skipping invalidating 
TLB.\n");
>   }
> @@ -637,6 +656,17 @@ static int __init exynos_sysmmu_probe(struct
> platform_device *pdev) return ret;
>   }
> 
> + data->clk_master = devm_clk_get(dev, "master");
> + if

Re: [PATCH v9 07/16] iommu/exynos: support for device tree

[Tomasz Figa]

Hi KyongHo,

On Thursday 08 of August 2013 18:38:49 Cho KyongHo wrote:
> This commit adds device tree support for System MMU.
> This also include the following changes and enhancements:
> 
> * use managed device helper functions.
> Simplyfies System MMU device driver.
> 
> * use only a single clock descriptor.
> System MMU device descriptor is seperate if it is imposible to make
> a single clock descriptor to make a device descriptor for a group of
> System MMUs.
> 
> * removed dbgname member from sysmmu_drvdata structure.
> debugging kernel message for a System MMU is distinguisheable with the
> name of device descroptors.

Please put all these three changes in separate patches. This patch is hard 
to review with all the changes mixed together...

In addition, I believe this is the patch that should be adding device tree 
binding documentation, not the 6/16 one, as this is where actually support 
for this binding gets added to the kernel.

> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/Kconfig|5 +-
>  drivers/iommu/exynos-iommu.c |  186
> - 2 files changed, 75
> insertions(+), 116 deletions(-)
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 820d85c..9ad45f1 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -168,16 +168,15 @@ config TEGRA_IOMMU_SMMU
> 
>  config EXYNOS_IOMMU
>   bool "Exynos IOMMU Support"
> - depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU
> + depends on ARCH_EXYNOS
>   select IOMMU_API
> + default n
>   help
> Support for the IOMMU(System MMU) of Samsung Exynos application
> processor family. This enables H/W multimedia accellerators to 
see
> non-linear physical memory chunks as a linear memory in their
> address spaces
> 
> -   If unsure, say N here.
> -
>  config EXYNOS_IOMMU_DEBUG
>   bool "Debugging log for Exynos IOMMU"
>   depends on EXYNOS_IOMMU
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index a318049..0ee73e8 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -170,15 +171,14 @@ struct sysmmu_drvdata {
>   struct list_head node; /* entry of exynos_iommu_domain.clients */
>   struct device *sysmmu;  /* System MMU's device descriptor */
>   struct device *dev; /* Owner of system MMU */
> - char *dbgname;
>   int nsfrs;
> - void __iomem **sfrbases;
> - struct clk *clk[2];
> + struct clk *clk;
>   int activations;
>   rwlock_t lock;
>   struct iommu_domain *domain;
>   sysmmu_fault_handler_t fault_handler;
>   unsigned long pgtable;
> + void __iomem *sfrbases[0];
>  };
> 
>  static bool set_sysmmu_active(struct sysmmu_drvdata *data)
> @@ -385,8 +385,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void
> *dev_id) if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
>   __raw_writel(1 << itype, data->sfrbases[i] + 
REG_INT_CLEAR);
>   else
> - dev_dbg(data->sysmmu, "(%s) %s is not handled.\n",
> - data->dbgname, sysmmu_fault_name[itype]);
> + dev_dbg(data->sysmmu, "%s is not handled.\n",
> + sysmmu_fault_name[itype]);
> 
>   if (itype != SYSMMU_FAULT_UNKNOWN)
>   sysmmu_unblock(data->sfrbases[i]);
> @@ -410,10 +410,8 @@ static bool __exynos_sysmmu_disable(struct
> sysmmu_drvdata *data) for (i = 0; i < data->nsfrs; i++)
>   __raw_writel(CTRL_DISABLE, data->sfrbases[i] + 
REG_MMU_CTRL);
> 
> - if (data->clk[1])
> - clk_disable(data->clk[1]);
> - if (data->clk[0])
> - clk_disable(data->clk[0]);
> + if (data->clk)
> + clk_disable(data->clk);
> 
>   disabled = true;
>   data->pgtable = 0;
> @@ -422,10 +420,10 @@ finish:
>   write_unlock_irqrestore(&data->lock, flags);
> 
>   if (disabled)
> - dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
> + dev_dbg(data->sysmmu, "Disabled\n");
>   else
> - dev_dbg(data->sysmmu, "(%s) %d times left to be 
disabled\n",
> - data->dbgname, data->activations);
> + dev_dbg(data->sysmmu, "%d times left to be disabled\n",
> + data->activations);
> 
>   return disabled;
>  }
> @@ -452,14 +450,12 @@ static int __exynos_sysmmu_enable(struct
> sysmmu_drvdata *data, ret = 1;
>   }
> 
> - dev_dbg(data->sysmmu, "(%s) Already enabled\n", data-
>dbgname);
> + dev_dbg(data->sysmmu, "Already enabled\n");
>   goto finish;
>   }
> 
> - if (data->clk[0])
> - clk_enable(data->clk[0]);
> - if (data->clk[1])
> - clk_enable(data->clk[1]);
> + if (data->clk)
> + clk_enable(data-

Re: [PATCH v9 06/16] ARM: dts: Add description of System MMU of Exynos SoCs

[Tomasz Figa]

Hi KyongHo,

On Thursday 08 of August 2013 18:38:35 Cho KyongHo wrote:
> Signed-off-by: Cho KyongHo 
> ---
>  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
>  arch/arm/boot/dts/exynos4.dtsi |  122 
>  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
>  arch/arm/boot/dts/exynos4x12.dtsi  |   82 ++
>  arch/arm/boot/dts/exynos5250.dtsi  |  290
>  5 files changed, 622 insertions(+), 0 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> 
> diff --git
> a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> new file mode 100644
> index 000..92f0a33
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> @@ -0,0 +1,103 @@
> +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management
> Unit) +
> +Samsung's Exynos architecture contains System MMU that enables
> scattered +physical memory chunks visible as a contiguous region to
> DMA-capable peripheral +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS
> and so forth.
> +
> +System MMU is a sort of IOMMU and support identical translation table
> format to +ARMv7 translation tables with minimum set of page properties
> including access +permissions, shareability and security protection. In
> addition, System MMU has +another capabilities like L2 TLB or
> block-fetch buffers to minimize translation +latency.
> +
> +A System MMU is dedicated to a single master peripheral device.  Thus,
> it is +important to specify the correct System MMU in the device node
> of its master +device. Whereas a System MMU is dedicated to a master
> device, the master device +may have more than one System MMU.

This paragraph is still not clear. What about something among these lines:

System MMUs are in many to one relation with peripheral devices, i.e. 
single peripheral device might have multiple System MMUs (usually one for 
each bus master), but one System MMU can handle only one peripheral 
device. The relation between a System MMU and the peripheral device it 
handles needs to be defined in device node of this peripheral device.

> +Required properties:
> +- compatible: Should be "samsung,exynos4210-sysmmu"
> +- reg: A tuple of base address and size of System MMU registers.
> +- interrupt-parent: The phandle of the interrupt controller of System
> MMU +- interrupts: A tuple of numbers that indicates the interrupt
> source. 

interrupts: An interrupt specifier for interrupt signal of System MMU, 
according to format defined for particular interrupt parent.

> +- clock-names: Should be "sysmmu" if the System MMU is needed
> to gate its clock. +   Please refer to the following
> documents:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +Documentation/devicetree/bindings/clock/exynos4-clock.txt
> +Documentation/devicetree/bindings/clock/exynos5250-
clock.txt
> +Optional "master" if the clock to the System MMU is gated 
by
> +another gate clock other than "sysmmu". The System MMU 
driver
> +sets "master" the parent of "sysmmu".
> +Exynos4 SoCs, there needs no "master" clocks.
> +Exynos5 SoCs, some System MMUs must have "master" clocks.
> +- clocks: Required if the System MMU is needed to gate its clock.
> +   Please refer to the documents listed above.
> +- samsung,power-domain: Required if the System MMU is needed to gate
> its power. +Please refer to the following document:
> +   Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +
> +Required properties for the master peripheral devices:
> +- iommu: phandles to the System MMUs of the device
> +
> +Examples:
> +A System MMU is dedicated to a single master device.
> + gsc_0:  gsc@0x13e0 {

nit: duplicated space after gsc_0: and incorrect 0x prefix in node unit-
address.

> + compatible = "samsung,exynos5-gsc";
> + reg = <0x13e0 0x1000>;
> + interrupts = <0 85 0>;
> + samsung,power-domain = <&pd_gsc>;
> + clocks = <&clock 256>;
> + clock-names = "gscl";
> + iommu = <&sysmmu_gsc1>;
> + };
> +
> + sysmmu_gsc0: sysmmu@13E8 {
> + compatible = "samsung,exynos4210-sysmmu";
> + reg = <0x13E8 0x1000>;
> + interrupt-parent = <&combiner>;
> + interrupt-names = "sysmmu-gsc0";

Hmm? interrupt-names property is not defined in your binding documentation 
and also the value here looks wrong. This should be a generic interrupt 
signal name that the SysMMU driver can understand, e.g. "sysmmu", without 
the "-gsc0" suffix.

> + interrupts = <2 0>;
> + clock-names = "sysmmu", "master";
> + clocks = <&clock

Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

[Tomasz Figa]

On Thursday 08 of August 2013 15:47:19 Stephen Warren wrote:
> On 08/08/2013 03:19 PM, Tomasz Figa wrote:
> > Hi Stephen,
> > 
> > On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
> >> On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
> >>> MFC driver use custom bindings for managing reserved memory. Those
> >>> bindings are not really specific to MFC device and no even well
> >>> discussed. They can be easily replaced with generic, platform
> >>> independent code for handling reserved and contiguous memory.
> >>> 
> >>> Two additional child devices for each memory port (AXI master) are
> >>> introduced to let one assign some properties to each of them. Later
> >>> one
> >>> can also use them to assign properties related to SYSMMU
> >>> controllers,
> >>> which can be used to manage the limited dma window provided by those
> >>> memory ports.
> >>> 
> >>> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> >>> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> >>> 
> >>> +The MFC device is connected to system bus with two memory ports
> >>> (AXI
> >>> +masters) for better performance. Those memory ports are modelled as
> >>> +separate child devices, so one can assign some properties to them
> >>> (like +memory region for dma buffer allocation or sysmmu
> >>> controller).
> >>> +
> >>> 
> >>>  Required properties:
> >>>- compatible : value should be either one among the following
> >>>   
> >>>   (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
> >>>   (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
> >>> 
> >>> + and additionally "simple-bus" to correctly initialize child
> >>> + devices for memory ports (AXI masters)
> >> 
> >> simple-bus is wrong here; the child nodes aren't independent entities
> >> that can be instantiated separately from their parent and without
> >> depending on their parent.
> > 
> > I fully agree, but I can't think of anything better. Could you suggest
> > a solution that would cover our use case:
> > 
> > The MFC IP has two separate bus masters (called here and there
> > memports). On some SoCs, each master must use different memory bank
> > to meet memory bandwidth requirements for higher bitrate video
> > streams. This can be seen as MFC having two DMA subdevices, which
> > have different DMA windows.
> > 
> > On Linux, this is handled by binding two appropriate CMA memory
> > regions to the memports, so the driver can do DMA allocations on
> > behalf of particular memport and get appropriate memory for it.
> 
> I don't see what that has to do with simple-bus.

Well, this is not the first binding doing things this way, unless I don't 
understand something. See the recently posted mvebu bindings. Using 
simple-bus for this has the nice property of allowing both non-DT and DT 
cases to be handled in exactly the same way in MFC driver.

> Whatever parses the
> node of the MFC can directly read from any contained property or child
> node; there's no need to try and get the core DT tree parser to
> enumerate the children.
> 
> If you actually need a struct platform_device for each of these child
> nodes (which sounds wrong, but I'm not familiar with the code)

We need struct device for each memport and CMA region bound to both of 
them. This is a requirement of the Linux DMA mapping API, and well, it 
represents real hardware structure anyway.

> , then
> simply have the driver call of_platform_populate() itself at the
> appropriate time.

This sounds fine to me. 

> But that's not going to work well unless the child
> nodes have compatible values, which doesn't seem right given their
> purpose.
> >>> -  - samsung,mfc-r : Base address of the first memory bank used by
> >>> MFC
> >>> - for DMA contiguous memory allocation and its size.
> >>> -
> >>> -  - samsung,mfc-l : Base address of the second memory bank used by
> >>> MFC
> >>> - for DMA contiguous memory allocation and its size.
> >> 
> >> These properties shouldn't be removed, but simply marked deprecated.
> >> The driver will need to continue to support them so that old DTs
> >> work with new kernels. The binding must therefore continue to
> >> document them so that the old DT content still makes sense.
> > 
> > I tend to disagree on this. For Samsung platforms we've been trying to
> > avoid DT bindings changes as much as possible, but I'd rather say that
> > device tree was coupled with kernel version it came from, so Samsung-
> > specific bindings haven't been fully stabilized yet, especially since
> > we are still at discussion stage when it's about defining processes
> > for binding staging and stabilization.
> 
> Well, that's why everyone is shouting at ARM for abusing DT...

IMHO this is not fully fair. We have a lot of development happenning on 
ARM. Things usually can't be done perfectly on first iteration, while we 
often want things working reasonably ASAP.

This is why I'm really all for staging/stable separation. I believe things 
need to be te

Re: [PATCH v4 01/13] [media] exynos5-is: Adding media device driver for exynos5

[Sylwester Nawrocki]

On 08/07/2013 11:03 AM, Arun Kumar K wrote:

From: Shaik Ameer Basha

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

* FIMC-IS
   Camera post-processing IP having multiple sub-nodes.

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

The media device creates two kinds of pipelines for connecting
the above mentioned IPs.
The pipeline0 is uses Sensor, MIPI-CSIS and FIMC-LITE which captures
image data and dumps to memory.
Pipeline1 uses FIMC-IS components for doing post-processing
operations on the captured image and give scaled YUV output.

Pipeline0
   ++ +---+ +---+ ++
   | Sensor | -->  | MIPI-CSIS | -->  | FIMC-LITE | -->  | Memory |
   ++ +---+ +---+ ++

Pipeline1
  ++  ++ +---+ +---+
  | Memory | -->   |  ISP   | -->  |SCC| -->  |SCP|
  ++  ++ +---+ +---+

Signed-off-by: Shaik Ameer Basha
Signed-off-by: Arun Kumar K
---
  .../devicetree/bindings/media/exynos5-mdev.txt |  148 +++
  drivers/media/platform/exynos5-is/exynos5-mdev.c   | 1189 
  drivers/media/platform/exynos5-is/exynos5-mdev.h   |  164 +++
  3 files changed, 1501 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/exynos5-mdev.txt
  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/Documentation/devicetree/bindings/media/exynos5-mdev.txt 
b/Documentation/devicetree/bindings/media/exynos5-mdev.txt
new file mode 100644
index 000..8b2ffb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-mdev.txt
@@ -0,0 +1,148 @@
+Samsung EXYNOS5 SoC Camera Subsystem
+
+
+The Exynos5 SoC Camera subsystem comprises of multiple sub-devices
+represented by separate device tree nodes. Currently this includes: FIMC-LITE,
+MIPI CSIS and FIMC-IS.
+
+The sub-subdevices are defined as child nodes of the common 'camera' node which
+also includes common properties of the whole subsystem not really specific to
+any single sub-device, like common camera port pins or the CAMCLK clock outputs
+for external image sensors attached to an SoC.
+
+Common 'camera' node
+
+
+Required properties:
+
+- compatible   : must be "samsung,exynos5-fimc", "simple-bus"
+- clocks   : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names  : must contain "sclk_bayer" entry and matching clock property
+  entry


I guess "and matching clock property entry" could be removed.


+The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
+to define a required pinctrl state named "default" and optional pinctrl states:


How about only supporting "default" pinctrl state in this initial DT 
binding/driver
version ? The optional states could be added later, my concern is that 
except the
camera port A, B there is also the RGB camera bay. Thus using "idle", 
"active-a",
active-b" won't work any more. We need to find some better solution for 
that.


Besides now when you removed the clock provider, there is not much you 
could do
with those optional pinctrl states. Those were originally meant to be 
used in
the clk_prepare/clk_unprepare ops. So, e.g. when sensor disables the 
clock the
host driver sets a clock output pin into idle state, e.g. input with 
pull down.


But maybe Exynos5 SoCs got improved comparing to e.g. Exynos4 so the 
clock output

pin is put into high impedance state when the sclk_cam clock is disabled ?
However that seems unlikely.


+"idle", "active-a", active-b". These optional states can be used to switch the
+camera port pinmux at runtime. The "idle" state should configure both the 
camera
+ports A and B into high impedance state, especially the CAMCLK clock output
+should be inactive. For the "active-a" state the camera port A must be 
activated
+and the port B deactivated and for the state "active-b" it should be the other
+way around.
+
+The 'camera' node must include at least one 'fimc-lite' child node.


This shouldn't be necessary, i.e. making the individual device nodes 
child nodes
of the camera node. Think of GScaler which can be used either by the 
camera or
the display/HDMI subsystem. Although csis and fimc-lite are purely 
camera specific
I'm inclined to move them out of the camera node and couple them with 
this node

either manually through 'compatible' values or explicitly through phandles.


+'parallel-ports' node
+--

Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

[Stephen Warren]

On 08/08/2013 03:19 PM, Tomasz Figa wrote:
> Hi Stephen,
> 
> On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
>> On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
>>> MFC driver use custom bindings for managing reserved memory. Those
>>> bindings are not really specific to MFC device and no even well
>>> discussed. They can be easily replaced with generic, platform
>>> independent code for handling reserved and contiguous memory.
>>>
>>> Two additional child devices for each memory port (AXI master) are
>>> introduced to let one assign some properties to each of them. Later
>>> one
>>> can also use them to assign properties related to SYSMMU controllers,
>>> which can be used to manage the limited dma window provided by those
>>> memory ports.
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>>
>>> +The MFC device is connected to system bus with two memory ports (AXI
>>> +masters) for better performance. Those memory ports are modelled as
>>> +separate child devices, so one can assign some properties to them
>>> (like +memory region for dma buffer allocation or sysmmu controller).
>>> +
>>>
>>>  Required properties:
>>>- compatible : value should be either one among the following
>>> 
>>> (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
>>> (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
>>>
>>> +   and additionally "simple-bus" to correctly initialize child
>>> +   devices for memory ports (AXI masters)
>>
>> simple-bus is wrong here; the child nodes aren't independent entities
>> that can be instantiated separately from their parent and without
>> depending on their parent.
> 
> I fully agree, but I can't think of anything better. Could you suggest a 
> solution that would cover our use case:
> 
> The MFC IP has two separate bus masters (called here and there memports). 
> On some SoCs, each master must use different memory bank to meet memory 
> bandwidth requirements for higher bitrate video streams. This can be seen 
> as MFC having two DMA subdevices, which have different DMA windows.
> 
> On Linux, this is handled by binding two appropriate CMA memory regions to 
> the memports, so the driver can do DMA allocations on behalf of particular 
> memport and get appropriate memory for it.

I don't see what that has to do with simple-bus. Whatever parses the
node of the MFC can directly read from any contained property or child
node; there's no need to try and get the core DT tree parser to
enumerate the children.

If you actually need a struct platform_device for each of these child
nodes (which sounds wrong, but I'm not familiar with the code), then
simply have the driver call of_platform_populate() itself at the
appropriate time. But that's not going to work well unless the child
nodes have compatible values, which doesn't seem right given their purpose.

>>> -  - samsung,mfc-r : Base address of the first memory bank used by MFC
>>> -   for DMA contiguous memory allocation and its size.
>>> -
>>> -  - samsung,mfc-l : Base address of the second memory bank used by
>>> MFC
>>> -   for DMA contiguous memory allocation and its size.
>>
>> These properties shouldn't be removed, but simply marked deprecated. The
>> driver will need to continue to support them so that old DTs work with
>> new kernels. The binding must therefore continue to document them so
>> that the old DT content still makes sense.
> 
> I tend to disagree on this. For Samsung platforms we've been trying to 
> avoid DT bindings changes as much as possible, but I'd rather say that 
> device tree was coupled with kernel version it came from, so Samsung-
> specific bindings haven't been fully stabilized yet, especially since we 
> are still at discussion stage when it's about defining processes for 
> binding staging and stabilization.

Well, that's why everyone is shouting at ARM for abusing DT...

> I would rather see this patch as part of work on Samsung DT binding 
> janitoring or maybe even sanitizing in some cases, like this one, when the 
> old (and IMHO bad) MFC binding was introduced without proper review. I 
> don't think we want to support this kind of brokenness anymore, especially 
> considering the hacks which would be required by such support (see 
> original implementation of this binding and code required in board file).
> 
>>> +Two child nodes must be defined for MFC device. Their names must be
>>> +following: "memport-r" and "memport-l" ("right" and "left"). Required
>>
>> Node names shouldn't have semantic meaning.
> 
> What about bus-master-0 and bus-master-1?

Just "bus-master" for each might make sense. Use reg properties to
differentiate the two?
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs

[Will Deacon]

On Thu, Aug 08, 2013 at 10:38:10PM +0100, Tomasz Figa wrote:
> On Thursday 08 of August 2013 08:09:49 Rob Herring wrote:
> > On Thu, Aug 1, 2013 at 8:05 AM, Cho KyongHo  
> wrote:
> > > Should this align with ARM System MMU bindings?
> > > System MMU in Exynos SoC is different from ARM System MMU.
> > > It does not follows the specifications of ARM System MMU.
> > 
> > I'm not saying the h/w is the same or even the same spec, but how you
> > describe a master to iommu connection needs to be done in the same
> > way. This should be done in the same way for ALL iommu's. And if what
> > is defined does not work for you, then we need to understand that and
> > fix the binding now.
> 
> +1
> 
> All IOMMUs should use a generic IOMMU Device Tree bindings (and in 
> general, the same should be true for all Device Tree bindings).
> 
> This means that if we already have some bindings for IOMMU, then they 
> should be reused if possible or extended if there is anything missing.
> 
> Of course there might be things that such generic bindings can't specify. 
> In this case device-specific properties can be introduced, but this is 
> last resort.

I'm also happy to discuss and/or review bindings in light of what we did for
the ARM SMMU.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs

[Tomasz Figa]

On Thursday 08 of August 2013 08:09:49 Rob Herring wrote:
> On Thu, Aug 1, 2013 at 8:05 AM, Cho KyongHo  
wrote:
> >> -Original Message-
> >> From: Rob Herring [mailto:robherri...@gmail.com]
> >> Sent: Saturday, July 27, 2013 10:55 PM
> >> 
> >> On Fri, Jul 26, 2013 at 6:28 AM, Cho KyongHo  
wrote:
> >> > Signed-off-by: Cho KyongHo 
> >> > ---
> >> > 
> >> >  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
> >> >  arch/arm/boot/dts/exynos4.dtsi |  122 
> >> >  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
> >> >  arch/arm/boot/dts/exynos4x12.dtsi  |   76 +
> >> >  arch/arm/boot/dts/exynos5250.dtsi  |  291
> >> >   5 files changed, 617 insertions(+), 0
> >> >  deletions(-)
> >> >  create mode 100644
> >> >  Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu
> >> >  .txt>> > 
> >> > diff --git
> >> > a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmm
> >> > u.txt
> >> > b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmm
> >> > u.txt new file mode 100644
> >> > index 000..92f0a33
> >> > --- /dev/null
> >> > +++
> >> > b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmm
> >> > u.txt @@ -0,0 +1,103 @@
> >> > +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management
> >> > Unit) +
> >> > +Samsung's Exynos architecture contains System MMU that enables
> >> > scattered +physical memory chunks visible as a contiguous region
> >> > to DMA-capable peripheral +devices like MFC, FIMC, FIMD, GScaler,
> >> > FIMC-IS and so forth.
> >> > +
> >> > +System MMU is a sort of IOMMU and support identical translation
> >> > table format to +ARMv7 translation tables with minimum set of page
> >> > properties including access +permissions, shareability and
> >> > security protection. In addition, System MMU has +another
> >> > capabilities like L2 TLB or block-fetch buffers to minimize
> >> > translation +latency.
> >> > +
> >> > +A System MMU is dedicated to a single master peripheral device. 
> >> > Thus, it is +important to specify the correct System MMU in the
> >> > device node of its master +device. Whereas a System MMU is
> >> > dedicated to a master device, the master device +may have more
> >> > than one System MMU.
> >> 
> >> I don't follow the last sentence. Can you elaborate on the type of
> >> connection you are talking about.
> > 
> > Grant also addressed that.
> > 
> > He corrected the sentence like the following:
> >   " Can I suggest rewriting the last two sentences to:
> >  The master device node must correctly specify at least one
> >  SystemMMU. A master  device may have more than one System MMU. "
> > 
> > I will change the sentence
> > 
> >> Also, please align with the ARM system MMU binding that Will Deacon
> >> has submitted particularly in terms of how master connections are
> >> described.
> > 
> > I didn't check it.
> > 
> > Should this align with ARM System MMU bindings?
> > System MMU in Exynos SoC is different from ARM System MMU.
> > It does not follows the specifications of ARM System MMU.
> 
> I'm not saying the h/w is the same or even the same spec, but how you
> describe a master to iommu connection needs to be done in the same
> way. This should be done in the same way for ALL iommu's. And if what
> is defined does not work for you, then we need to understand that and
> fix the binding now.

+1

All IOMMUs should use a generic IOMMU Device Tree bindings (and in 
general, the same should be true for all Device Tree bindings).

This means that if we already have some bindings for IOMMU, then they 
should be reused if possible or extended if there is anything missing.

Of course there might be things that such generic bindings can't specify. 
In this case device-specific properties can be introduced, but this is 
last resort.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling

[Tomasz Figa]

Hi Julius,

On Thursday 08 of August 2013 11:06:54 Julius Werner wrote:
> > I'm not sure I understand. The old documentation referred to the
> > USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
> > your new version only refers to (usb device) PHY_CONTROL. Regardless
> > of
> > multiple phys, you're suggesting that we describe less of each phy.
> > That seems like taking away usable information. Unless I've
> > misunderstood?
> 
> Well that's just the thing that's confusing right now, and which I am
> trying to fix: every PHY is either DEVICE or HOST and thus has only
> one PMU register. The current code describes the PMU register space
> for all PHYs on the system in the DT entry of every PHY and then
> calculates which register to use with hardcoded offsets. I think it
> makes much more sense if every PHY only describes its own register and
> doesn't need to do address arithmetic later on.
> 
> As Vivek said there is one exception in an old Exynos4,

Not that old yet. :)

> but that is
> currently not implemented in the upstream kernel anyway

Sorry, I don't understand what is not implemented. Without your patch, the 
PHY driver handles both PMU registers of Exynos4.

Best regards,
Tomasz

> , and if it
> ever will be it's still much easier to special case one weird chip
> than to have a super complicated and confusing mechanism for all of
> them.
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 13/20] pwm: Add new pwm-samsung driver

[Tomasz Figa]

On Thursday 08 of August 2013 10:13:27 Andrew Bresticker wrote:
> > ..it should not be defined as non-static in this case (= an ifdef is
> > needed in this header). I believe I had this already fixed, not sure
> > what happened with the fix...
> 
> Perhaps this is it: https://patchwork.kernel.org/patch/2787271/.  That
> should probably land with this patchset too.

Oh yes, this is it.

I know what happened now. This series was already queued for 3.11 in 
Samsung tree. After a bit of testing in linux-next Bart found the build 
error and sent a fix, which was going to be merged for 3.11 as well. 
However since there have been some problems just before merge window 
started, this series had to be dropped, including the fixup patch.

Thanks for reporting. Let me try to sort this out.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

[Tomasz Figa]

Hi Stephen,

On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
> On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
> > MFC driver use custom bindings for managing reserved memory. Those
> > bindings are not really specific to MFC device and no even well
> > discussed. They can be easily replaced with generic, platform
> > independent code for handling reserved and contiguous memory.
> > 
> > Two additional child devices for each memory port (AXI master) are
> > introduced to let one assign some properties to each of them. Later
> > one
> > can also use them to assign properties related to SYSMMU controllers,
> > which can be used to manage the limited dma window provided by those
> > memory ports.
> > 
> > diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> > b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> > 
> > +The MFC device is connected to system bus with two memory ports (AXI
> > +masters) for better performance. Those memory ports are modelled as
> > +separate child devices, so one can assign some properties to them
> > (like +memory region for dma buffer allocation or sysmmu controller).
> > +
> > 
> >  Required properties:
> >- compatible : value should be either one among the following
> > 
> > (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
> > (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
> > 
> > +   and additionally "simple-bus" to correctly initialize child
> > +   devices for memory ports (AXI masters)
> 
> simple-bus is wrong here; the child nodes aren't independent entities
> that can be instantiated separately from their parent and without
> depending on their parent.

I fully agree, but I can't think of anything better. Could you suggest a 
solution that would cover our use case:

The MFC IP has two separate bus masters (called here and there memports). 
On some SoCs, each master must use different memory bank to meet memory 
bandwidth requirements for higher bitrate video streams. This can be seen 
as MFC having two DMA subdevices, which have different DMA windows.

On Linux, this is handled by binding two appropriate CMA memory regions to 
the memports, so the driver can do DMA allocations on behalf of particular 
memport and get appropriate memory for it.

> > -  - samsung,mfc-r : Base address of the first memory bank used by MFC
> > -   for DMA contiguous memory allocation and its size.
> > -
> > -  - samsung,mfc-l : Base address of the second memory bank used by
> > MFC
> > -   for DMA contiguous memory allocation and its size.
> 
> These properties shouldn't be removed, but simply marked deprecated. The
> driver will need to continue to support them so that old DTs work with
> new kernels. The binding must therefore continue to document them so
> that the old DT content still makes sense.

I tend to disagree on this. For Samsung platforms we've been trying to 
avoid DT bindings changes as much as possible, but I'd rather say that 
device tree was coupled with kernel version it came from, so Samsung-
specific bindings haven't been fully stabilized yet, especially since we 
are still at discussion stage when it's about defining processes for 
binding staging and stabilization.

I would rather see this patch as part of work on Samsung DT binding 
janitoring or maybe even sanitizing in some cases, like this one, when the 
old (and IMHO bad) MFC binding was introduced without proper review. I 
don't think we want to support this kind of brokenness anymore, especially 
considering the hacks which would be required by such support (see 
original implementation of this binding and code required in board file).

> > +Two child nodes must be defined for MFC device. Their names must be
> > +following: "memport-r" and "memport-l" ("right" and "left"). Required
> 
> Node names shouldn't have semantic meaning.

What about bus-master-0 and bus-master-1?

> > +properties:
> > +  - compatible : value should be "samsung,memport"
> 
> There's no need to define compatible properties for things which aren't
> separate devices.

I agree.

> > +  - dma-memory-region : optional property with a phandle to
> > respective memory + region (see 
devicetree/bindings/memory.txt), if
> > no region
> > +   is defined, sysmmu controller must be used for 
managing
> > +   limited dma window of each memory port.
> 
> What's the benefit of putting this property in a sub-node; surely you
> can put the property in the main MFC node yet follow the same conceptual
> schema for its content as a dma-memory-region node?

See my use case description above.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

[Stephen Warren]

On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
> MFC driver use custom bindings for managing reserved memory. Those bindings
> are not really specific to MFC device and no even well discussed. They can
> be easily replaced with generic, platform independent code for handling
> reserved and contiguous memory.
> 
> Two additional child devices for each memory port (AXI master) are
> introduced to let one assign some properties to each of them. Later one
> can also use them to assign properties related to SYSMMU controllers,
> which can be used to manage the limited dma window provided by those
> memory ports.

> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
> b/Documentation/devicetree/bindings/media/s5p-mfc.txt

> +The MFC device is connected to system bus with two memory ports (AXI
> +masters) for better performance. Those memory ports are modelled as
> +separate child devices, so one can assign some properties to them (like
> +memory region for dma buffer allocation or sysmmu controller).
> +
>  Required properties:
>- compatible : value should be either one among the following
>   (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
>   (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
> + and additionally "simple-bus" to correctly initialize child
> + devices for memory ports (AXI masters)

simple-bus is wrong here; the child nodes aren't independent entities
that can be instantiated separately from their parent and without
depending on their parent.

> -  - samsung,mfc-r : Base address of the first memory bank used by MFC
> - for DMA contiguous memory allocation and its size.
> -
> -  - samsung,mfc-l : Base address of the second memory bank used by MFC
> - for DMA contiguous memory allocation and its size.

These properties shouldn't be removed, but simply marked deprecated. The
driver will need to continue to support them so that old DTs work with
new kernels. The binding must therefore continue to document them so
that the old DT content still makes sense.

> +Two child nodes must be defined for MFC device. Their names must be
> +following: "memport-r" and "memport-l" ("right" and "left"). Required

Node names shouldn't have semantic meaning.

> +properties:
> +  - compatible : value should be "samsung,memport"

There's no need to define compatible properties for things which aren't
separate devices.

> +  - dma-memory-region : optional property with a phandle to respective memory
> + region (see devicetree/bindings/memory.txt), if no 
> region
> + is defined, sysmmu controller must be used for managing
> + limited dma window of each memory port.

What's the benefit of putting this property in a sub-node; surely you
can put the property in the main MFC node yet follow the same conceptual
schema for its content as a dma-memory-region node?
--
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 v3 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation

[Stephen Warren]

On 08/05/2013 04:37 PM, Sylwester Nawrocki wrote:
> On 08/05/2013 06:53 PM, Stephen Warren wrote:
>> On 08/03/2013 03:41 PM, Sylwester Nawrocki wrote:
>>> On 08/02/2013 05:02 PM, Arun Kumar K wrote:
 The patch adds the DT binding documentation for Samsung
 Exynos5 SoC series imaging subsystem (FIMC-IS).
>>
 diff --git
 a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
 b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
 new file mode 100644
 index 000..49a373a
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
 @@ -0,0 +1,52 @@
 +Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS)
 +--
 +
 +The camera subsystem on Samsung Exynos5 SoC has some changes relative
 +to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and
 +FIMC-LITE IPs but has a much improved version of FIMC-IS which can
 +handle sensor controls and camera post-processing operations. The
 +Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many
 +post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two
 +dedicated scalers (SCC and SCP).
>>
>> So there are a lot of blocks mentioned there, yet the binding doesn't
>> seem to describe most of it. Is the binding complete?
> 
> Thanks for the review Stephen.
> 
> No, the binding certainly isn't complete, it doesn't describe the all
> available IP blocks. There are separate MMIO address regions for each
...
> So while we could list all the devices, we decided not to do so.
> Because it is not needed by the current software and we may miss some
> details for case where the whole subsystem is controlled by the host
> CPU (however such scenario is extremely unlikely AFAICT) which then
> would be impossible or hard to change.

Yes, that's probably a good approach.

> I guess we should list all available devices, similarly as it's done
> in Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt.
> 
> And then should they just be disabled through the status property
> if they are not needed in the Linux driver ? I guess it is more
> sensible than marking them as optional and then not listing them
> in dts at all ?

If you can define complete bindings for those nodes, it might make sense
to do that. If the devices are perhaps complex to represent and hence
you might not be able to come up with complete bindings for them right
now, it may indeed be better to simply not mention the devices you don't
care about for now.

 +pmu subnode
 +---
 +
 +Required properties:
 + - reg : should contain PMU physical base address and size of the
 memory
 + mapped registers.
>>
>> I think you need a compatible value for this. How else is the node
>> identified? The node name probably should not be used for identification.
> 
> Of course the node name is currently used for identification. There is no
> compatible property because this pmu node is used to get hold of only part
> of the Power Management Unit registers, specific to the FIMC-IS.
> The PMU has more registers that also other drivers would be interested in,
> e.g. clocks or USB.

I believe the correct way to solve this is for there to be a standalone
PMU node at the appropriate location in DT, and for the FIMC bindings to
reference that other node by phandle.

Right now, the FIMC driver SW can manually follow the phandle, look at
the reg property, and map that itself. Later down the road, you could
instantiate a true PMU driver, and have the FIMC driver look up that
driver, and call APIs on it. This change can be made without requiring
any changes to the DT binding. That way, you aren't introducing a fake
PMU node into the FIMC bindings just to satisfy internal Linux driver
details.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 03/16] iommu/exynos: fix page table maintenance

[Grant Grundler]

Tomasz,

On Thu, Aug 8, 2013 at 6:54 AM, Tomasz Figa  wrote:
...
>> + BUG_ON(lv1ent_section(sent));
>
> Is this condition really a critical one, to the point that the system
> should not continue execution?
>
...
>>   if (lv1ent_page(sent)) {
>> - if (*pgcnt != NUM_LV2ENTRIES)
>> - return -EADDRINUSE;
>> -
>> + BUG_ON(*pgcnt != NUM_LV2ENTRIES);
>
> Ditto.

I can't speak to the previous BUG_ON(). I believe the EADDRESSINUSE
failures could be either WARN_ON or BUG_ON.   This condition is
clearly a bug in the generic IOMMU allocator and I think that's why
KyongHo Cho used BUG_ON.

Handing out duplicate addresses will generally lead to some sort of
data corruption or other fault depending on how robust the underlying
device drivers are written.  So my preference is a BUG_ON to
immediately flag this condition instead of hoping a device driver will
correctly handling the dma mapping failure (Some do, most currently
don't).

WARN_ON() + return -EADDRESSINUSE would be a good alternative.

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling

[Julius Werner]

> I'm not sure I understand. The old documentation referred to the
> USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
> your new version only refers to (usb device) PHY_CONTROL. Regardless of
> multiple phys, you're suggesting that we describe less of each phy.
> That seems like taking away usable information. Unless I've
> misunderstood?

Well that's just the thing that's confusing right now, and which I am
trying to fix: every PHY is either DEVICE or HOST and thus has only
one PMU register. The current code describes the PMU register space
for all PHYs on the system in the DT entry of every PHY and then
calculates which register to use with hardcoded offsets. I think it
makes much more sense if every PHY only describes its own register and
doesn't need to do address arithmetic later on.

As Vivek said there is one exception in an old Exynos4, but that is
currently not implemented in the upstream kernel anyway, and if it
ever will be it's still much easier to special case one weird chip
than to have a super complicated and confusing mechanism for all of
them.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 13/20] pwm: Add new pwm-samsung driver

[Andrew Bresticker]

> ..it should not be defined as non-static in this case (= an ifdef is
> needed in this header). I believe I had this already fixed, not sure what
> happened with the fix...

Perhaps this is it: https://patchwork.kernel.org/patch/2787271/.  That
should probably land with this patchset too.

Thanks,
Andrew
--
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: EXYNOS: add power domains support for EXYNOS5440

[Mark Rutland]

On Tue, Aug 06, 2013 at 05:16:56PM +0100, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Saturday, August 03, 2013 09:14:11 PM Mark Rutland wrote:
> > On Fri, Aug 02, 2013 at 10:01:52PM +0100, Stephen Warren wrote:
> > > (CCing the other DT maintainers, hence quoting binding in full)
> > > 
> > > On 08/02/2013 07:23 AM, Bartlomiej Zolnierkiewicz wrote:
> > > > On EXYNOS5440 power domains are handled in a different way than on
> > > > the previous EXYNOS SoCs. Add support for them to EXYNOS pm_domains
> > > > driver. Then add device tree nodes for PCIe (controlling power for
> > > > PCIe host controller) and Conn2 (controlling power for Ethernet,
> > > > SATA and USB controllers) power domains to exynos5440.dtsi.
> > > > 
> > > > Currently if runtime Power Management is enabled and the driver
> > > > for devices under power domain is disabled then the power domain
> > > > will be disabled by EXYNOS pm_domains driver. To make more active
> > > > use of power domains (dynamically enable and disabled them as
> > > > needed) it is required to add runtime PM support to pci-exynos,
> > > > stmmac, ahci_platform, ohci-exynos and ehci-s5p drivers (to be
> > > > done later).
> > > > 
> > > > Signed-off-by: Bartlomiej Zolnierkiewicz 
> > > > Signed-off-by: Myungjoo Ham 
> > > > Cc: Tomasz Figa 
> > > > Cc: Stephen Warren 
> > > > ---
> > > >  Documentation/devicetree/bindings/arm/exynos/power_domain.txt |   33 ++
> > > >  arch/arm/boot/dts/exynos5440.dtsi |   23 +
> > > >  arch/arm/mach-exynos/Kconfig  |1 
> > > >  arch/arm/mach-exynos/common.c |4 
> > > >  arch/arm/mach-exynos/pm_domains.c |  138 
> > > > +-
> > > >  5 files changed, 190 insertions(+), 9 deletions(-)
> > > > 
> > > > Index: b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> > > > ===
> > > > --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
> > > > 2013-08-02 14:45:53.551392396 +0200
> > > > +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
> > > > 2013-08-02 14:46:29.799391845 +0200
> > > > @@ -5,20 +5,47 @@ to gate power to one or more peripherals
> > > >  
> > > >  Required Properties:
> > > >  - compatible: should be one of the following.
> > > > -* samsung,exynos4210-pd - for exynos4210 type power domain.
> > > > +* samsung,exynos4210-pd - for Exynos4210 type power domain.
> > > > +* samsung,exynos5440-pd - for Exynos5440 type power domain.
> > > >  - reg: physical base address of the controller and length of memory 
> > > > mapped
> > > > -region.
> > > > +region (Exynos4210 type power domain) or bit offset in the control
> > > > +register (Exynos5440 type power domain).
> > > > +
> > > > +Additional parent node must be created for Exynos5440 power domains 
> > > > with
> > > > +the following required properties:
> > > > +- compatible: samsung,exynos5440-power-domains, simple-bus
> > > > +- reg: physical base address of the XMU controller and length of memory
> > > > +mapped region
> > > 
> > > It's a little odd to describe the child nodes first. Given the 4210 and
> > > 5440 bindings work so differently, I'd suggest making separate binding
> > > files for the two; samsung,exynos4210-pd.txt and 
> > > samsung,exynos5440-pd.txt.
> 
> OK, I'll fix it.
> 
> > > The node being describe here clearly is not a simple-bus; the child
> > > nodes appear to have a specific need that their parent be compatible =
> > > "samsung,exynos5440-power-domains", hence they aren't the independent
> > > devices that simple-bus would usually contain.
> > 
> > +1. This is most definitely not a simple-bus, the child nodes reg
> > properties cdon't represent the same address space as the
> > parent's reg property.
> 
> What does in mean in the practice? What should I do instead?

The driver for the parent nodes should probe for the child nodes via
some mechanism. The "simple-bus" compatible property should be removed
from the parent node as it's simply not true.

Simple-bus should only be used where the child nodes make sense and are
useable on their own, regardless of the parent node.

> 
> > How much does the association of bit-offsets to power domains vary? 
> 
> On EXYNOS5440 power domains are controlled by control and status registers
> which are shared among all power domains. On other EXYNOS SoCs there are
> separate control/status registers for each power domain.

Ok.

> 
> > > Note that I only briefly reviewed the low-level structural aspects of
> > > the binding that I mentioned above; I haven't thought about the binding
> > > at a higher level of e.g. "does this binding conceptually make sense".
> > 
> > This is unfortunately difficult to do :(
> > 
> > > 
> > > >  Node of a device using power domains must have a samsung,power-domain 
> > > > property
> > > >  defined with

Re: [PATCH v9 04/16] iommu/exynos: allocate lv2 page table from own slab

[Tomasz Figa]

On Thursday 08 of August 2013 18:38:04 Cho KyongHo wrote:
> Since kmalloc() does not guarantee that the allignment of 1KiB when it
> allocates 1KiB, it is required to allocate lv2 page table from own
> slab that guarantees alignment of 1KiB
> 
> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/exynos-iommu.c |   24 
>  1 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index d90e6fa..a318049 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -100,6 +100,8 @@
>  #define REG_PB1_SADDR0x054
>  #define REG_PB1_EADDR0x058
> 
> +static struct kmem_cache *lv2table_kmem_cache;
> +
>  static unsigned long *section_entry(unsigned long *pgtable, unsigned
> long iova) {
>   return pgtable + lv1ent_offset(iova);
> @@ -765,7 +767,8 @@ static void exynos_iommu_domain_destroy(struct
> iommu_domain *domain)
> 
>   for (i = 0; i < NUM_LV1ENTRIES; i++)
>   if (lv1ent_page(priv->pgtable + i))
> - kfree(__va(lv2table_base(priv->pgtable + i)));
> + kmem_cache_free(lv2table_kmem_cache,
> + __va(lv2table_base(priv->pgtable + i)));
> 
>   free_pages((unsigned long)priv->pgtable, 2);
>   free_pages((unsigned long)priv->lv2entcnt, 1);
> @@ -861,7 +864,7 @@ static unsigned long *alloc_lv2entry(unsigned long
> *sent, unsigned long iova, if (lv1ent_fault(sent)) {
>   unsigned long *pent;
> 
> - pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
> + pent = kmem_cache_zalloc(lv2table_kmem_cache, GFP_ATOMIC);
>   BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
>   if (!pent)
>   return ERR_PTR(-ENOMEM);
> @@ -881,7 +884,7 @@ static int lv1set_section(unsigned long *sent,
> phys_addr_t paddr, short *pgcnt)
> 
>   if (lv1ent_page(sent)) {
>   BUG_ON(*pgcnt != NUM_LV2ENTRIES);
> - kfree(page_entry(sent, 0));
> + kmem_cache_free(lv2table_kmem_cache, page_entry(sent, 0));
>   *pgcnt = 0;
>   }
> 
> @@ -1082,10 +1085,23 @@ static int __init exynos_iommu_init(void)
>  {
>   int ret;
> 
> + lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
> + LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
> + if (!lv2table_kmem_cache) {
> + pr_err("%s: Failed to create kmem cache\n", __func__);
> + return -ENOMEM;
> + }
> +
>   ret = platform_driver_register(&exynos_sysmmu_driver);
> 
>   if (ret == 0)
> - bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
> + ret = bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
> +
> + if (ret) {
> + pr_err("%s: Failed to register exynos-iommu driver.\n",
> + __func__);
> + kmem_cache_destroy(lv2table_kmem_cache);
> + }

What about making the return value handling here cleaner? For example:

lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
if (!lv2table_kmem_cache) {
...
return -ENOMEM;
}

ret = platform_driver_register(&exynos_sysmmu_driver);
if (ret) {
...
goto err_destroy_kmem_cache;
}

ret = bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
if (ret) {
...
goto err_platform_unregister;
}

return 0;

err_platform_unregister:
...
err_destroy_kmem_cache:
...
return ret;
}

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 03/16] iommu/exynos: fix page table maintenance

[Tomasz Figa]

On Thursday 08 of August 2013 18:37:43 Cho KyongHo wrote:
> This prevents allocating lv2 page table for the lv1 page table entry
  ^ What this is this this about? :)

> that already has 1MB page mapping. In addition, changed to BUG_ON
> instead of returning -EADDRINUSE.

The change mentioned in last sentence should be a separate patch.

> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/exynos-iommu.c |   68
> - 1 files changed, 40
> insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index d545a25..d90e6fa 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -52,11 +52,11 @@
>  #define lv2ent_large(pent) ((*(pent) & 3) == 1)
> 
>  #define section_phys(sent) (*(sent) & SECT_MASK)
> -#define section_offs(iova) ((iova) & 0xF)
> +#define section_offs(iova) ((iova) & ~SECT_MASK)
>  #define lpage_phys(pent) (*(pent) & LPAGE_MASK)
> -#define lpage_offs(iova) ((iova) & 0x)
> +#define lpage_offs(iova) ((iova) & ~LPAGE_MASK)
>  #define spage_phys(pent) (*(pent) & SPAGE_MASK)
> -#define spage_offs(iova) ((iova) & 0xFFF)
> +#define spage_offs(iova) ((iova) & ~SPAGE_MASK)
> 
>  #define lv1ent_offset(iova) ((iova) >> SECT_ORDER)
>  #define lv2ent_offset(iova) (((iova) & 0xFF000) >> SPAGE_ORDER)
> @@ -856,13 +856,15 @@ finish:
>  static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long
> iova, short *pgcounter)
>  {
> + BUG_ON(lv1ent_section(sent));

Is this condition really a critical one, to the point that the system 
should not continue execution?

> +
>   if (lv1ent_fault(sent)) {
>   unsigned long *pent;
> 
>   pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
>   BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
>   if (!pent)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
> 
>   *sent = mk_lv1ent_page(__pa(pent));
>   *pgcounter = NUM_LV2ENTRIES;
> @@ -875,15 +877,11 @@ static unsigned long *alloc_lv2entry(unsigned long
> *sent, unsigned long iova,
> 
>  static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short
> *pgcnt) {
> - if (lv1ent_section(sent))
> - return -EADDRINUSE;
> + BUG_ON(lv1ent_section(sent));

Ditto.

>   if (lv1ent_page(sent)) {
> - if (*pgcnt != NUM_LV2ENTRIES)
> - return -EADDRINUSE;
> -
> + BUG_ON(*pgcnt != NUM_LV2ENTRIES);

Ditto.

>   kfree(page_entry(sent, 0));
> -
>   *pgcnt = 0;
>   }
> 
> @@ -894,24 +892,24 @@ static int lv1set_section(unsigned long *sent,
> phys_addr_t paddr, short *pgcnt) return 0;
>  }
> 
> +static void clear_page_table(unsigned long *ent, int n)
> +{
> + if (n > 0)
> + memset(ent, 0, sizeof(*ent) * n);
> +}

I don't see the point of creating this function. It seems to be used only 
once, in addition with a constant as n, so the check for n > 0 is 
unnecessary.

And even if there is a need for this change, it should be done in separate 
patch, as this one is not about stylistic changes, but fixing page table 
maintenance (at least based on your commit message).

>  static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t
> size, short *pgcnt)
>  {
>   if (size == SPAGE_SIZE) {
> - if (!lv2ent_fault(pent))
> - return -EADDRINUSE;
> -
> + BUG_ON(!lv2ent_fault(pent));

Ditto.

>   *pent = mk_lv2ent_spage(paddr);
>   pgtable_flush(pent, pent + 1);
>   *pgcnt -= 1;
>   } else { /* size == LPAGE_SIZE */
>   int i;
>   for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
> - if (!lv2ent_fault(pent)) {
> - memset(pent, 0, sizeof(*pent) * i);
> - return -EADDRINUSE;
> - }
> -
> + BUG_ON(!lv2ent_fault(pent));

Ditto.

>   *pent = mk_lv2ent_lpage(paddr);
>   }
>   pgtable_flush(pent - SPAGES_PER_LPAGE, pent);
> @@ -944,17 +942,16 @@ static int exynos_iommu_map(struct iommu_domain
> *domain, unsigned long iova, pent = alloc_lv2entry(entry, iova,
>   &priv->lv2entcnt[lv1ent_offset(iova)]);
> 
> - if (!pent)
> - ret = -ENOMEM;
> + if (IS_ERR(pent))
> + ret = PTR_ERR(pent);
>   else
>   ret = lv2set_page(pent, paddr, size,
>   &priv->lv2entcnt[lv1ent_offset(iova)]);
>   }
> 
> - if (ret) {
> - pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
> - __func__, iova, size);
> - }
> + if (ret)
> + pr_err("%s: Failed(%d) to map 0x%#x bytes @ %#lx\n",
> +

Re: [PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries

[Tomasz Figa]

On Thursday 08 of August 2013 18:37:34 Cho KyongHo wrote:
> This commit adds cache flush for removed small and large page entries
> in exynos_iommu_unmap(). Missing cache flush of removed page table
> entries can cause missing page fault interrupt when a master IP
> accesses an unmapped area.
> 
> Tested-by: Grant Grundler 
> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/exynos-iommu.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 233f382..d545a25 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct
> iommu_domain *domain, if (lv2ent_small(ent)) {
>   *ent = 0;
>   size = SPAGE_SIZE;
> + pgtable_flush(ent, ent + 1);
>   priv->lv2entcnt[lv1ent_offset(iova)] += 1;
>   goto done;
>   }
> @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct
> iommu_domain *domain, BUG_ON(size < LPAGE_SIZE);
> 
>   memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
> + pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
> 
>   size = LPAGE_SIZE;
>   priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;

Looks reasonable.

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 01/16] iommu/exynos: do not include removed header

[Tomasz Figa]

Hi KyongHo,

On Thursday 08 of August 2013 18:37:25 Cho KyongHo wrote:
> This commit remove  which is removed.

I would prefer a more meaningful commit message, something among following 
lines:

8<---
Commit 25e9d28d92 (ARM: EXYNOS: remove system mmu initialization from 
exynos tree) removed arch/arm/mach-exynos/mach/sysmmu.h header without 
removing remaining use of it from exynos-iommu driver, thus causing a 
compilation error.

This patch fixes the error by removing respective include line from exynos-
iommu.c.
--->8

Also a sentence explaining why linux/kernel.h header must be included would 
be nice.

> Signed-off-by: Cho KyongHo 

Please note that as far as I'm aware of, tags should be made using western 
name writing convention, i.e. starting with first name.

Best regards,
Tomasz

> ---
>  drivers/iommu/exynos-iommu.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 3f32d64..233f382 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -12,6 +12,7 @@
>  #define DEBUG
>  #endif
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,8 +30,6 @@
>  #include 
>  #include 
> 
> -#include 
> -
>  /* We does not consider super section mapping (16MB) */
>  #define SECT_ORDER 20
>  #define LPAGE_ORDER 16
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs

[Rob Herring]

On Thu, Aug 1, 2013 at 8:05 AM, Cho KyongHo  wrote:
>> -Original Message-
>> From: Rob Herring [mailto:robherri...@gmail.com]
>> Sent: Saturday, July 27, 2013 10:55 PM
>> On Fri, Jul 26, 2013 at 6:28 AM, Cho KyongHo  wrote:
>> > Signed-off-by: Cho KyongHo 
>> > ---
>> >  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
>> >  arch/arm/boot/dts/exynos4.dtsi |  122 
>> >  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
>> >  arch/arm/boot/dts/exynos4x12.dtsi  |   76 +
>> >  arch/arm/boot/dts/exynos5250.dtsi  |  291 
>> > 
>> >  5 files changed, 617 insertions(+), 0 deletions(-)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
>> >
>> > diff --git 
>> > a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
>> > b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
>> > new file mode 100644
>> > index 000..92f0a33
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
>> > @@ -0,0 +1,103 @@
>> > +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
>> > +
>> > +Samsung's Exynos architecture contains System MMU that enables scattered
>> > +physical memory chunks visible as a contiguous region to DMA-capable 
>> > peripheral
>> > +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
>> > +
>> > +System MMU is a sort of IOMMU and support identical translation table 
>> > format to
>> > +ARMv7 translation tables with minimum set of page properties including 
>> > access
>> > +permissions, shareability and security protection. In addition, System 
>> > MMU has
>> > +another capabilities like L2 TLB or block-fetch buffers to minimize 
>> > translation
>> > +latency.
>> > +
>> > +A System MMU is dedicated to a single master peripheral device.  Thus, it 
>> > is
>> > +important to specify the correct System MMU in the device node of its 
>> > master
>> > +device. Whereas a System MMU is dedicated to a master device, the master 
>> > device
>> > +may have more than one System MMU.
>>
>> I don't follow the last sentence. Can you elaborate on the type of
>> connection you are talking about.
>>
> Grant also addressed that.
> He corrected the sentence like the following:
>
>   " Can I suggest rewriting the last two sentences to:
>  The master device node must correctly specify at least one
>  SystemMMU. A master  device may have more than one System MMU. "
>
> I will change the sentence
>
>> Also, please align with the ARM system MMU binding that Will Deacon
>> has submitted particularly in terms of how master connections are
>> described.
>>
> I didn't check it.
>
> Should this align with ARM System MMU bindings?
> System MMU in Exynos SoC is different from ARM System MMU.
> It does not follows the specifications of ARM System MMU.

I'm not saying the h/w is the same or even the same spec, but how you
describe a master to iommu connection needs to be done in the same
way. This should be done in the same way for ALL iommu's. And if what
is defined does not work for you, then we need to understand that and
fix the binding now.

Rob
--
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 v9 00/16] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

[Tomasz Figa]

Hi KyongHo,

Just a little hint for future:

To make reviewing your patches easier, please send all patches (01 and 
further) as a follow up (reply) to cover letter of the series (patch 00).

This can be achieved by using --thread switch of git send-email for 
example.

Best regards,
Tomasz

On Thursday 08 of August 2013 18:37:10 Cho KyongHo wrote:
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is
> disabled before MFC block is power-down not to invalidate IOTLB in the
> System MMU when I/O memory mapping is changed. Because a System MMU
> resides in the same H/W block, access to control registers of System MMU
> while the H/W block is turned off must be prohibited.
> 
> This set of changes solves the above problem with setting each System
> MMUs as the parent of the device which owns the System MMU to receive
> the information when the device is turned off or turned on.
> 
> Another big change to the driver is the support for devicetree.
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
> 
> In addition, this patchset also includes several bug fixes and
> enhancements of the current driver.
> 
> Change log:
> v9:
> - Rebased on the following branches
>   git.linaro.org/git-ro/people/mturquette/linux.git/clk-next
>  
> git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/samsung-
> next git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> (3.11-rc4) - Split "add bus notifier for registering System MMU" into 5
> patches - Call clk_prepare() that was missing in v8.
> - Fixed base address of sysmmu_tv in exynos4210.dtsi
> - BUG_ON() instead of return -EADDRINUSE when trying mapping on an mapped
> area - Moved camif_top to 317 in drivers/clk/samsung/clk-exynos5250.c -
> Removed 'iommu' property from 'codec'(mfc) node
> - Does not make 'master' clock to be the parent of 'sysmmu' clock.
>'master' clock is enabled before accessing control registers of System
> MMU and disabled after the access.
> 
> v8:
> - Reordered patch list: moved "change rwloc to spinlock" to the last.
> - Fixed remained bug in "fix page table maintenance".
> - Always return 0 from exynos_iommu_attach_device().
> - Removed prefetch buffer setting when System MMU is enabled
>   due to the restriction of prefetch buffers:
>   A prefetch buffer must not hit from more than one DMA.
>   For instance with GScalers, if a single prefetch buffer is initialized
>   with 0x0 ~ 0x and a GScaler works on source buffer at
> 0x1000 and target buffer @ 0x2000, the System MMU may be got
> deadlock. Clients must initialize prefetch buffers with custom function
> defined in exynos-iommu drivers whenever they need to enable prefetch
> buffers. - The clock of System MMU has no relationship with the clock of
> its master H/W. The clock of master H/W is always enabled when
> exynos-iommu driver needs to access MMIO area and disabled as soon as
> the access finishes. - Removed err_page variable used in
> exynos_iommu_unmap() in the previous patch "fix page table maintenance".
> - Split a big patch "add bus notifier for registering System MMU".
>Extracted the following 2 patches: 9/12 and 10/12.
> - And some additional fixes...
> 
> v7:
> - Rebased on the stable 3.10
> - Registered PM domains and gate clocks with DT
> - Changed connection method between a System MMU and its master H/W
>'mmu-master' property in the node of System MMU
>--> 'iommu' property in the node of master H/W
> - Marking device descriptor of master H/W of a System MMU with bus
> notifier. - Power management (PM_RUNTIME, PM_SLEEP) of System MMUs with
> gpd_dev_ops of Generic IO Powerdomain. gpd_dev_ops are set to the master
> H/Ws before they are probed in the bus notifier.
> - Removed additional debugging features like debugfs entries and
>version names.
> - Removed support for advanced features of System MMU 3.2 and 3.3
>the current IOMMU API cannot handle the feature
>   (A kind of L2 TLB that fetches several consequence page table entries.
>It must be initialized by the driver of master H/W whenever it works.)
> 
> v6:
> - Rebased on the branch, next/iommu-exynos of
>   git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> 
> v5:
> - new bugfix: patch 01
> - Reordered patches
>   * patch 01 ~ 05: Bugfix and enhancements of the existing driver
>   * patch 06 ~ 10: Device Tree support and callbacks for power management
> * patch 11 : System MMU 3.2 and 3.3 support
>   * patch 12 ~ 14: Debugging features
> - Additional code compaction
> 
> v4:
> - Remove Change-Id from v3 patches
> - Change the order of the third and the first patch
>   Thanks to Kukjin Kim.
> - Fix memory leak when allocating and assigning exynos_iommu_owner to
> client device if the client device has multiple System MMUs.
>

Re: [PATCH v9 05/16] clk: exynos: add gate clock descriptions of System MMU

[Tomasz Figa]

On Thursday 08 of August 2013 13:17:34 Sylwester Nawrocki wrote:
> On 08/08/2013 11:38 AM, Cho KyongHo wrote:
> > This adds gate clocks of all System MMUs and their master IPs
> > that are not apeared in clk-exynos5250.c
> > Also fixes GATE_IP_ACP to 0x18800 and changed GATE_DA to GATE
> > for System MMU clocks in clk-exynos4.c
> > 
> > Signed-off-by: Cho KyongHo 
> > ---
> > 
> >  .../devicetree/bindings/clock/exynos5250-clock.txt |   26 +
> >  drivers/clk/samsung/clk-exynos4.c  |   27 +++--
> >  drivers/clk/samsung/clk-exynos5250.c   |   57
> >   3 files changed, 82 insertions(+), 28
> >  deletions(-)
> 
> [...]
> 
> > @@ -349,19 +358,26 @@ static struct samsung_gate_clock
> > exynos5250_gate_clks[] __initdata = {> 
> > GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
> > GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
> > GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
> > 
> > -   GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
> > -   GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> > -   GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> > -   GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> > +   GATE(smmu_gscl0, "smmu_gscl0", "none", GATE_IP_GSCL, 7, 0, 0),
> > +   GATE(smmu_gscl1, "smmu_gscl1", "none", GATE_IP_GSCL, 8, 0, 0),
> > +   GATE(smmu_gscl2, "smmu_gscl2", "none", GATE_IP_GSCL, 9, 0, 0),
> > +   GATE(smmu_gscl3, "smmu_gscl3", "none", GATE_IP_GSCL, 10, 0, 0),
> 
> Why are the smmu clocks' parent clocks removed ? Shouldn't both the
> gscaler gate clock and the gscaler smmu clock be still same, as it is in
> case of exynos4 ?

I agree with Sylwester.

In fact, it is not a valid clock setup. A valid clock must be either root 
clock (indicated by appropriate clock flag and specified frequency) or have 
a valid parent.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 05/16] clk: exynos: add gate clock descriptions of System MMU

[Sylwester Nawrocki]

On 08/08/2013 11:38 AM, Cho KyongHo wrote:
> This adds gate clocks of all System MMUs and their master IPs
> that are not apeared in clk-exynos5250.c
> Also fixes GATE_IP_ACP to 0x18800 and changed GATE_DA to GATE
> for System MMU clocks in clk-exynos4.c
> 
> Signed-off-by: Cho KyongHo 
> ---
>  .../devicetree/bindings/clock/exynos5250-clock.txt |   26 +
>  drivers/clk/samsung/clk-exynos4.c  |   27 +++--
>  drivers/clk/samsung/clk-exynos5250.c   |   57 
> 
>  3 files changed, 82 insertions(+), 28 deletions(-)
[...]
> @@ -349,19 +358,26 @@ static struct samsung_gate_clock exynos5250_gate_clks[] 
> __initdata = {
>   GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
>   GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
>   GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
> - GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
> - GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> - GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> - GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> + GATE(smmu_gscl0, "smmu_gscl0", "none", GATE_IP_GSCL, 7, 0, 0),
> + GATE(smmu_gscl1, "smmu_gscl1", "none", GATE_IP_GSCL, 8, 0, 0),
> + GATE(smmu_gscl2, "smmu_gscl2", "none", GATE_IP_GSCL, 9, 0, 0),
> + GATE(smmu_gscl3, "smmu_gscl3", "none", GATE_IP_GSCL, 10, 0, 0),

Why are the smmu clocks' parent clocks removed ? Shouldn't both the gscaler
gate clock and the gscaler smmu clock be still same, as it is in case of
exynos4 ?
--
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] clk: samsung: Staticise non-exported symbols for PLLs

[Mark Brown]

From: Mark Brown 

These symbols are not used outside the files they are defined in so do
not need to be in the global namespace and they aren't declared so sparse
warns.

Signed-off-by: Mark Brown 
---
 drivers/clk/samsung/clk-exynos4.c| 2 +-
 drivers/clk/samsung/clk-exynos5250.c | 2 +-
 drivers/clk/samsung/clk-exynos5420.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index 68f9a4a..fec319d 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -984,7 +984,7 @@ static __initdata struct of_device_id ext_clk_match[] = {
{},
 };
 
-struct __initdata samsung_pll_clock exynos4_plls[nr_plls] = {
+static struct __initdata samsung_pll_clock exynos4_plls[nr_plls] = {
[apll] = PLL_A(pll_35xx, fout_apll, "fout_apll", "fin_pll", APLL_LOCK,
APLL_CON0, "fout_apll", NULL),
[mpll] = PLL_A(pll_35xx, fout_mpll, "fout_mpll", "fin_pll",
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index df3628c..5865cef 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -517,7 +517,7 @@ static __initdata struct samsung_pll_rate_table 
epll_24mhz_tbl[] = {
{ },
 };
 
-struct __initdata samsung_pll_clock exynos5250_plls[nr_plls] = {
+static struct __initdata samsung_pll_clock exynos5250_plls[nr_plls] = {
[apll] = PLL_A(pll_35xx, fout_apll, "fout_apll", "fin_pll", APLL_LOCK,
APLL_CON0, "fout_apll", NULL),
[mpll] = PLL_A(pll_35xx, fout_mpll, "fout_mpll", "fin_pll", MPLL_LOCK,
diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index ca352695..872e13d 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -727,7 +727,7 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(smmu_mscl2, "smmu_mscl2", "aclk400_mscl", GATE_IP_MSCL, 10, 0, 0),
 };
 
-struct __initdata samsung_pll_clock exynos5420_plls[nr_plls] = {
+static struct __initdata samsung_pll_clock exynos5420_plls[nr_plls] = {
[apll] = PLL(pll_2550, fout_apll, "fout_apll", "fin_pll", APLL_LOCK,
APLL_CON0, NULL),
[cpll] = PLL(pll_2550, fout_mpll, "fout_mpll", "fin_pll", MPLL_LOCK,
-- 
1.8.4.rc1

--
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 v9 06/16] ARM: dts: Add description of System MMU of Exynos SoCs

[Sylwester Nawrocki]

Hi,

On 08/08/2013 11:38 AM, Cho KyongHo wrote:

How about something along the lines of:

"This patch adds dts entries for the SYSMMU devices found on Exynos4
and Exynos5 SoC series and the SYSMMU binding documentation."

instead of this empty changelog ?

> Signed-off-by: Cho KyongHo 
> ---
>  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
>  arch/arm/boot/dts/exynos4.dtsi |  122 
>  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
>  arch/arm/boot/dts/exynos4x12.dtsi  |   82 ++
>  arch/arm/boot/dts/exynos5250.dtsi  |  290 
> 
>  5 files changed, 622 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> new file mode 100644
> index 000..92f0a33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> @@ -0,0 +1,103 @@
> +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
> +
> +Samsung's Exynos architecture contains System MMU that enables scattered
> +physical memory chunks visible as a contiguous region to DMA-capable 
> peripheral
> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.

s/so forth/and more ?

> +
> +System MMU is a sort of IOMMU and support identical translation table format 
> to

s/support/supports ?

> +ARMv7 translation tables with minimum set of page properties including access
> +permissions, shareability and security protection. In addition, System MMU 
> has
> +another capabilities like L2 TLB or block-fetch buffers to minimize 
> translation
> +latency.
> +
> +A System MMU is dedicated to a single master peripheral device.  Thus, it is
> +important to specify the correct System MMU in the device node of its master
> +device. Whereas a System MMU is dedicated to a master device, the master 
> device
> +may have more than one System MMU.
> +
> +Required properties:
> +- compatible: Should be "samsung,exynos4210-sysmmu"
> +- reg: A tuple of base address and size of System MMU registers.
> +- interrupt-parent: The phandle of the interrupt controller of System MMU
> +- interrupts: A tuple of numbers that indicates the interrupt source.

The interrupt specifier depends on the interrupt controller (interrupt-parent). 
So it might not always be a "tuple of numbers". It's probably better to say,
e.g.:

- interrupts: Should contain the SYSMMU controller interrupt.

> +- clock-names: Should be "sysmmu" if the System MMU is needed to gate its 
> clock.
> +   Please refer to the following documents:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +Documentation/devicetree/bindings/clock/exynos4-clock.txt
> +Documentation/devicetree/bindings/clock/exynos5250-clock.txt

You could replace "Documentation/devicetree/bindings/clock" with "../clock"

> +Optional "master" if the clock to the System MMU is gated by
> +another gate clock other than "sysmmu". The System MMU driver
> +sets "master" the parent of "sysmmu".
> +Exynos4 SoCs, there needs no "master" clocks.
> +Exynos5 SoCs, some System MMUs must have "master" clocks.
> +- clocks: Required if the System MMU is needed to gate its clock.
> +   Please refer to the documents listed above.
> +- samsung,power-domain: Required if the System MMU is needed to gate its 
> power.

Isn't it required always when an SoC support Power Domains and the SYSMMU
belongs to a power domain ? Perhaps something like:

- samsung,power-domain: Required if the System MMU belongs to a Power Domain.

would be more appropriate ?

> +   Please refer to the following document:
> +   Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +
> +Required properties for the master peripheral devices:
> +- iommu: phandles to the System MMUs of the device
> +
> +Examples:
> +A System MMU is dedicated to a single master device.
> + gsc_0:  gsc@0x13e0 {
> + compatible = "samsung,exynos5-gsc";
> + reg = <0x13e0 0x1000>;
> + interrupts = <0 85 0>;
> + samsung,power-domain = <&pd_gsc>;
> + clocks = <&clock 256>;
> + clock-names = "gscl";

You could omit all the above properties, perhaps just leaving
'compatible' property, simply replacing them with:
...

since the only relevant property hers is 'iommu' ? Just a suggestion
though.

> + iommu = <&sysmmu_gsc1>;

Shouldn't this be:

iommu = <&sysmmu_gsc0>;
? 
It also probably makes sense to put the SYMMU device node above 
the master device node.

> + };
> +
> + sysmmu_gsc0: sysmmu@13E8 {
> + compatible = "samsung,exynos4210-sy

Re: [PATCH V3 2/3] ASoC: Samsung: I2S: Add quirks as driver data in I2S

[Mark Brown]

On Thu, Aug 08, 2013 at 01:13:02PM +0530, Padma Venkat wrote:

> If legacy platforms not required to change then I need to introduce a
> new samsung_i2s_dai_data structure which holds only dai_type for
> non-dt platforms. If I change legacy platforms it breaks the older
> platforms now. Is it okay adding a samsung_i2s_dai_data structure for
> non-dt platforms which will be removed later?

This is totally fine and looks much nicer - you're not creating DT style
names in the platform bus, nor making names that are so long that we
need to expand the maximum length of a plaform device name (which isn't
awesome).


signature.asc
Description: Digital signature

Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling

[Vivek Gautam]

On Thu, Aug 8, 2013 at 2:56 PM, Mark Rutland  wrote:
> On Wed, Aug 07, 2013 at 06:06:05PM +0100, Julius Werner wrote:
>> > This breaks compatibility, both for an old kernel and a new dt and a new
>> > kernel with an old dt. Is anyone using these bindings?
>>
>> They only affect Samsung SoCs and have only been upstream for half a
>> year, so I doubt it's heavily used.
>
> I'm not sure everyone will be happy with that line.
>
>>
>> > Why are we describing fewer registers now? Are they described elsewhere?
>> >
>> > The dt should describe the device, not only the portion of it Linux
>> > wants to use right now.
>>
>> This only ever described a small section of the huge set of PMU
>> registers anyway. Before it described up to three registers
>> controlling different PHYs (using hardcoded offsets in the code to
>> later find the right one)... with my patch every PHY's DT entry only
>> describes the one register concerning itself, which makes more sense
>> in my opinion. It will also prevent the register descriptions in
>> different DT entries from overlapping.
>>
>
> I'm not sure I understand. The old documentation referred to the
> USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
> your new version only refers to (usb device) PHY_CONTROL. Regardless of
> multiple phys, you're suggesting that we describe less of each phy.
> That seems like taking away usable information. Unless I've
> misunderstood?

Just giving some pointers here:

As also mentioned in the documentation for samsung-usbphy, SoCs prior
to exynos4x had only one PMU
register handling power to the PHYs (USB 2.0 phy to be specific).
Exynos4x SoCs also had USB 2.0 PHY only
but device and host PHYs' power was being handled by two registers
namely - USBDEVICE_PHY_CONTROL and
USBHOST_PHY_CONTROL.

Exynos5x series of SoCs now have USB 2.0 type PHY (both device and
host PHY are power-handled by only one register)
and USB 3.0 type PHY (having a separate PMU register to handle power
to PHY); so in a total of two registers but both
handling entirely separate PHYs.

So, samsung-usb2 phy driver should be interacting with only one PMU
register (with an exception for exynos4x)
and furthermore samsung-usb3phy driver interact with its separate PMU register.

Sylwester,
Please correct me if i am wrong somewhere.

>
> Ideally, we'd describe the whole set of registers and linkages to phys,
> even if Linux doesn't ahppen to use that information right now.
>
> Thanks,
> Mark.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek
--
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 v9 12/16] iommu/exynos: add bus notifier for registering System MMU

[Cho KyongHo]

When a device driver is registered, all constructs to handle System MMU
is prepared by bus notifier call.
This changes in how to retrieving System MMU from the device descriptor
of master H/W.

Previously archdata.iommu of master H/W contains the device descriptor
of System MMU and the device descriptor of System MMU has the list entry
of iommu_domain. In fact, System MMU is attached to iommu_domain.

This changes what is actually attached to iommu_domain.
archdata.iommu of master H/W contains ponter to the device descriptor
of System MMU and the list entry of iommu_domain.
Thus what attached to iommu_domain is now master H/W.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |  435 --
 1 files changed, 291 insertions(+), 144 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 686e3c8..8240f7f 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -154,6 +156,14 @@ static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
"UNKNOWN FAULT"
 };
 
+struct exynos_iommu_client {
+   struct list_head node;  /* entry of exynos_iommu_domain.clients */
+   struct device *dev;
+   spinlock_t lock;
+   int num_sysmmu;
+   struct device *sysmmu[0];
+};
+
 struct exynos_iommu_domain {
struct list_head clients; /* list of sysmmu_drvdata.node */
unsigned long *pgtable; /* lv1 page table, 16KB */
@@ -163,9 +173,8 @@ struct exynos_iommu_domain {
 };
 
 struct sysmmu_drvdata {
-   struct list_head node; /* entry of exynos_iommu_domain.clients */
struct device *sysmmu;  /* System MMU's device descriptor */
-   struct device *dev; /* Owner of system MMU */
+   struct device *master;  /* Owner of system MMU */
int nsfrs;
struct clk *clk;
struct clk *clk_master;
@@ -246,7 +255,6 @@ static void __sysmmu_tlb_invalidate_entry(void __iomem 
*sfrbase,
 static void __sysmmu_set_ptbase(void __iomem *sfrbase,
   unsigned long pgd)
 {
-   __raw_writel(0x1, sfrbase + REG_MMU_CFG); /* 16KB LV1, LRU */
__raw_writel(pgd, sfrbase + REG_PT_BASE_ADDR);
 
__sysmmu_tlb_invalidate(sfrbase);
@@ -336,12 +344,13 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
*dev_id)
 {
/* SYSMMU is in blocked when interrupt occurred. */
struct sysmmu_drvdata *data = dev_id;
+   struct exynos_iommu_client *client = NULL;
enum exynos_sysmmu_inttype itype;
unsigned long addr = -1;
-
int i, ret = -ENOSYS;
 
-   read_lock(&data->lock);
+   if (data->master)
+   client = data->master->archdata.iommu;
 
WARN_ON(!is_sysmmu_active(data));
 
@@ -354,6 +363,9 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
}
 
clk_enable(data->clk_master);
+   if (client)
+   spin_lock(&client->lock);
+   read_lock(&data->lock);
 
if (i == data->nsfrs) {
itype = SYSMMU_FAULT_UNKNOWN;
@@ -368,7 +380,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
}
 
if (data->domain)
-   ret = report_iommu_fault(data->domain, data->dev,
+   ret = report_iommu_fault(data->domain, data->master,
addr, itype);
 
if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
@@ -387,179 +399,246 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
*dev_id)
clk_disable(data->clk_master);
 
read_unlock(&data->lock);
+   if (client)
+   spin_unlock(&client->lock);
 
return IRQ_HANDLED;
 }
 
-static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
+static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
 {
-   unsigned long flags;
-   bool disabled = false;
int i;
 
-   write_lock_irqsave(&data->lock, flags);
+   clk_enable(data->clk_master);
+   for (i = 0; i < data->nsfrs; i++) {
+   __raw_writel(CTRL_DISABLE,
+   data->sfrbases[i] + REG_MMU_CTRL);
+   __raw_writel(0, data->sfrbases[i] + REG_MMU_CFG);
+   }
 
-   if (!set_sysmmu_inactive(data))
-   goto finish;
+   clk_disable(data->clk);
+   clk_disable(data->clk_master);
+}
 
-   clk_enable(data->clk_master);
+static bool __sysmmu_disable(struct sysmmu_drvdata *data)
+{
+   bool disabled;
+   unsigned long flags;
 
-   for (i = 0; i < data->nsfrs; i++)
-   __raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
+   write_lock_irqsave(&data->lock, flags);
 
-   clk_disable(data->clk_master);
+   disabled = set_sysmmu_inactive(data);
 
-   clk_disable(data->clk);
+   if (disabled) {
+   data->pgtable = 0;
+   data->domain = NULL;
 
-   di

[PATCH v9 03/16] iommu/exynos: fix page table maintenance

[Cho KyongHo]

This prevents allocating lv2 page table for the lv1 page table entry
that already has 1MB page mapping. In addition, changed to BUG_ON
instead of returning -EADDRINUSE.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   68 -
 1 files changed, 40 insertions(+), 28 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index d545a25..d90e6fa 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -52,11 +52,11 @@
 #define lv2ent_large(pent) ((*(pent) & 3) == 1)
 
 #define section_phys(sent) (*(sent) & SECT_MASK)
-#define section_offs(iova) ((iova) & 0xF)
+#define section_offs(iova) ((iova) & ~SECT_MASK)
 #define lpage_phys(pent) (*(pent) & LPAGE_MASK)
-#define lpage_offs(iova) ((iova) & 0x)
+#define lpage_offs(iova) ((iova) & ~LPAGE_MASK)
 #define spage_phys(pent) (*(pent) & SPAGE_MASK)
-#define spage_offs(iova) ((iova) & 0xFFF)
+#define spage_offs(iova) ((iova) & ~SPAGE_MASK)
 
 #define lv1ent_offset(iova) ((iova) >> SECT_ORDER)
 #define lv2ent_offset(iova) (((iova) & 0xFF000) >> SPAGE_ORDER)
@@ -856,13 +856,15 @@ finish:
 static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
short *pgcounter)
 {
+   BUG_ON(lv1ent_section(sent));
+
if (lv1ent_fault(sent)) {
unsigned long *pent;
 
pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
if (!pent)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
*sent = mk_lv1ent_page(__pa(pent));
*pgcounter = NUM_LV2ENTRIES;
@@ -875,15 +877,11 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, 
unsigned long iova,
 
 static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short *pgcnt)
 {
-   if (lv1ent_section(sent))
-   return -EADDRINUSE;
+   BUG_ON(lv1ent_section(sent));
 
if (lv1ent_page(sent)) {
-   if (*pgcnt != NUM_LV2ENTRIES)
-   return -EADDRINUSE;
-
+   BUG_ON(*pgcnt != NUM_LV2ENTRIES);
kfree(page_entry(sent, 0));
-
*pgcnt = 0;
}
 
@@ -894,24 +892,24 @@ static int lv1set_section(unsigned long *sent, 
phys_addr_t paddr, short *pgcnt)
return 0;
 }
 
+static void clear_page_table(unsigned long *ent, int n)
+{
+   if (n > 0)
+   memset(ent, 0, sizeof(*ent) * n);
+}
+
 static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
short *pgcnt)
 {
if (size == SPAGE_SIZE) {
-   if (!lv2ent_fault(pent))
-   return -EADDRINUSE;
-
+   BUG_ON(!lv2ent_fault(pent));
*pent = mk_lv2ent_spage(paddr);
pgtable_flush(pent, pent + 1);
*pgcnt -= 1;
} else { /* size == LPAGE_SIZE */
int i;
for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
-   if (!lv2ent_fault(pent)) {
-   memset(pent, 0, sizeof(*pent) * i);
-   return -EADDRINUSE;
-   }
-
+   BUG_ON(!lv2ent_fault(pent));
*pent = mk_lv2ent_lpage(paddr);
}
pgtable_flush(pent - SPAGES_PER_LPAGE, pent);
@@ -944,17 +942,16 @@ static int exynos_iommu_map(struct iommu_domain *domain, 
unsigned long iova,
pent = alloc_lv2entry(entry, iova,
&priv->lv2entcnt[lv1ent_offset(iova)]);
 
-   if (!pent)
-   ret = -ENOMEM;
+   if (IS_ERR(pent))
+   ret = PTR_ERR(pent);
else
ret = lv2set_page(pent, paddr, size,
&priv->lv2entcnt[lv1ent_offset(iova)]);
}
 
-   if (ret) {
-   pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
-   __func__, iova, size);
-   }
+   if (ret)
+   pr_err("%s: Failed(%d) to map 0x%#x bytes @ %#lx\n",
+   __func__, ret, size, iova);
 
spin_unlock_irqrestore(&priv->pgtablelock, flags);
 
@@ -968,6 +965,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain 
*domain,
struct sysmmu_drvdata *data;
unsigned long flags;
unsigned long *ent;
+   size_t err_pgsize;
 
BUG_ON(priv->pgtable == NULL);
 
@@ -976,7 +974,10 @@ static size_t exynos_iommu_unmap(struct iommu_domain 
*domain,
ent = section_entry(priv->pgtable, iova);
 
if (lv1ent_section(ent)) {
-   BUG_ON(size < SECT_SIZE);
+   if (WARN_ON(size < SECT_SIZE)) {
+   err

[PATCH v9 14/16] iommu/exynos: add support for power management subsystems.

[Cho KyongHo]

This adds support for Advance Power Management and Runtime Power
Management.

Since System MMU is located in the same local power domain of its
master H/W, System MMU must be initialized before it is working if
its power domain was ever turned off. TLB invalidation according to
unmapping on page tables must also be performed while power domain is
turned on.

This patch ensures that resume and runtime_resume(restore_state)
functions in this driver is called before the calls to resume and
runtime_resume callback functions in the drivers of master H/Ws.
Likewise, suspend and runtime_suspend(save_state) functions in this
driver is called after the calls to suspend and runtime_suspend in the
drivers of master H/Ws.

In order to get benefit of this support, the master H/W and its System
MMU must resides in the same power domain in terms of Linux kernel. If
a master H/W does not use generic I/O power domain, its driver must
call iommu_attach_device() after its local power domain is turned on,
iommu_detach_device before turned off.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |  235 +-
 1 files changed, 231 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 9e64483..56aead9 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -186,6 +187,7 @@ struct sysmmu_drvdata {
int activations;
rwlock_t lock;
struct iommu_domain *domain;
+   bool runtime_active;
unsigned long pgtable;
void __iomem *sfrbases[0];
 };
@@ -438,7 +440,8 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
data->pgtable = 0;
data->domain = NULL;
 
-   __sysmmu_disable_nocount(data);
+   if (data->runtime_active)
+   __sysmmu_disable_nocount(data);
 
dev_dbg(data->sysmmu, "Disabled\n");
} else  {
@@ -505,7 +508,8 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
data->pgtable = pgtable;
data->domain = domain;
 
-   __sysmmu_enable_nocount(data);
+   if (data->runtime_active)
+   __sysmmu_enable_nocount(data);
 
dev_dbg(data->sysmmu, "Enabled\n");
} else {
@@ -609,7 +613,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, 
unsigned long iova)
data = dev_get_drvdata(client->sysmmu[i]);
 
read_lock_irqsave(&data->lock, flags);
-   if (is_sysmmu_active(data)) {
+   if (is_sysmmu_active(data) && data->runtime_active) {
int i;
clk_enable(data->clk_master);
for (i = 0; i < data->nsfrs; i++)
@@ -637,7 +641,8 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
data = dev_get_drvdata(client->sysmmu[i]);
 
read_lock_irqsave(&data->lock, flags);
-   if (is_sysmmu_active(data)) {
+   if (is_sysmmu_active(data) &&
+   data->runtime_active) {
int i;
for (i = 0; i < data->nsfrs; i++) {
clk_enable(data->clk_master);
@@ -711,6 +716,8 @@ static int __init exynos_sysmmu_probe(struct 
platform_device *pdev)
}
}
 
+   pm_runtime_enable(dev);
+
data->sysmmu = dev;
 
data->clk = devm_clk_get(dev, "sysmmu");
@@ -736,6 +743,8 @@ static int __init exynos_sysmmu_probe(struct 
platform_device *pdev)
return ret;
}
 
+   data->runtime_active = !pm_runtime_enabled(dev);
+
rwlock_init(&data->lock);
 
platform_set_drvdata(pdev, data);
@@ -744,6 +753,34 @@ static int __init exynos_sysmmu_probe(struct 
platform_device *pdev)
return ret;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int sysmmu_suspend(struct device *dev)
+{
+   struct sysmmu_drvdata *data = dev_get_drvdata(dev);
+   unsigned long flags;
+   read_lock_irqsave(&data->lock, flags);
+   if (is_sysmmu_active(data) &&
+   (!pm_runtime_enabled(dev) || data->runtime_active))
+   __sysmmu_disable_nocount(data);
+   read_unlock_irqrestore(&data->lock, flags);
+   return 0;
+}
+
+static int sysmmu_resume(struct device *dev)
+{
+   struct sysmmu_drvdata *data = dev_get_drvdata(dev);
+   unsigned long flags;
+   read_lock_irqsave(&data->lock, flags);
+   if (is_sysmmu_active(data) &&
+   (!pm_runtime_enabled(dev) || data->runtime_active))
+   __sysmmu_enable_nocount(data);
+   read_unlock_irqrestore(&data->lock, flags);
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(sysmmu_pm_ops, sysmmu_suspend, sysmmu_resume);
+
 #ifdef CONFIG_OF
 static struct of_device_id s

[PATCH v9 00/16] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

[Cho KyongHo]

The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is disabled
before MFC block is power-down not to invalidate IOTLB in the System MMU
when I/O memory mapping is changed. Because a System MMU resides in the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.

This set of changes solves the above problem with setting each System MMUs
as the parent of the device which owns the System MMU to receive the
information when the device is turned off or turned on.

Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt

In addition, this patchset also includes several bug fixes and enhancements
of the current driver.

Change log:
v9:
- Rebased on the following branches
  git.linaro.org/git-ro/people/mturquette/linux.git/clk-next
  git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/samsung-next
  git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master (3.11-rc4)
- Split "add bus notifier for registering System MMU" into 5 patches
- Call clk_prepare() that was missing in v8.
- Fixed base address of sysmmu_tv in exynos4210.dtsi
- BUG_ON() instead of return -EADDRINUSE when trying mapping on an mapped area
- Moved camif_top to 317 in drivers/clk/samsung/clk-exynos5250.c
- Removed 'iommu' property from 'codec'(mfc) node
- Does not make 'master' clock to be the parent of 'sysmmu' clock.
   'master' clock is enabled before accessing control registers of System MMU
   and disabled after the access.

v8:
- Reordered patch list: moved "change rwloc to spinlock" to the last.
- Fixed remained bug in "fix page table maintenance".
- Always return 0 from exynos_iommu_attach_device().
- Removed prefetch buffer setting when System MMU is enabled
  due to the restriction of prefetch buffers:
  A prefetch buffer must not hit from more than one DMA.
  For instance with GScalers, if a single prefetch buffer is initialized
  with 0x0 ~ 0x and a GScaler works on source buffer at 0x1000
  and target buffer @ 0x2000, the System MMU may be got deadlock.
  Clients must initialize prefetch buffers with custom function defined
  in exynos-iommu drivers whenever they need to enable prefetch buffers.
- The clock of System MMU has no relationship with the clock of its master H/W.
  The clock of master H/W is always enabled when exynos-iommu driver needs to
  access MMIO area and disabled as soon as the access finishes.
- Removed err_page variable used in exynos_iommu_unmap() in the previous patch
  "fix page table maintenance".
- Split a big patch "add bus notifier for registering System MMU".
   Extracted the following 2 patches: 9/12 and 10/12.
- And some additional fixes...

v7:
- Rebased on the stable 3.10
- Registered PM domains and gate clocks with DT
- Changed connection method between a System MMU and its master H/W
   'mmu-master' property in the node of System MMU
   --> 'iommu' property in the node of master H/W
- Marking device descriptor of master H/W of a System MMU with bus notifier.
- Power management (PM_RUNTIME, PM_SLEEP) of System MMUs with gpd_dev_ops
   of Generic IO Powerdomain. gpd_dev_ops are set to the master H/Ws
   before they are probed in the bus notifier.
- Removed additional debugging features like debugfs entries and
   version names.
- Removed support for advanced features of System MMU 3.2 and 3.3
   the current IOMMU API cannot handle the feature
  (A kind of L2 TLB that fetches several consequence page table entries.
   It must be initialized by the driver of master H/W whenever it works.)

v6:
- Rebased on the branch, next/iommu-exynos of
  git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git

v5:
- new bugfix: patch 01
- Reordered patches
  * patch 01 ~ 05: Bugfix and enhancements of the existing driver
  * patch 06 ~ 10: Device Tree support and callbacks for power management
  * patch 11 : System MMU 3.2 and 3.3 support
  * patch 12 ~ 14: Debugging features
- Additional code compaction

v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
  Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to client
  device if the client device has multiple System MMUs.
  Thanks to Rahul Sharma.

v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
  Thanks to Prathyush.

v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction

Patch summary:

Diffstats:
 .../devicetree/bindings/clock/exynos5250-clock.txt |   26 +
 .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 ++
 arch/arm/boot/dts/exynos4.dtsi |  122 +++
 arch/

[PATCH v9 16/16] iommu/exynos: return 0 if iommu_attach_device() successes

[Cho KyongHo]

iommu_attach_device() against exynos-iommu positive integer on success
if the caller calls iommu_attach_device() with the same iommu_domain
multiple times without call to iommu_detach_device() to inform the
caller how many calls to iommu_detach_device() to really detach iommu.

However the convention of the return value of success of common API is
zero, this patch makes iommu_attach_device() call against exynos-iommu
always return zero if the given device is successfully attached to
the given iommu_domain even though it is already attached to the same
iommu_domain.

Reviewed-by: Grant Grundler 
Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 2d16fc0..d959e95 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -891,15 +891,16 @@ static int exynos_iommu_attach_device(struct iommu_domain 
*domain,
 
spin_unlock_irqrestore(&priv->lock, flags);
 
-   if (ret < 0)
+   if (ret < 0) {
dev_err(dev, "%s: Failed to attach IOMMU with pgtable %#lx\n",
__func__, __pa(priv->pgtable));
-   else
-   dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
-   __func__, __pa(priv->pgtable),
-   (ret == 0) ? "" : ", again");
+   return ret;
+   }
 
-   return ret;
+   dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
+   __func__, __pa(priv->pgtable), (ret == 0) ? "" : ", again");
+
+   return 0;
 }
 
 static void exynos_iommu_detach_device(struct iommu_domain *domain,
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 10/16] iommu/exynos: remove custom fault handler

[Cho KyongHo]

This commit removes custom fault handler. The device drivers that
need to register fault handler can register
with iommu_set_fault_handler().

Reviewed-by: Grant Grundler 
Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   71 ++
 1 files changed, 17 insertions(+), 54 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 88b9139..e8f3e82 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -131,16 +131,6 @@ enum exynos_sysmmu_inttype {
SYSMMU_FAULTS_NUM
 };
 
-/*
- * @itype: type of fault.
- * @pgtable_base: the physical address of page table base. This is 0 if @itype
- *is SYSMMU_BUSERROR.
- * @fault_addr: the device (virtual) address that the System MMU tried to
- * translated. This is 0 if @itype is SYSMMU_BUSERROR.
- */
-typedef int (*sysmmu_fault_handler_t)(enum exynos_sysmmu_inttype itype,
-   unsigned long pgtable_base, unsigned long fault_addr);
-
 static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
REG_PAGE_FAULT_ADDR,
REG_AR_FAULT_ADDR,
@@ -182,7 +172,6 @@ struct sysmmu_drvdata {
int activations;
rwlock_t lock;
struct iommu_domain *domain;
-   sysmmu_fault_handler_t fault_handler;
unsigned long pgtable;
void __iomem *sfrbases[0];
 };
@@ -318,34 +307,17 @@ finish:
read_unlock_irqrestore(&data->lock, flags);
 }
 
-static void __set_fault_handler(struct sysmmu_drvdata *data,
-   sysmmu_fault_handler_t handler)
-{
-   unsigned long flags;
-
-   write_lock_irqsave(&data->lock, flags);
-   data->fault_handler = handler;
-   write_unlock_irqrestore(&data->lock, flags);
-}
-
-void exynos_sysmmu_set_fault_handler(struct device *dev,
-   sysmmu_fault_handler_t handler)
-{
-   struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
-
-   __set_fault_handler(data, handler);
-}
-
-static int default_fault_handler(enum exynos_sysmmu_inttype itype,
-unsigned long pgtable_base, unsigned long fault_addr)
+static void show_fault_information(const char *name,
+   enum exynos_sysmmu_inttype itype,
+   unsigned long pgtable_base, unsigned long fault_addr)
 {
unsigned long *ent;
 
if ((itype >= SYSMMU_FAULTS_NUM) || (itype < SYSMMU_PAGEFAULT))
itype = SYSMMU_FAULT_UNKNOWN;
 
-   pr_err("%s occurred at 0x%lx(Page table base: 0x%lx)\n",
-   sysmmu_fault_name[itype], fault_addr, pgtable_base);
+   pr_err("%s occurred at 0x%lx by %s(Page table base: 0x%lx)\n",
+   sysmmu_fault_name[itype], fault_addr, name, pgtable_base);
 
ent = section_entry(__va(pgtable_base), fault_addr);
pr_err("\tLv1 entry: 0x%lx\n", *ent);
@@ -358,16 +330,12 @@ static int default_fault_handler(enum 
exynos_sysmmu_inttype itype,
pr_err("Generating Kernel OOPS... because it is unrecoverable.\n");
 
BUG();
-
-   return 0;
 }
 
 static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 {
/* SYSMMU is in blocked when interrupt occurred. */
struct sysmmu_drvdata *data = dev_id;
-   struct resource *irqres;
-   struct platform_device *pdev;
enum exynos_sysmmu_inttype itype;
unsigned long addr = -1;
 
@@ -377,16 +345,17 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
*dev_id)
 
WARN_ON(!is_sysmmu_active(data));
 
-   pdev = to_platform_device(data->sysmmu);
-   for (i = 0; i < (pdev->num_resources / 2); i++) {
-   irqres = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+   for (i = 0; i < data->nsfrs; i++) {
+   struct resource *irqres;
+   irqres = platform_get_resource(to_platform_device(data->sysmmu),
+   IORESOURCE_IRQ, i);
if (irqres && ((int)irqres->start == irq))
break;
}
 
clk_enable(data->clk_master);
 
-   if (i == pdev->num_resources) {
+   if (i == data->nsfrs) {
itype = SYSMMU_FAULT_UNKNOWN;
} else {
itype = (enum exynos_sysmmu_inttype)
@@ -402,19 +371,15 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
*dev_id)
ret = report_iommu_fault(data->domain, data->dev,
addr, itype);
 
-   if ((ret == -ENOSYS) && data->fault_handler) {
-   unsigned long base = data->pgtable;
-   if (itype != SYSMMU_FAULT_UNKNOWN)
-   base = __raw_readl(
-   data->sfrbases[i] + REG_PT_BASE_ADDR);
-   ret = data->fault_handler(itype, base, addr);
-   }
-
if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
__raw_writel(1 << itype, data->sfrbases[i] +

[PATCH v9 15/16] iommu/exynos: change rwlock to spinlock

[Cho KyongHo]

Since acquiring read_lock is not more frequent than write_lock, it is
not beneficial to use rwlock, this commit changes rwlock to spinlock.

Reviewed-by: Grant Grundler 
Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   36 ++--
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 56aead9..2d16fc0 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -185,7 +185,7 @@ struct sysmmu_drvdata {
struct clk *clk;
struct clk *clk_master;
int activations;
-   rwlock_t lock;
+   spinlock_t lock;
struct iommu_domain *domain;
bool runtime_active;
unsigned long pgtable;
@@ -285,7 +285,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
BUG_ON((base0 + size0) <= base0);
BUG_ON((size1 > 0) && ((base1 + size1) <= base1));
 
-   read_lock_irqsave(&data->lock, flags);
+   spin_lock_irqsave(&data->lock, flags);
if (!is_sysmmu_active(data))
goto finish;
 
@@ -319,7 +319,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
 
clk_disable(data->clk_master);
 finish:
-   read_unlock_irqrestore(&data->lock, flags);
+   spin_unlock_irqrestore(&data->lock, flags);
 }
 
 static void show_fault_information(const char *name,
@@ -372,7 +372,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
clk_enable(data->clk_master);
if (client)
spin_lock(&client->lock);
-   read_lock(&data->lock);
+   spin_lock(&data->lock);
 
if (i == data->nsfrs) {
itype = SYSMMU_FAULT_UNKNOWN;
@@ -405,7 +405,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
clk_disable(data->clk_master);
 
-   read_unlock(&data->lock);
+   spin_unlock(&data->lock);
if (client)
spin_unlock(&client->lock);
 
@@ -432,7 +432,7 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
bool disabled;
unsigned long flags;
 
-   write_lock_irqsave(&data->lock, flags);
+   spin_lock_irqsave(&data->lock, flags);
 
disabled = set_sysmmu_inactive(data);
 
@@ -449,7 +449,7 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
data->activations);
}
 
-   write_unlock_irqrestore(&data->lock, flags);
+   spin_unlock_irqrestore(&data->lock, flags);
 
return disabled;
 }
@@ -503,7 +503,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
int ret = 0;
unsigned long flags;
 
-   write_lock_irqsave(&data->lock, flags);
+   spin_lock_irqsave(&data->lock, flags);
if (set_sysmmu_active(data)) {
data->pgtable = pgtable;
data->domain = domain;
@@ -521,7 +521,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
if (WARN_ON(ret < 0))
set_sysmmu_inactive(data); /* decrement count */
 
-   write_unlock_irqrestore(&data->lock, flags);
+   spin_unlock_irqrestore(&data->lock, flags);
 
return ret;
 }
@@ -612,7 +612,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, 
unsigned long iova)
 
data = dev_get_drvdata(client->sysmmu[i]);
 
-   read_lock_irqsave(&data->lock, flags);
+   spin_lock_irqsave(&data->lock, flags);
if (is_sysmmu_active(data) && data->runtime_active) {
int i;
clk_enable(data->clk_master);
@@ -625,7 +625,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, 
unsigned long iova)
"disabled. Skipping TLB invalidation @ %#lx\n",
iova);
}
-   read_unlock_irqrestore(&data->lock, flags);
+   spin_unlock_irqrestore(&data->lock, flags);
}
 }
 
@@ -640,7 +640,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
 
data = dev_get_drvdata(client->sysmmu[i]);
 
-   read_lock_irqsave(&data->lock, flags);
+   spin_lock_irqsave(&data->lock, flags);
if (is_sysmmu_active(data) &&
data->runtime_active) {
int i;
@@ -656,7 +656,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
} else {
dev_dbg(dev, "disabled. Skipping TLB invalidation\n");
}
-   read_unlock_irqrestore(&data->lock, flags);
+   spin_unlock_irqrestore(&data->lock, flags);
}
 }
 
@@ -745,7 +745,7 @@ static int __init exynos_sysmmu_probe(struct 
platform_device *pdev)
 
data->runtime_active = !pm_runtime_enabled(dev);
 
-   rwlock_init(&data->lock);
+   spin_lock_init(&data->lock);
 
platform_set_drvdata(pdev, data);
dev_dbg(dev, "Probed and initial

[PATCH v9 13/16] iommu/exynos: turn on useful configuration options

[Cho KyongHo]

This turns on ACGEN and SYSSEL.

ACGEN is architectural clock gating that gates clocks by System MMU
itself if it is not active. Note that ACGEN is different from clock
gating by the CPU. ACGEN just gates clocks to the internal logic of
System MMU while clock gating by the CPU gates clocks to the System
MMU.

SYSSEL selects System MMU version in some Exynos SoCs. Some Exynos
SoCs have an option to select System MMU versions exclusively because
the SoCs adopts new System MMU version experimentally.

This also always selects LRU as TLB replacement policy. Selecting TLB
replacement policy is deprecated from System MMU 3.2. TLB in System
MMU 3.3 has single TLB replacement policy, LRU. The bit of MMU_CFG
selecting TLB replacement policy is remained as reserved.

QoS value of page table walking is set to 15 (highst value). System
MMU 3.3 can inherit QoS value of page table walking from its master
H/W's transaction. This new feature is enabled by default and QoS
value written to MMU_CFG is ignored.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 8240f7f..9e64483 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -82,6 +82,11 @@
 #define CTRL_BLOCK 0x7
 #define CTRL_DISABLE   0x0
 
+#define CFG_LRU0x1
+#define CFG_QOS(n) ((n & 0xF) << 7)
+#define CFG_MASK   0x0150 /* Selecting bit 0-15, 20, 22 and 24 */
+#define CFG_ACGEN  (1 << 24) /* System MMU 3.3 only */
+#define CFG_SYSSEL (1 << 22) /* System MMU 3.2 only */
 #define CFG_FLPDCACHE  (1 << 20) /* System MMU 3.2+ only */
 
 #define REG_MMU_CTRL   0x000
@@ -449,12 +454,21 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
 
 static void __sysmmu_init_config(struct sysmmu_drvdata *data, int idx)
 {
-   unsigned long cfg = 0;
+   unsigned long cfg = CFG_LRU | CFG_QOS(15);
int maj, min = 0;
 
maj = __sysmmu_version(data, idx, &min);
-   if ((maj == 3) && (min > 1))
-   cfg |= CFG_FLPDCACHE;
+   if (maj == 3) {
+   if (min >= 2) {
+   cfg |= CFG_FLPDCACHE;
+   if (min == 3) {
+   cfg |= CFG_ACGEN;
+   cfg &= ~CFG_LRU;
+   } else {
+   cfg |= CFG_SYSSEL;
+   }
+   }
+   }
 
__raw_writel(cfg, data->sfrbases[idx] + REG_MMU_CFG);
 }
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 11/16] iommu/exynos: remove calls to Runtime PM API functions

[Cho KyongHo]

Runtime power management by exynos-iommu driver independently from
master H/W's runtime pm is not useful for power saving since attaching
master H/W in probing time turns on its local power endlessly.
Thus this removes runtime pm API calls.
Runtime PM support is added in the following commits to exynos-iommu
driver.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   20 
 1 files changed, 0 insertions(+), 20 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index e8f3e82..686e3c8 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -491,15 +491,8 @@ int exynos_sysmmu_enable(struct device *dev, unsigned long 
pgtable)
 
BUG_ON(!memblock_is_memory(pgtable));
 
-   ret = pm_runtime_get_sync(data->sysmmu);
-   if (ret < 0) {
-   dev_dbg(data->sysmmu, "Failed to enable\n");
-   return ret;
-   }
-
ret = __exynos_sysmmu_enable(data, pgtable, NULL);
if (WARN_ON(ret < 0)) {
-   pm_runtime_put(data->sysmmu);
dev_err(data->sysmmu,
"Already enabled with page table %#lx\n",
data->pgtable);
@@ -516,7 +509,6 @@ static bool exynos_sysmmu_disable(struct device *dev)
bool disabled;
 
disabled = __exynos_sysmmu_disable(data);
-   pm_runtime_put(data->sysmmu);
 
return disabled;
 }
@@ -626,8 +618,6 @@ static int __init exynos_sysmmu_probe(struct 
platform_device *pdev)
}
}
 
-   pm_runtime_enable(dev);
-
data->sysmmu = dev;
data->clk = devm_clk_get(dev, "sysmmu");
if (IS_ERR(data->clk)) {
@@ -759,12 +749,6 @@ static int exynos_iommu_attach_device(struct iommu_domain 
*domain,
unsigned long flags;
int ret;
 
-   ret = pm_runtime_get_sync(data->sysmmu);
-   if (ret < 0)
-   return ret;
-
-   ret = 0;
-
spin_lock_irqsave(&priv->lock, flags);
 
ret = __exynos_sysmmu_enable(data, __pa(priv->pgtable), domain);
@@ -781,7 +765,6 @@ static int exynos_iommu_attach_device(struct iommu_domain 
*domain,
if (ret < 0) {
dev_err(dev, "%s: Failed to attach IOMMU with pgtable %#lx\n",
__func__, __pa(priv->pgtable));
-   pm_runtime_put(data->sysmmu);
} else if (ret > 0) {
dev_dbg(dev, "%s: IOMMU with pgtable 0x%lx already attached\n",
__func__, __pa(priv->pgtable));
@@ -826,9 +809,6 @@ static void exynos_iommu_detach_device(struct iommu_domain 
*domain,
 
 finish:
spin_unlock_irqrestore(&priv->lock, flags);
-
-   if (found)
-   pm_runtime_put(data->sysmmu);
 }
 
 static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 08/16] iommu/exynos: gating clocks of master H/W

[Cho KyongHo]

This patch gates clocks of master H/W as well as clocks of System MMU
if master clocks are specified.

Some Exynos SoCs (i.e. GScalers in Exynos5250) have dependencies in
the gating clocks of master H/W and its System MMU. If a H/W is the
case, accessing control registers of System MMU is prohibited unless
both of the gating clocks of System MMU and its master H/W.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   38 ++
 1 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 0ee73e8..005a7ed 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -173,6 +173,7 @@ struct sysmmu_drvdata {
struct device *dev; /* Owner of system MMU */
int nsfrs;
struct clk *clk;
+   struct clk *clk_master;
int activations;
rwlock_t lock;
struct iommu_domain *domain;
@@ -263,6 +264,8 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
if (!is_sysmmu_active(data))
goto finish;
 
+   clk_enable(data->clk_master);
+
for (i = 0; i < data->nsfrs; i++) {
if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
if (!sysmmu_block(data->sfrbases[i]))
@@ -288,6 +291,8 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
sysmmu_unblock(data->sfrbases[i]);
}
}
+
+   clk_disable(data->clk_master);
 finish:
read_unlock_irqrestore(&data->lock, flags);
 }
@@ -358,6 +363,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
break;
}
 
+   clk_enable(data->clk_master);
+
if (i == pdev->num_resources) {
itype = SYSMMU_FAULT_UNKNOWN;
} else {
@@ -391,6 +398,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
if (itype != SYSMMU_FAULT_UNKNOWN)
sysmmu_unblock(data->sfrbases[i]);
 
+   clk_disable(data->clk_master);
+
read_unlock(&data->lock);
 
return IRQ_HANDLED;
@@ -407,11 +416,14 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata 
*data)
if (!set_sysmmu_inactive(data))
goto finish;
 
+   clk_enable(data->clk_master);
+
for (i = 0; i < data->nsfrs; i++)
__raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
 
-   if (data->clk)
-   clk_disable(data->clk);
+   clk_disable(data->clk_master);
+
+   clk_disable(data->clk);
 
disabled = true;
data->pgtable = 0;
@@ -454,11 +466,12 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata 
*data,
goto finish;
}
 
-   if (data->clk)
-   clk_enable(data->clk);
+   clk_enable(data->clk);
 
data->pgtable = pgtable;
 
+   clk_enable(data->clk_master);
+
for (i = 0; i < data->nsfrs; i++) {
__sysmmu_set_ptbase(data->sfrbases[i], pgtable);
 
@@ -473,6 +486,8 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata 
*data,
__raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
}
 
+   clk_disable(data->clk_master);
+
data->domain = domain;
 
dev_dbg(data->sysmmu, "Enabled\n");
@@ -528,6 +543,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, 
unsigned long iova)
 
if (is_sysmmu_active(data)) {
int i;
+   clk_enable(data->clk_master);
for (i = 0; i < data->nsfrs; i++) {
if (sysmmu_block(data->sfrbases[i])) {
__sysmmu_tlb_invalidate_entry(
@@ -535,6 +551,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, 
unsigned long iova)
sysmmu_unblock(data->sfrbases[i]);
}
}
+   clk_disable(data->clk_master);
} else {
dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
}
@@ -551,12 +568,14 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
 
if (is_sysmmu_active(data)) {
int i;
+   clk_enable(data->clk_master);
for (i = 0; i < data->nsfrs; i++) {
if (sysmmu_block(data->sfrbases[i])) {
__sysmmu_tlb_invalidate(data->sfrbases[i]);
sysmmu_unblock(data->sfrbases[i]);
}
}
+   clk_disable(data->clk_master);
} else {
dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
}
@@ -637,6 +656,17 @@ static int __init exynos_sysmmu_probe(struct 
platform_device *pdev)
return ret;
}
 
+   data->clk_master = devm_clk_get(dev, "master");
+   if (IS_ERR(data->clk_master))
+   data->clk_mas

[PATCH v9 07/16] iommu/exynos: support for device tree

[Cho KyongHo]

This commit adds device tree support for System MMU.
This also include the following changes and enhancements:

* use managed device helper functions.
Simplyfies System MMU device driver.

* use only a single clock descriptor.
System MMU device descriptor is seperate if it is imposible to make
a single clock descriptor to make a device descriptor for a group of
System MMUs.

* removed dbgname member from sysmmu_drvdata structure.
debugging kernel message for a System MMU is distinguisheable with the
name of device descroptors.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/Kconfig|5 +-
 drivers/iommu/exynos-iommu.c |  186 -
 2 files changed, 75 insertions(+), 116 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 820d85c..9ad45f1 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -168,16 +168,15 @@ config TEGRA_IOMMU_SMMU
 
 config EXYNOS_IOMMU
bool "Exynos IOMMU Support"
-   depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU
+   depends on ARCH_EXYNOS
select IOMMU_API
+   default n
help
  Support for the IOMMU(System MMU) of Samsung Exynos application
  processor family. This enables H/W multimedia accellerators to see
  non-linear physical memory chunks as a linear memory in their
  address spaces
 
- If unsure, say N here.
-
 config EXYNOS_IOMMU_DEBUG
bool "Debugging log for Exynos IOMMU"
depends on EXYNOS_IOMMU
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index a318049..0ee73e8 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -170,15 +171,14 @@ struct sysmmu_drvdata {
struct list_head node; /* entry of exynos_iommu_domain.clients */
struct device *sysmmu;  /* System MMU's device descriptor */
struct device *dev; /* Owner of system MMU */
-   char *dbgname;
int nsfrs;
-   void __iomem **sfrbases;
-   struct clk *clk[2];
+   struct clk *clk;
int activations;
rwlock_t lock;
struct iommu_domain *domain;
sysmmu_fault_handler_t fault_handler;
unsigned long pgtable;
+   void __iomem *sfrbases[0];
 };
 
 static bool set_sysmmu_active(struct sysmmu_drvdata *data)
@@ -385,8 +385,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
__raw_writel(1 << itype, data->sfrbases[i] + REG_INT_CLEAR);
else
-   dev_dbg(data->sysmmu, "(%s) %s is not handled.\n",
-   data->dbgname, sysmmu_fault_name[itype]);
+   dev_dbg(data->sysmmu, "%s is not handled.\n",
+   sysmmu_fault_name[itype]);
 
if (itype != SYSMMU_FAULT_UNKNOWN)
sysmmu_unblock(data->sfrbases[i]);
@@ -410,10 +410,8 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata 
*data)
for (i = 0; i < data->nsfrs; i++)
__raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
 
-   if (data->clk[1])
-   clk_disable(data->clk[1]);
-   if (data->clk[0])
-   clk_disable(data->clk[0]);
+   if (data->clk)
+   clk_disable(data->clk);
 
disabled = true;
data->pgtable = 0;
@@ -422,10 +420,10 @@ finish:
write_unlock_irqrestore(&data->lock, flags);
 
if (disabled)
-   dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
+   dev_dbg(data->sysmmu, "Disabled\n");
else
-   dev_dbg(data->sysmmu, "(%s) %d times left to be disabled\n",
-   data->dbgname, data->activations);
+   dev_dbg(data->sysmmu, "%d times left to be disabled\n",
+   data->activations);
 
return disabled;
 }
@@ -452,14 +450,12 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata 
*data,
ret = 1;
}
 
-   dev_dbg(data->sysmmu, "(%s) Already enabled\n", data->dbgname);
+   dev_dbg(data->sysmmu, "Already enabled\n");
goto finish;
}
 
-   if (data->clk[0])
-   clk_enable(data->clk[0]);
-   if (data->clk[1])
-   clk_enable(data->clk[1]);
+   if (data->clk)
+   clk_enable(data->clk);
 
data->pgtable = pgtable;
 
@@ -479,7 +475,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata 
*data,
 
data->domain = domain;
 
-   dev_dbg(data->sysmmu, "(%s) Enabled\n", data->dbgname);
+   dev_dbg(data->sysmmu, "Enabled\n");
 finish:
write_unlock_irqrestore(&data->lock, flags);
 
@@ -495,7 +491,7 @@ int exynos_sysmmu_enable(struct device *dev, unsigned long 
pgtable)
 
ret = pm_runtime_get_sync(data->sy

[PATCH v9 09/16] iommu/exynos: remove prefetch buffer setting when enabling System MMU

[Cho KyongHo]

Prefetch buffer must be handled accurately, exact range of a buffer,
frame by frame manually. Otherwise, it may causes page fault or
deadlock in System MMU.
Thus this patch removes prefetch buffer setting when System MMU is
initialized(enabled).

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   32 +++-
 1 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 005a7ed..88b9139 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -80,6 +80,8 @@
 #define CTRL_BLOCK 0x7
 #define CTRL_DISABLE   0x0
 
+#define CFG_FLPDCACHE  (1 << 20) /* System MMU 3.2+ only */
+
 #define REG_MMU_CTRL   0x000
 #define REG_MMU_CFG0x004
 #define REG_MMU_STATUS 0x008
@@ -96,6 +98,9 @@
 
 #define REG_MMU_VERSION0x034
 
+#define MMU_MAJ_VER(reg)   (reg >> 28)
+#define MMU_MIN_VER(reg)   ((reg >> 21) & 0x7F)
+
 #define REG_PB0_SADDR  0x04C
 #define REG_PB0_EADDR  0x050
 #define REG_PB1_SADDR  0x054
@@ -201,6 +206,22 @@ static bool is_sysmmu_active(struct sysmmu_drvdata *data)
return data->activations > 0;
 }
 
+static unsigned int __sysmmu_version(struct sysmmu_drvdata *data,
+int idx, unsigned int *minor)
+{
+   unsigned long major;
+
+   major = readl(data->sfrbases[idx] + REG_MMU_VERSION);
+
+   if (minor)
+   *minor = MMU_MIN_VER(major);
+
+   if (MMU_MAJ_VER(major) > 3)
+   return 1;
+
+   return MMU_MAJ_VER(major);
+}
+
 static void sysmmu_unblock(void __iomem *sfrbase)
 {
__raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
@@ -473,14 +494,15 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata 
*data,
clk_enable(data->clk_master);
 
for (i = 0; i < data->nsfrs; i++) {
+   unsigned int min;
+
__sysmmu_set_ptbase(data->sfrbases[i], pgtable);
 
-   if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
-   /* System MMU version is 3.x */
-   __raw_writel((1 << 12) | (2 << 28),
+   if ((__sysmmu_version(data, i, &min) == 3) && (min > 1)) {
+   unsigned long cfg;
+   cfg = __raw_readl(data->sfrbases[i] + REG_MMU_CFG);
+   __raw_writel(cfg | CFG_FLPDCACHE,
data->sfrbases[i] + REG_MMU_CFG);
-   __sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 0);
-   __sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 1);
}
 
__raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 06/16] ARM: dts: Add description of System MMU of Exynos SoCs

[Cho KyongHo]

Signed-off-by: Cho KyongHo 
---
 .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
 arch/arm/boot/dts/exynos4.dtsi |  122 
 arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
 arch/arm/boot/dts/exynos4x12.dtsi  |   82 ++
 arch/arm/boot/dts/exynos5250.dtsi  |  290 
 5 files changed, 622 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt

diff --git 
a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
new file mode 100644
index 000..92f0a33
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
@@ -0,0 +1,103 @@
+Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
+
+Samsung's Exynos architecture contains System MMU that enables scattered
+physical memory chunks visible as a contiguous region to DMA-capable peripheral
+devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
+
+System MMU is a sort of IOMMU and support identical translation table format to
+ARMv7 translation tables with minimum set of page properties including access
+permissions, shareability and security protection. In addition, System MMU has
+another capabilities like L2 TLB or block-fetch buffers to minimize translation
+latency.
+
+A System MMU is dedicated to a single master peripheral device.  Thus, it is
+important to specify the correct System MMU in the device node of its master
+device. Whereas a System MMU is dedicated to a master device, the master device
+may have more than one System MMU.
+
+Required properties:
+- compatible: Should be "samsung,exynos4210-sysmmu"
+- reg: A tuple of base address and size of System MMU registers.
+- interrupt-parent: The phandle of the interrupt controller of System MMU
+- interrupts: A tuple of numbers that indicates the interrupt source.
+- clock-names: Should be "sysmmu" if the System MMU is needed to gate its 
clock.
+   Please refer to the following documents:
+  Documentation/devicetree/bindings/clock/clock-bindings.txt
+  Documentation/devicetree/bindings/clock/exynos4-clock.txt
+  Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+  Optional "master" if the clock to the System MMU is gated by
+  another gate clock other than "sysmmu". The System MMU driver
+  sets "master" the parent of "sysmmu".
+  Exynos4 SoCs, there needs no "master" clocks.
+  Exynos5 SoCs, some System MMUs must have "master" clocks.
+- clocks: Required if the System MMU is needed to gate its clock.
+ Please refer to the documents listed above.
+- samsung,power-domain: Required if the System MMU is needed to gate its power.
+ Please refer to the following document:
+ Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+
+Required properties for the master peripheral devices:
+- iommu: phandles to the System MMUs of the device
+
+Examples:
+A System MMU is dedicated to a single master device.
+   gsc_0:  gsc@0x13e0 {
+   compatible = "samsung,exynos5-gsc";
+   reg = <0x13e0 0x1000>;
+   interrupts = <0 85 0>;
+   samsung,power-domain = <&pd_gsc>;
+   clocks = <&clock 256>;
+   clock-names = "gscl";
+   iommu = <&sysmmu_gsc1>;
+   };
+
+   sysmmu_gsc0: sysmmu@13E8 {
+   compatible = "samsung,exynos4210-sysmmu";
+   reg = <0x13E8 0x1000>;
+   interrupt-parent = <&combiner>;
+   interrupt-names = "sysmmu-gsc0";
+   interrupts = <2 0>;
+   clock-names = "sysmmu", "master";
+   clocks = <&clock 262>, <&clock 256>;
+   samsung,power-domain = <&pd_gsc>;
+   status = "ok";
+   };
+
+MFC has 2 System MMUs for each port that MFC is attached. Thus it seems natural
+to define 2 System MMUs for each port of the MFC:
+
+   mfc: codec@1340 {
+   compatible = "samsung,mfc-v5";
+   reg = <0x1340 0x1>;
+   interrupts = <0 94 0>;
+   samsung,power-domain = <&pd_mfc>;
+   clocks = <&clock 170>, <&clock 273>;
+   clock-names = "sclk_mfc", "mfc";
+   status = "ok";
+   iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
+   };
+
+   sysmmu_mfc_l: sysmmu@1362 {
+   compatible = "samsung,exynos4210-sysmmu";
+   reg = <0x1362 0x1000>;
+   interrupt-parent = <&combiner>;
+   interrupt-names = "sysmmu-mfc-l";
+   interrupts = <5 5>;
+   clock-names = "sysmmu";
+   clocks = <&clock 274>;
+   samsung,power-domain = <&pd_mfc>;
+

[PATCH v9 05/16] clk: exynos: add gate clock descriptions of System MMU

[Cho KyongHo]

This adds gate clocks of all System MMUs and their master IPs
that are not apeared in clk-exynos5250.c
Also fixes GATE_IP_ACP to 0x18800 and changed GATE_DA to GATE
for System MMU clocks in clk-exynos4.c

Signed-off-by: Cho KyongHo 
---
 .../devicetree/bindings/clock/exynos5250-clock.txt |   26 +
 drivers/clk/samsung/clk-exynos4.c  |   27 +++--
 drivers/clk/samsung/clk-exynos5250.c   |   57 
 3 files changed, 82 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 24765c1..9c76710 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -159,6 +159,32 @@ clock which they consume.
   mixer343
   hdmi 344
   g2d  345
+  smmu_fimc_lite0  346
+  smmu_fimc_lite1  347
+  smmu_fimc_lite2  348
+  smmu_tv  349
+  smmu_fimd1   350
+  smmu_2d  351
+  fimc_isp 352
+  fimc_drc 353
+  fimc_fd  354
+  fimc_scc 355
+  fimc_scp 356
+  fimc_mcuctl  357
+  fimc_odc 358
+  fimc_dis 359
+  fimc_3dnr360
+  smmu_fimc_isp361
+  smmu_fimc_drc362
+  smmu_fimc_fd 363
+  smmu_fimc_scc364
+  smmu_fimc_scp365
+  smmu_fimc_mcuctl 366
+  smmu_fimc_odc367
+  smmu_fimc_dis0   368
+  smmu_fimc_dis1   369
+  smmu_fimc_3dnr   370
+  camif_top371
 
 
[Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index 68f9a4a..92dcf03 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -705,29 +705,20 @@ static struct samsung_gate_clock exynos4_gate_clks[] 
__initdata = {
GATE_IP_CAM, 4, 0, 0, "fimc"),
GATE_DA(csis1, "s5p-mipi-csis.1", "csis1", "aclk160",
GATE_IP_CAM, 5, 0, 0, "fimc"),
-   GATE_DA(smmu_fimc0, "exynos-sysmmu.5", "smmu_fimc0", "aclk160",
-   GATE_IP_CAM, 7, 0, 0, "sysmmu"),
-   GATE_DA(smmu_fimc1, "exynos-sysmmu.6", "smmu_fimc1", "aclk160",
-   GATE_IP_CAM, 8, 0, 0, "sysmmu"),
-   GATE_DA(smmu_fimc2, "exynos-sysmmu.7", "smmu_fimc2", "aclk160",
-   GATE_IP_CAM, 9, 0, 0, "sysmmu"),
-   GATE_DA(smmu_fimc3, "exynos-sysmmu.8", "smmu_fimc3", "aclk160",
-   GATE_IP_CAM, 10, 0, 0, "sysmmu"),
-   GATE_DA(smmu_jpeg, "exynos-sysmmu.3", "smmu_jpeg", "aclk160",
-   GATE_IP_CAM, 11, 0, 0, "sysmmu"),
+   GATE(smmu_fimc0, "smmu_fimc0", "aclk160", GATE_IP_CAM, 7, 0, 0),
+   GATE(smmu_fimc1, "smmu_fimc1", "aclk160", GATE_IP_CAM, 8, 0, 0),
+   GATE(smmu_fimc2, "smmu_fimc2", "aclk160", GATE_IP_CAM, 9, 0, 0),
+   GATE(smmu_fimc3, "smmu_fimc3", "aclk160", GATE_IP_CAM, 10, 0, 0),
+   GATE(smmu_jpeg, "smmu_jpeg", "aclk160", GATE_IP_CAM, 11, 0, 0),
GATE(pixelasyncm0, "pxl_async0", "aclk160", GATE_IP_CAM, 17, 0, 0),
GATE(pixelasyncm1, "pxl_async1", "aclk160", GATE_IP_CAM, 18, 0, 0),
-   GATE_DA(smmu_tv, "exynos-sysmmu.2", "smmu_tv", "aclk160",
-   GATE_IP_TV, 4, 0, 0, "sysmmu"),
+   GATE(smmu_tv, "smmu_tv", "aclk160", GATE_IP_TV, 4, 0, 0),
GATE_DA(mfc, "s5p-mfc", "mfc", "aclk100", GATE_IP_MFC, 0, 0, 0, "mfc"),
-   GATE_DA(smmu_mfcl, "exynos-sysmmu.0", "smmu_mfcl", "aclk100",
-   GATE_IP_MFC, 1, 0, 0, "sysmmu"),
-   GATE_DA(smmu_mfcr, "exynos-sysmmu.1", "smmu_mfcr", "aclk100",
-   GATE_IP_MFC, 2, 0, 0, "sysmmu"),
+   GATE(smmu_mfcl, "smmu_mfcl", "aclk100", GATE_IP_MFC, 1, 0, 0),
+   GATE(smmu_mfcr, "smmu_mfcr", "aclk100", GATE_IP_MFC, 2, 0, 0),
GATE_DA(fimd0, "exynos4-fb.0", "fimd0", "aclk160",
GATE_IP_LCD0, 0, 0, 0, "fimd"),
-   GATE_DA(smmu_fimd0, "exynos-sysmmu.10", "smmu_fimd0", "aclk160",
-   GATE_IP_LCD0, 4, 0, 0, "sysmmu"),
+   GATE(smmu_fimd0, "smmu_fimd0", "aclk160", GATE_IP_LCD0, 4, 0, 0),
GATE_DA(pdma0, "dma-pl330.0", "pdma0", "aclk133",
GATE_IP_FSYS, 0, 0, 0, "dma"),
GATE_DA(pdma1, "dma-pl330.1", "pdma1", "aclk133",
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index df3628c..e945fcf 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -64,6 +64,8 @@
 #define DIV_PERIC3 0x10564
 #define DIV_PERIC4 0x10568
 #define DIV_PERIC5 0x1056c
+#define GATE_IP_ISP0   0x0C800
+#define GATE_IP_ISP1   0x0C800
 #define GATE_IP_GSCL   0x10920
 #define GATE_IP_MFC   

[PATCH v9 04/16] iommu/exynos: allocate lv2 page table from own slab

[Cho KyongHo]

Since kmalloc() does not guarantee that the allignment of 1KiB when it
allocates 1KiB, it is required to allocate lv2 page table from own
slab that guarantees alignment of 1KiB

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   24 
 1 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index d90e6fa..a318049 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -100,6 +100,8 @@
 #define REG_PB1_SADDR  0x054
 #define REG_PB1_EADDR  0x058
 
+static struct kmem_cache *lv2table_kmem_cache;
+
 static unsigned long *section_entry(unsigned long *pgtable, unsigned long iova)
 {
return pgtable + lv1ent_offset(iova);
@@ -765,7 +767,8 @@ static void exynos_iommu_domain_destroy(struct iommu_domain 
*domain)
 
for (i = 0; i < NUM_LV1ENTRIES; i++)
if (lv1ent_page(priv->pgtable + i))
-   kfree(__va(lv2table_base(priv->pgtable + i)));
+   kmem_cache_free(lv2table_kmem_cache,
+   __va(lv2table_base(priv->pgtable + i)));
 
free_pages((unsigned long)priv->pgtable, 2);
free_pages((unsigned long)priv->lv2entcnt, 1);
@@ -861,7 +864,7 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, 
unsigned long iova,
if (lv1ent_fault(sent)) {
unsigned long *pent;
 
-   pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
+   pent = kmem_cache_zalloc(lv2table_kmem_cache, GFP_ATOMIC);
BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
if (!pent)
return ERR_PTR(-ENOMEM);
@@ -881,7 +884,7 @@ static int lv1set_section(unsigned long *sent, phys_addr_t 
paddr, short *pgcnt)
 
if (lv1ent_page(sent)) {
BUG_ON(*pgcnt != NUM_LV2ENTRIES);
-   kfree(page_entry(sent, 0));
+   kmem_cache_free(lv2table_kmem_cache, page_entry(sent, 0));
*pgcnt = 0;
}
 
@@ -1082,10 +1085,23 @@ static int __init exynos_iommu_init(void)
 {
int ret;
 
+   lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
+   LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
+   if (!lv2table_kmem_cache) {
+   pr_err("%s: Failed to create kmem cache\n", __func__);
+   return -ENOMEM;
+   }
+
ret = platform_driver_register(&exynos_sysmmu_driver);
 
if (ret == 0)
-   bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
+   ret = bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
+
+   if (ret) {
+   pr_err("%s: Failed to register exynos-iommu driver.\n",
+   __func__);
+   kmem_cache_destroy(lv2table_kmem_cache);
+   }
 
return ret;
 }
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 01/16] iommu/exynos: do not include removed header

[Cho KyongHo]

This commit remove  which is removed.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 3f32d64..233f382 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -12,6 +12,7 @@
 #define DEBUG
 #endif
 
+#include 
 #include 
 #include 
 #include 
@@ -29,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 /* We does not consider super section mapping (16MB) */
 #define SECT_ORDER 20
 #define LPAGE_ORDER 16
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries

[Cho KyongHo]

This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.

Tested-by: Grant Grundler 
Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 233f382..d545a25 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain 
*domain,
if (lv2ent_small(ent)) {
*ent = 0;
size = SPAGE_SIZE;
+   pgtable_flush(ent, ent + 1);
priv->lv2entcnt[lv1ent_offset(iova)] += 1;
goto done;
}
@@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain 
*domain,
BUG_ON(size < LPAGE_SIZE);
 
memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
+   pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
 
size = LPAGE_SIZE;
priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling

[Mark Rutland]

On Wed, Aug 07, 2013 at 06:06:05PM +0100, Julius Werner wrote:
> > This breaks compatibility, both for an old kernel and a new dt and a new
> > kernel with an old dt. Is anyone using these bindings?
> 
> They only affect Samsung SoCs and have only been upstream for half a
> year, so I doubt it's heavily used.

I'm not sure everyone will be happy with that line.

> 
> > Why are we describing fewer registers now? Are they described elsewhere?
> >
> > The dt should describe the device, not only the portion of it Linux
> > wants to use right now.
> 
> This only ever described a small section of the huge set of PMU
> registers anyway. Before it described up to three registers
> controlling different PHYs (using hardcoded offsets in the code to
> later find the right one)... with my patch every PHY's DT entry only
> describes the one register concerning itself, which makes more sense
> in my opinion. It will also prevent the register descriptions in
> different DT entries from overlapping.
> 

I'm not sure I understand. The old documentation referred to the
USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
your new version only refers to (usb device) PHY_CONTROL. Regardless of
multiple phys, you're suggesting that we describe less of each phy.
That seems like taking away usable information. Unless I've
misunderstood?

Ideally, we'd describe the whole set of registers and linkages to phys,
even if Linux doesn't ahppen to use that information right now.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 2/3] ASoC: Samsung: I2S: Add quirks as driver data in I2S

[Tomasz Figa]

On Thursday 08 of August 2013 13:13:02 Padma Venkat wrote:
> Hi Tomasz,
> 
> On Wed, Aug 7, 2013 at 4:43 PM, Tomasz Figa  wrote:
> > Ahh, one more thing inline.
> 
> [snip]
> 
> >> +static struct samsung_i2s_dai_data i2sv3_dai_type = {
> >> + .dai_type = TYPE_PRI,
> >> + .quirks = QUIRK_NO_MUXPSR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv4_dai_type = {
> >> + .dai_type = TYPE_PRI,
> >> + .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv5_c100_dai_type = {
> >> + .dai_type = TYPE_PRI,
> >> + .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR | QUIRK_SEC_DAI |
> >> + QUIRK_NEED_RSTCLR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data i2sv5_dai_type = {
> >> + .dai_type = TYPE_PRI,
> >> + .quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR,
> >> +};
> >> +
> >> +static struct samsung_i2s_dai_data samsung_dai_type_sec = {
> >> + .dai_type = TYPE_SEC,
> >> +};
> >> +
> >> 
> >>  static struct platform_device_id samsung_i2s_driver_ids[] = {
> >>  
> >>   {
> >> 
> >> - .name   = "samsung-i2s",
> >> - .driver_data= TYPE_PRI,
> >> + .name   = "samsung,s3c6410-i2s",
> >> + .driver_data= (kernel_ulong_t)&i2sv3_dai_type,
> >> + }, {
> >> + .name   = "samsung,s3c6410-i2s-multi",
> >> + .driver_data= (kernel_ulong_t)&i2sv4_dai_type,
> >> + }, {
> >> + .name   = "samsung,s5pc100-i2s",
> >> + .driver_data= (kernel_ulong_t)&i2sv5_c100_dai_type,
> >> 
> >>   }, {
> >> 
> >> - .name   = "samsung-i2s-sec",
> >> - .driver_data= TYPE_SEC,
> >> + .name   = "samsung,s5pv210-i2s",
> >> + .driver_data= (kernel_ulong_t)&i2sv5_dai_type,
> >> + }, {
> >> + .name   = "samsung-i2s-sec",
> >> + .driver_data=
> >> (kernel_ulong_t)&samsung_dai_type_sec,
> > 
> > I don't think you need to change the legacy platform IDs at all.
> 
> If legacy platforms not required to change then I need to introduce a
> new samsung_i2s_dai_data structure which holds only dai_type for
> non-dt platforms. If I change legacy platforms it breaks the older
> platforms now. Is it okay adding a samsung_i2s_dai_data structure for
> non-dt platforms which will be removed later?

Sorry, I don't understand the problem here.

Original contents of samsung_i2s_driver_ids[] array already conveyed 
information about dai type inside driver_data field of each 
platform_device_id entry.

If you really need to have samsung_i2s_dai_data struct for both DT and 
non-DT cases you can create dummy dai_data for both platform ID entries, 
which would have only dai type field initialized. This would be fine, 
because the non-DT probe path takes anything else from platform_data and 
would not need samsung_i2s_dai_data struct in any other way than getting 
dai_type in probe.

Best regards,
Tomasz

> > IMHO it would be better to keep the old way of quirk retrieval from
> > platform_data (which I think this patch does anyway, because the probe
> > path without DT is unchanged), as it will be dropped in some point in
> > time anyway.
> > 
> > This would also eliminate the need for patch 1.
> > 
> > Best regards,
> > Tomasz
> 
> Thanks
> Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 2/3] ASoC: Samsung: I2S: Add quirks as driver data in I2S

[Padma Venkat]

Hi Tomasz,

On Wed, Aug 7, 2013 at 4:43 PM, Tomasz Figa  wrote:
> Ahh, one more thing inline.
>

[snip]

>>
>> +static struct samsung_i2s_dai_data i2sv3_dai_type = {
>> + .dai_type = TYPE_PRI,
>> + .quirks = QUIRK_NO_MUXPSR,
>> +};
>> +
>> +static struct samsung_i2s_dai_data i2sv4_dai_type = {
>> + .dai_type = TYPE_PRI,
>> + .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR,
>> +};
>> +
>> +static struct samsung_i2s_dai_data i2sv5_c100_dai_type = {
>> + .dai_type = TYPE_PRI,
>> + .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR | QUIRK_SEC_DAI |
>> + QUIRK_NEED_RSTCLR,
>> +};
>> +
>> +static struct samsung_i2s_dai_data i2sv5_dai_type = {
>> + .dai_type = TYPE_PRI,
>> + .quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR,
>> +};
>> +
>> +static struct samsung_i2s_dai_data samsung_dai_type_sec = {
>> + .dai_type = TYPE_SEC,
>> +};
>> +
>>  static struct platform_device_id samsung_i2s_driver_ids[] = {
>>   {
>> - .name   = "samsung-i2s",
>> - .driver_data= TYPE_PRI,
>> + .name   = "samsung,s3c6410-i2s",
>> + .driver_data= (kernel_ulong_t)&i2sv3_dai_type,
>> + }, {
>> + .name   = "samsung,s3c6410-i2s-multi",
>> + .driver_data= (kernel_ulong_t)&i2sv4_dai_type,
>> + }, {
>> + .name   = "samsung,s5pc100-i2s",
>> + .driver_data= (kernel_ulong_t)&i2sv5_c100_dai_type,
>>   }, {
>> - .name   = "samsung-i2s-sec",
>> - .driver_data= TYPE_SEC,
>> + .name   = "samsung,s5pv210-i2s",
>> + .driver_data= (kernel_ulong_t)&i2sv5_dai_type,
>> + }, {
>> + .name   = "samsung-i2s-sec",
>> + .driver_data= (kernel_ulong_t)&samsung_dai_type_sec,
>
> I don't think you need to change the legacy platform IDs at all.

If legacy platforms not required to change then I need to introduce a
new samsung_i2s_dai_data structure which holds only dai_type for
non-dt platforms. If I change legacy platforms it breaks the older
platforms now. Is it okay adding a samsung_i2s_dai_data structure for
non-dt platforms which will be removed later?

>
> IMHO it would be better to keep the old way of quirk retrieval from
> platform_data (which I think this patch does anyway, because the probe path
> without DT is unchanged), as it will be dropped in some point in time
> anyway.
>
> This would also eliminate the need for patch 1.
>
> Best regards,
> Tomasz
>

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5] pci: exynos: split into two parts such as Synopsys part and Exynos part

[Jingoo Han]

On Thursday, August 08, 2013 2:05 AM, Bjorn Helgaas wrote:
> On Tue, Aug 6, 2013 at 10:13 PM, Jingoo Han  wrote:
> > On Wednesday, July 31, 2013 5:14 PM, Jingoo Han  wrote:
> >> Exynos PCIe IP consists of Synopsys specific part and Exynos
> >> specific part. Only core block is a Synopsys designware part;
> >> other parts are Exynos specific.
> >> Also, the Synopsys designware part can be shared with other
> >> platforms; thus, it can be split two parts such as Synopsys
> >> designware part and Exynos specific part.
> >>
> >> Signed-off-by: Jingoo Han 
> >> Cc: Pratyush Anand 
> >> Cc: Mohit KUMAR 
> >
> > Hi Bjorn Helgaas,
> >
> > There is no comment for last 2 weeks.
> > Will you accept this patch?
> 
> I don't have any problem with this, since it's really arch code.  Do
> you want me to merge it, or do you have a standard path for merging
> Exynos and/or Designware changes?

Hi Bjorn,

I want you to merge it. :)
Thank you.

Best regards,
Jingoo Han

> 
> Bjorn
> 
> In case you need it:
> 
> Acked-by: Bjorn Helgaas 
> 
> >> ---
> >> Changes since v4:
> >> - fixed section mismatch warnings
> >> - fixed sparse warnings
> >>
> >>  .../devicetree/bindings/pci/designware-pcie.txt|3 +
> >>  arch/arm/boot/dts/exynos5440.dtsi  |2 +
> >>  drivers/pci/host/Makefile  |3 +-
> >>  drivers/pci/host/pci-exynos.c  |  530 ++
> >>  drivers/pci/host/pcie-designware.c | 1011 
> >> ++--
> >>  drivers/pci/host/pcie-designware.h |   65 ++
> >>  6 files changed, 874 insertions(+), 740 deletions(-)
> >>  create mode 100644 drivers/pci/host/pci-exynos.c
> >>  create mode 100644 drivers/pci/host/pcie-designware.h
> >

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