[PATCH v2 2/2] ARM: dts: exynos542x: add GSCL block parent clock management to pm domain

[Marek Szyprowski]

Add support for restoring GScaler parent clocks configuration when GSCL
power domain is turned on.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos5420.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 1b3d6c7..5d00c18 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -252,8 +252,10 @@
compatible = "samsung,exynos4210-pd";
reg = <0x10044000 0x20>;
#power-domain-cells = <0>;
-   clocks = < CLK_GSCL0>, < CLK_GSCL1>;
-   clock-names = "asb0", "asb1";
+   clocks = < CLK_FIN_PLL>,
+< CLK_MOUT_USER_ACLK300_GSCL>,
+< CLK_GSCL0>, < CLK_GSCL1>;
+   clock-names = "oscclk", "clk0", "asb0", "asb1";
};
 
isp_pd: power-domain@10044020 {
-- 
1.9.2

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

Re: [PATCH 3/7] of: reserved_mem: add support for named reserved mem nodes

[Marek Szyprowski]

Hello,

On 2015-12-08 15:58, Rob Herring wrote:

On Mon, Dec 7, 2015 at 6:08 AM, Marek Szyprowski
 wrote:

This patch allows device drivers to use more than one reserved memory
region assigned to given device. When NULL name is passed to
of_reserved_mem_device_init(), the default (first) region is used.

Every property that's an array does not need a name property. Just use
indexes please.


Okay, I will update the patch and add support for indices in the main
implementation as well as a wrapper, which accepts "name" parameter.




Signed-off-by: Marek Szyprowski 
---
  drivers/of/of_reserved_mem.c| 101 +++-
  include/linux/of_reserved_mem.h |   6 ++-
  2 files changed, 84 insertions(+), 23 deletions(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1a3556a9e9ea..0a0b23b73004 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 

  #define MAX_RESERVED_REGIONS   16
  static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -287,31 +288,84 @@ static inline struct reserved_mem *__find_rmem(struct 
device_node *node)
 return NULL;
  }

+static struct reserved_mem *__node_to_rmem(struct device_node *node,
+  const char *name)
+{
+   struct reserved_mem *rmem;
+   struct device_node *target;
+   int idx = 0;
+
+   if (!node)
+   return NULL;
+
+   if (name) {
+   idx = of_property_match_string(node,
+  "memory-region-names", name);
+   if (idx < 0)
+   return NULL;
+   }
+
+   target = of_parse_phandle(node, "memory-region", idx);
+   if (!target)
+   return NULL;
+   rmem = __find_rmem(target);
+   of_node_put(target);
+
+   return rmem;
+}
+
+struct rmem_assigned_device {
+   struct device *dev;
+   struct reserved_mem *rmem;
+   struct list_head list;
+};
+
+static LIST_HEAD(of_rmem_assigned_device_list);
+static DEFINE_MUTEX(of_rmem_assigned_device_mutex);

Not that this is a fast or contended path, but I think a spinlock
would be more appropriate here.


This is not meant to be called really often and for all kinds on 
initialization lists
and structures I saw that mutexes are used instead of spinlocks. There 
is no intention

to let this function to be called from atomic context.




+
  /**
   * of_reserved_mem_device_init() - assign reserved memory region to given 
device
+ * @dev:   Pointer to the device to configure
+ * @np:Pointer to the device_node with 'reserved-memory' 
property
+ * @name:  Optional name of the selected region (can be NULL)
+ *
+ * This function assigns respective DMA-mapping operations based on reserved
+ * memory regionspecified by 'memory-region' property in @np node, named @name
+ * to the @dev device. When NULL name is provided, the default (first) memory
+ * region is used. When driver needs to use more than one reserved memory
+ * region, it should allocate child devices and initialize regions by name for
+ * each of child device.
   *
- * This function assign memory region pointed by "memory-region" device tree
- * property to the given device.
+ * Returns error code or zero on success.
   */
-int of_reserved_mem_device_init(struct device *dev)
+int of_reserved_mem_device_init(struct device *dev, struct device_node *np,
+   const char *name)
  {
+   struct rmem_assigned_device *rd;
 struct reserved_mem *rmem;
-   struct device_node *np;
 int ret;

-   np = of_parse_phandle(dev->of_node, "memory-region", 0);
-   if (!np)
-   return -ENODEV;
-
-   rmem = __find_rmem(np);
-   of_node_put(np);
-
+   rmem = __node_to_rmem(np, name);
 if (!rmem || !rmem->ops || !rmem->ops->device_init)
 return -EINVAL;

+   rd = kmalloc(sizeof(struct rmem_assigned_device), GFP_KERNEL);
+   if (!rd)
+   return -ENOMEM;
+
 ret = rmem->ops->device_init(rmem, dev);
-   if (ret == 0)
+   if (ret == 0) {
+   rd->dev = dev;
+   rd->rmem = rmem;
+
+   mutex_lock(_rmem_assigned_device_mutex);
+   list_add(>list, _rmem_assigned_device_list);
+   mutex_unlock(_rmem_assigned_device_mutex);
+
 dev_info(dev, "assigned reserved memory node %s\n", 
rmem->name);
+   } else {
+   kfree(rd);
+   }

 return ret;
  }
@@ -319,21 +373,26 @@ EXPORT_SYMBOL_GPL(of_reserved_mem_device_init);

  /**
   * of_reserved_mem_device_release() - release reserved memory device 
structures
+ * @dev:   Pointer to the device to deconfigure
   *
   * This function releases structures allocated for memory region handling for
   * the 

Re: [PATCH v2 00/25] mtd: nand: refactor the NAND subsystem (part 1)

[Boris Brezillon]

Hi Brian,

On Tue, 8 Dec 2015 16:36:24 -0800
Brian Norris  wrote:

> Hi,
> 
> On Tue, Dec 01, 2015 at 12:02:57PM +0100, Boris Brezillon wrote:
> > Hello,
> > 
> > This huge series aims at clarifying the relationship between the mtd and
> > nand_chip structures and hiding NAND framework internals to NAND
> > controller drivers.
> > 
> > The first part of the series provide an mtd_to_nand() helper to hide the
> > way mtd and nand_chip are linked together.
> > 
> > The second part of the series embeds the mtd structure into the nand_chip
> > one so that NAND controller drivers don't have to bother allocating the
> > MTD device and linking it with the NAND chip.
> > 
> > The last part of the series hides accesses to the chip->priv field behind
> > two helper functions.
> > 
> > This allows removal of some of the boilerplate code done in all NAND
> > controller drivers, but most importantly, it unifies a bit the way NAND
> > chip structures are instantiated (even though we still have two different
> > kinds of drivers: those embedding the nand_chip struct into their private
> > nand chip representation, and those allocating two different structures
> > and linking them together with the chip->priv field).
> > 
> > As said in the title, this refactoring is only the first step. I plan to
> > rework the NAND controller / NAND chip separation for pretty much the same
> > reasons: clarifying the separation between the two concepts, and getting
> > rid of more boilerplate code in NAND controller drivers.
> > 
> > Stay tuned ;-).
> > 
> > Best Regards,
> > 
> > Boris
> > 
> > Changes since v1:
> > - dropped already applied patches
> > - fixed some typos
> > - manually fixed some modifications omitted by the coccinelle scripts
> > - manually reworked modifactions done by coccinelle scripts to improve
> >   readability and fix coding style issues
> > 
> > Boris Brezillon (25):
> >   ARM: nand: make use of mtd_to_nand() where appropriate
> 
> I've sent this (+ the introduction of mtd_to_nand()) in a pull request
> to arm-soc, as well as to l2-mtd.git.
> 
> >   blackfin: nand: make use of mtd_to_nand() where appropriate
> >   cris: nand: make use of mtd_to_nand() where appropriate
> >   mips: nand: make use of mtd_to_nand() where appropriate
> 
> I've based these on v4.4-rc1 and brought them into l2-mtd.git, in case
> any arch/{blackfin,cris,mips}/ people want to pull them in too.
> 
> >   sh: nand: make use of mtd_to_nand() where appropriate
> >   mtd: nand: make use of mtd_to_nand() in NAND core code
> >   mtd: nand: make use of mtd_to_nand() in NAND drivers
> >   staging: mt29f_spinand: make use of mtd_to_nand()
> >   mtd: nand: embed an mtd_info structure into nand_chip
> >   mtd: nand: add nand_to_mtd() helper
> 
> Pulled the rest up to here into l2-mtd.git.

Okay, thanks.

> 
> >   coccinelle: nand: detect and correct drivers embedding an mtd_info
> > object
> 
> I believe Julia had comments on this. That probably would go through the
> kbuild tree in the end anyway (?).

Julia proposed to generate this script using sgen, so I guess this will
come later through a different tree.

> 
> >   mtd: nand: use the mtd instance embedded in struct nand_chip
> 
> There's still at least one problem in this patch (commented on the
> patch). It touches a lot of drivers, so any extra review would be great.

Yep, I think I'll resend the series and split the modification so that
you can pick changes independently (as you suggested a few days ago).

Anyway, reviews from other people would be much appreciated. As I said,
most of changes have been automated with coccinelle, but some of them
have been made manually done, and this is the case for all drivers using
the following pattern:

var = kzalloc(sizeof(struct mtd_info) +
  sizeof(struct nand_chip) + ... ,...);

because I failed to find a pattern common enough to match the cases I
had, and manually fixing them was easier for me...

> 
> >   mtd: nand: update the documentation to reflect framework changes
> >   staging: mt29f_spinand: use the mtd instance embedded in struct
> > nand_chip
> >   cris: nand: use the mtd instance embedded in struct nand_chip
> >   mtd: nand: update mtd_to_nand()
> >   mtd: nand: remove useless mtd->priv = chip assignments
> >   cris: nand: remove useless mtd->priv = chip assignments
> >   staging: mt29f_spinand: remove useless mtd->priv = chip assignment
> >   mtd: nand: simplify nand_dt_init() usage
> >   mtd: nand: kill the chip->flash_node field
> >   mtd: nand: add helpers to access ->priv
> >   ARM: make use of nand_set/get_controller_data() helpers
> >   mtd: nand: make use of nand_set/get_controller_data() helpers
> >   staging: mt29f_spinand: make use of nand_set/get_controller_data()
> > helpers
> 
> All the rest look good to me. I'll wait until I get a good copy of patch
> 12 before taking them.

Sure.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel 

Re: [PATCH v3 bis 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip

[Boris Brezillon]

Hi Brian,

On Tue, 8 Dec 2015 16:17:41 -0800
Brian Norris  wrote:

> 
> > diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
> > index 43bded6..84d027e 100644
> > --- a/drivers/mtd/nand/cmx270_nand.c
> > +++ b/drivers/mtd/nand/cmx270_nand.c
> > @@ -160,10 +160,8 @@ static int __init cmx270_init(void)
> > gpio_direction_input(GPIO_NAND_RB);
> >  
> > /* Allocate memory for MTD device structure and private data */
> > -   cmx270_nand_mtd = kzalloc(sizeof(struct mtd_info) +
> > - sizeof(struct nand_chip),
> > - GFP_KERNEL);
> > -   if (!cmx270_nand_mtd) {
> > +   this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
> > +   if (!this) {
> > ret = -ENOMEM;
> > goto err_kzalloc;
> > }
> > @@ -175,8 +173,7 @@ static int __init cmx270_init(void)
> > goto err_ioremap;
> > }
> >  
> > -   /* Get pointer to private data */
> > -   this = (struct nand_chip *)(_nand_mtd[1]);
> > +   cmx270_nand_mtd = nand_to_mtd(this);
> 
> So, you make cmx270_nand_mtd no longer kzalloc()'d, but I still see the
> cmx270_init() function end with:
> 
> err_scan:
> iounmap(cmx270_nand_io);
> err_ioremap:
> kfree(cmx270_nand_mtd);  <- *** this! ***

Oh, crap.

> err_kzalloc:
> gpio_free(GPIO_NAND_RB);
> err_gpio_request:
>   gpio_free(GPIO_NAND_CS);
> 
>   return ret;
> 
> }
> 
> I have a feeling there's a failing in your coccinelle script somewhere.

These changes are not automated, because it's kind of hard to address
all the different cases where the following pattern is employed;

var = kzalloc(sizeof(struct mtd_info) +
  sizeof(struct nand_chip) + ..., ...);

Sometime var is an mtd_info pointer, sometime it's a nand_chip pointer
or directly a pointer to the private struct.

I'm pretty sure we could come up with a valid coccinelle script, but
given the number of drivers using this approach I'm not sure it is
worth it...

> 
> Given that I was only through 10 of 49 files changes, I think you might
> need to take a comb over your patch better.

I'll go over those changes one more time, but from my experience, these
kind of bugs are spotted more easily by people who didn't write the
code, so other reviews are more than welcome.

Also, as you suggested, I'll split the changes in several commits (one
per driver) so that you can pick them independently.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] clk: samsung: exynos5422: add missing parent GSCL block clocks

[Sylwester Nawrocki]

Adding Stephen and linux-clk at Cc.

On 09/12/15 05:49, Krzysztof Kozlowski wrote:
> On 08.12.2015 22:46, Marek Szyprowski wrote:
>> > This patch adds clocks, which are required for preserving parent clock
>> > configuration on GSCL power domain on/off.
>> > 
>> > Signed-off-by: Marek Szyprowski 
>> > ---
>> >  drivers/clk/samsung/clk-exynos5420.c   | 8 
>> >  include/dt-bindings/clock/exynos5420.h | 2 ++
>> >  2 files changed, 6 insertions(+), 4 deletions(-)
>
> I suppose that, with ack from clock folks, this can go through samsung-soc?

I guess it makes more sense that making a stable branch with just
this patch to be pulled into arm-soc and clk tree. I'm fine with
applying this patch through arm-soc, but I think we also need
Mike's or Stephen ack for this.

Acked-by: Sylwester Nawrocki 

-- 
Thanks,
Sylwester
--
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] drm/exynos: atomic check only enabled crtc states

[Javier Martinez Canillas]

Hello Inki,

On 11/27/2015 10:00 AM, Javier Martinez Canillas wrote:
> Hello Andrzej,
> 
> On 11/27/2015 03:57 AM, Andrzej Hajda wrote:
>> Since atomic check is called also for disabled crtcs it should skip
>> mode checking as it can be uninitialized. The patch fixes it.
>>
>> Signed-off-by: Andrzej Hajda 
>> Suggested-by: Daniel Vetter 
>> ---
>> Hi Javier,
>>
>> Could you check with this patch.
>>
> 
> The patch fixes the issue I reported. The display mode is correctly set
> with and without a HDMI monitor plugged. So on an Exynos5800 Peach Pi:
> 
> Tested-by: Javier Martinez Canillas 
> 

This patch was never picked but fixes and important
bug introduced in the v4.4 merge window so it should
be sent during the v4.4-rc cycle.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/8] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms

[Javier Martinez Canillas]

Hello Bartlomiej,

On 12/07/2015 03:18 PM, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patch series adds generic cpufreq-dt driver support for
> Exynos542x/5800 (using the new CPU clock type which allows it).
> 
> It has been tested on Exynos5422 based ODROID-XU3 Lite board.
>

I tested on an Exynos5800 Peach Pi and all governors are working
as expected on both the Cortex-A7 and Cortex-A15 cores.

So for the whole series:

Tested-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: dts: exynos542x: add GSCL block parent clock management to pm domain

[Krzysztof Kozlowski]

W dniu 09.12.2015 o 17:07, Marek Szyprowski pisze:
> Add support for restoring GScaler parent clocks configuration when GSCL
> power domain is turned on.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Changelog is always nice, even though the traffic on samsung-soc is not
huge now.

Anyway, thanks for update:

Reviewed-by: Krzysztof Kozlowski 

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

[PATCH v2 6/7] media: s5p-mfc: replace custom reserved memory init code with generic one

[Marek Szyprowski]

This patch removes custom code for initialization and handling of
reserved memory regions in s5p-mfc driver and replaces it with generic
named reserved memory regions specified in device tree.

s5p-mfc driver now handles two reserved memory regions: "left" and
"right", defined by generic reserved memory bindings. Support for non-dt
platform has been removed, because all supported platforms have been
converted to device tree.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 129 +++
 1 file changed, 62 insertions(+), 67 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3e9cdaf..3063449 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "s5p_mfc_common.h"
 #include "s5p_mfc_ctrl.h"
@@ -1022,55 +1023,67 @@ static const struct v4l2_file_operations s5p_mfc_fops = 
{
.mmap = s5p_mfc_mmap,
 };
 
-static int match_child(struct device *dev, void *data)
+/* DMA memory related helper functions */
+static void s5p_mfc_memdev_release(struct device *dev)
 {
-   if (!dev_name(dev))
-   return 0;
-   return !strcmp(dev_name(dev), (char *)data);
+   of_reserved_mem_device_release(dev);
 }
 
-static void *mfc_get_drv_data(struct platform_device *pdev);
-
-static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
+static struct device *s5p_mfc_alloc_memdev(struct device *dev, const char 
*name)
 {
-   unsigned int mem_info[2] = { };
+   struct device *child;
+   int ret;
 
-   dev->mem_dev_l = devm_kzalloc(>plat_dev->dev,
-   sizeof(struct device), GFP_KERNEL);
-   if (!dev->mem_dev_l) {
-   mfc_err("Not enough memory\n");
-   return -ENOMEM;
-   }
-   device_initialize(dev->mem_dev_l);
-   of_property_read_u32_array(dev->plat_dev->dev.of_node,
-   "samsung,mfc-l", mem_info, 2);
-   if (dma_declare_coherent_memory(dev->mem_dev_l, mem_info[0],
-   mem_info[0], mem_info[1],
-   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
-   mfc_err("Failed to declare coherent memory for\n"
-   "MFC device\n");
-   return -ENOMEM;
+   child = devm_kzalloc(dev, sizeof(struct device), GFP_KERNEL);
+   if (!child)
+   return NULL;
+
+   device_initialize(child);
+   dev_set_name(child, "%s:%s", dev_name(dev), name);
+   child->parent = dev;
+   child->bus = dev->bus;
+   child->coherent_dma_mask = dev->coherent_dma_mask;
+   child->dma_mask = dev->dma_mask;
+   child->release = s5p_mfc_memdev_release;
+
+   if (device_add(child) == 0) {
+   ret = of_reserved_mem_init_by_name(child, dev->of_node, name);
+   if (ret == 0)
+   return child;
}
 
-   dev->mem_dev_r = devm_kzalloc(>plat_dev->dev,
-   sizeof(struct device), GFP_KERNEL);
-   if (!dev->mem_dev_r) {
-   mfc_err("Not enough memory\n");
-   return -ENOMEM;
-   }
-   device_initialize(dev->mem_dev_r);
-   of_property_read_u32_array(dev->plat_dev->dev.of_node,
-   "samsung,mfc-r", mem_info, 2);
-   if (dma_declare_coherent_memory(dev->mem_dev_r, mem_info[0],
-   mem_info[0], mem_info[1],
-   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
-   pr_err("Failed to declare coherent memory for\n"
-   "MFC device\n");
-   return -ENOMEM;
+   put_device(child);
+   return NULL;
+}
+
+static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev)
+{
+   struct device *dev = _dev->plat_dev->dev;
+
+   /*
+* Create and initialize virtual devices for accessing
+* reserved memory regions.
+*/
+   mfc_dev->mem_dev_l = s5p_mfc_alloc_memdev(dev, "left");
+   if (!mfc_dev->mem_dev_l)
+   return -ENODEV;
+   mfc_dev->mem_dev_r = s5p_mfc_alloc_memdev(dev, "right");
+   if (!mfc_dev->mem_dev_r) {
+   device_unregister(mfc_dev->mem_dev_l);
+   return -ENODEV;
}
+
return 0;
 }
 
+static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
+{
+   device_unregister(mfc_dev->mem_dev_l);
+   device_unregister(mfc_dev->mem_dev_r);
+}
+
+static void *mfc_get_drv_data(struct platform_device *pdev);
+
 /* MFC probe function */
 static int s5p_mfc_probe(struct platform_device *pdev)
 {
@@ -1096,12 +1109,6 @@ static int s5p_mfc_probe(struct platform_device *pdev)
 
dev->variant = mfc_get_drv_data(pdev);
 
-   ret = s5p_mfc_init_pm(dev);
-   if (ret < 0) {
-   dev_err(>dev, "failed to 

[PATCH v2 4/7] media: vb2-dma-contig: add helper for setting dma max seg size

[Marek Szyprowski]

Add a helper function for device drivers to set DMA's max_seg_size.
Setting it to largest possible value lets DMA-mapping API always create
contiguous mappings in DMA address space. This is essential for all
devices, which use dma-contig videobuf2 memory allocator and shared
buffers.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++
 include/media/videobuf2-dma-contig.h   |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index c331272..628518d 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -742,6 +742,21 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
 }
 EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
 
+int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size)
+{
+   if (!dev->dma_parms) {
+   dev->dma_parms = devm_kzalloc(dev, sizeof(dev->dma_parms),
+ GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+   if (dma_get_max_seg_size(dev) < size)
+   return dma_set_max_seg_size(dev, size);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
+
 MODULE_DESCRIPTION("DMA-contig memory handling routines for videobuf2");
 MODULE_AUTHOR("Pawel Osciak ");
 MODULE_LICENSE("GPL");
diff --git a/include/media/videobuf2-dma-contig.h 
b/include/media/videobuf2-dma-contig.h
index c33dfa6..0e6ba64 100644
--- a/include/media/videobuf2-dma-contig.h
+++ b/include/media/videobuf2-dma-contig.h
@@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb, unsigned 
int plane_no)
 
 void *vb2_dma_contig_init_ctx(struct device *dev);
 void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
+int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size);
 
 extern const struct vb2_mem_ops vb2_dma_contig_memops;
 
-- 
1.9.2

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

[PATCH v2 7/7] media: s5p-mfc: add iommu support

[Marek Szyprowski]

This patch adds support for IOMMU to s5p-mfc device driver. MFC firmware
is limited and it cannot use the default configuration. If IOMMU is
available, the patch disables the default DMA address space
configuration and creates a new address space of size limited to 256M
and base address set to 0x2000.

For now the same address space is shared by both 'left' and 'right'
memory channels, because the DMA/IOMMU frameworks do not support
configuring them separately. This is not optimal, but besides limiting
total address space available has no other drawbacks (MFC firmware
supports 256M of address space per each channel).

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 24 
 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h | 79 ++
 2 files changed, 103 insertions(+)
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3063449..bae7c0f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -30,6 +30,7 @@
 #include "s5p_mfc_dec.h"
 #include "s5p_mfc_enc.h"
 #include "s5p_mfc_intr.h"
+#include "s5p_mfc_iommu.h"
 #include "s5p_mfc_opr.h"
 #include "s5p_mfc_cmd.h"
 #include "s5p_mfc_pm.h"
@@ -1061,6 +1062,22 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
struct device *dev = _dev->plat_dev->dev;
 
/*
+* When IOMMU is available, we cannot use the default configuration,
+* because of MFC firmware requirements: address space limited to
+* 256M and non-zero default start address.
+* This is still simplified, not optimal configuration, but for now
+* IOMMU core doesn't allow to configure device's IOMMUs channel
+* separately.
+*/
+   if (exynos_is_iommu_available(dev)) {
+   int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
+S5P_MFC_IOMMU_DMA_SIZE);
+   if (ret == 0)
+   mfc_dev->mem_dev_l = mfc_dev->mem_dev_r = dev;
+   return ret;
+   }
+
+   /*
 * Create and initialize virtual devices for accessing
 * reserved memory regions.
 */
@@ -1078,6 +1095,13 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
 
 static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
 {
+   struct device *dev = _dev->plat_dev->dev;
+
+   if (exynos_is_iommu_available(dev)) {
+   exynos_unconfigure_iommu(dev);
+   return;
+   }
+
device_unregister(mfc_dev->mem_dev_l);
device_unregister(mfc_dev->mem_dev_r);
 }
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
new file mode 100644
index 000..5d1d1c2
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics Co.Ltd
+ * Authors: Marek Szyprowski 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#ifndef S5P_MFC_IOMMU_H_
+#define S5P_MFC_IOMMU_H_
+
+#define S5P_MFC_IOMMU_DMA_BASE 0x2000lu
+#define S5P_MFC_IOMMU_DMA_SIZE SZ_256M
+
+#ifdef CONFIG_EXYNOS_IOMMU
+
+#include 
+
+static inline bool exynos_is_iommu_available(struct device *dev)
+{
+   return dev->archdata.iommu != NULL;
+}
+
+static inline void exynos_unconfigure_iommu(struct device *dev)
+{
+   struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+   arm_iommu_detach_device(dev);
+   arm_iommu_release_mapping(mapping);
+}
+
+static inline int exynos_configure_iommu(struct device *dev,
+unsigned int base, unsigned int size)
+{
+   struct dma_iommu_mapping *mapping = NULL;
+   int ret;
+
+   /* Disable the default mapping created by device core */
+   if (to_dma_iommu_mapping(dev))
+   exynos_unconfigure_iommu(dev);
+
+   mapping = arm_iommu_create_mapping(dev->bus, base, size);
+   if (IS_ERR(mapping)) {
+   pr_warn("Failed to create IOMMU mapping for device %s\n",
+   dev_name(dev));
+   return PTR_ERR(mapping);
+   }
+
+   ret = arm_iommu_attach_device(dev, mapping);
+   if (ret) {
+   pr_warn("Failed to attached device %s to IOMMU_mapping\n",
+   dev_name(dev));
+   arm_iommu_release_mapping(mapping);
+   return ret;
+   }
+
+   return 0;
+}
+
+#else
+
+static inline bool exynos_is_iommu_available(struct device *dev)
+{
+   

[PATCH v2 0/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support

[Marek Szyprowski]

Hello,

This patchset finally perform cleanup of custom code in s5p-mfc codec
driver. The first part is removal of custom, driver specific code for
intializing and handling of reserved memory. Instead, a generic code for
reserved memory regions is used. Then, once it is done, the proper setup
of DMA parameters (max segment size) is applied for all multimedia
devices found on Exynos SoCs to let them properly handle shared buffers
mapped into contiguous DMA address space. The last patch adds support
for IOMMU to MFC driver. Some additional code is needed because of
specific requirements of MFC device firmware (see patch 7 for more
details). When no IOMMU is available, the code fallbacks to generic
reserved memory regions.

After applying this patchset, MFC device works correctly when IOMMU is
either enabled or disabled.

Patches have been tested on top of linux-next from 20151207. I would
prefer to merge patches 1-2 via Samsung tree and patches 3-7 via media
tree (there are no compile-time dependencies between patches 1-2 and
3-7). Patches have been tested on Odroid U3 (Exynos 4412 based) and
Odroid XU3 (Exynos 5422 based) boards.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Changelog:
v2:
- reworked of_reserved_mem_init* functions on request from Rob Herring,
  added separate index and name based selection of reserved region
- adapted for of_reserved_mem_init* related changes

v1: https://www.mail-archive.com/linux-media@vger.kernel.org/msg94100.html
- initial version of another approach for this problem, rewrote driver code
  for new reserved memory bindings, which finally have been merged some
  time ago

v0: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/189259.html
- old patchset solving the same problem, abandoned due to other tasks
  and long time of merging reserved memory bindings and support code for
  it

Patch summary:

Marek Szyprowski (7):
  ARM: Exynos: convert MFC device to generic reserved memory bindings
  ARM: dts: exynos4412-odroid*: enable MFC device
  of: reserved_mem: add support for named reserved mem nodes
  media: vb2-dma-contig: add helper for setting dma max seg size
  media: set proper max seg size for devices on Exynos SoCs
  media: s5p-mfc: replace custom reserved memory init code with generic
one
  media: s5p-mfc: add iommu support

 .../devicetree/bindings/media/s5p-mfc.txt  |  16 +--
 arch/arm/boot/dts/exynos4210-origen.dts|  22 ++-
 arch/arm/boot/dts/exynos4210-smdkv310.dts  |  22 ++-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|  24 
 arch/arm/boot/dts/exynos4412-origen.dts|  22 ++-
 arch/arm/boot/dts/exynos4412-smdk4412.dts  |  22 ++-
 arch/arm/boot/dts/exynos5250-arndale.dts   |  22 ++-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |  22 ++-
 arch/arm/boot/dts/exynos5250-spring.dts|  22 ++-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  22 ++-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |  22 ++-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  22 ++-
 arch/arm/mach-exynos/Makefile  |   2 -
 arch/arm/mach-exynos/exynos.c  |  19 ---
 arch/arm/mach-exynos/mfc.h |  16 ---
 arch/arm/mach-exynos/s5p-dev-mfc.c |  94 -
 drivers/media/platform/exynos-gsc/gsc-core.c   |   1 +
 drivers/media/platform/exynos4-is/fimc-core.c  |   1 +
 drivers/media/platform/exynos4-is/fimc-is.c|   1 +
 drivers/media/platform/exynos4-is/fimc-lite.c  |   1 +
 drivers/media/platform/s5p-g2d/g2d.c   |   1 +
 drivers/media/platform/s5p-jpeg/jpeg-core.c|   1 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 153 -
 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h |  79 +++
 drivers/media/platform/s5p-tv/mixer_video.c|   1 +
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  15 ++
 drivers/of/of_reserved_mem.c   | 104 +++---
 include/linux/of_reserved_mem.h|  31 -
 include/media/videobuf2-dma-contig.h   |   1 +
 29 files changed, 533 insertions(+), 248 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/mfc.h
 delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
 create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h

-- 
1.9.2

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

[PATCH v2 2/7] ARM: dts: exynos4412-odroid*: enable MFC device

[Marek Szyprowski]

Enable support for Multimedia Codec (MFC) device for all Exynos4412-based
Odroid boards.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index edf0fc8..5825abf 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -18,6 +18,24 @@
stdout-path = _1;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mfc_left: region@7700 {
+   compatible = "shared-dma-pool";
+   reusable;
+   reg = <0x7700 0x100>;
+   };
+
+   mfc_right: region@7800 {
+   compatible = "shared-dma-pool";
+   reusable;
+   reg = <0x7800 0x100>;
+   };
+   };
+
firmware@0204F000 {
compatible = "samsung,secure-firmware";
reg = <0x0204F000 0x1000>;
@@ -451,6 +469,12 @@
clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
 };
 
+ {
+   memory-region = <_left>, <_right>;
+   memory-region-names = "left", "right";
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
1.9.2

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

[PATCH v2 3/7] of: reserved_mem: add support for named reserved mem nodes

[Marek Szyprowski]

This patch allows device drivers to initialize more than one reserved
memory region assigned to given device. When driver needs to use more
than one reserved memory region, it should allocate child devices and
initialize regions by index or name for each of its child devices.

Signed-off-by: Marek Szyprowski 
---
 drivers/of/of_reserved_mem.c| 104 
 include/linux/of_reserved_mem.h |  31 ++--
 2 files changed, 112 insertions(+), 23 deletions(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index be77e75..a583480 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_RESERVED_REGIONS   16
 static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -281,53 +282,116 @@ static inline struct reserved_mem *__find_rmem(struct 
device_node *node)
return NULL;
 }
 
+struct rmem_assigned_device {
+   struct device *dev;
+   struct reserved_mem *rmem;
+   struct list_head list;
+};
+
+static LIST_HEAD(of_rmem_assigned_device_list);
+static DEFINE_MUTEX(of_rmem_assigned_device_mutex);
+
 /**
  * of_reserved_mem_device_init() - assign reserved memory region to given 
device
+ * @dev:   Pointer to the device to configure
+ * @np:Pointer to the device_node with 'reserved-memory' 
property
+ * @idx:   Index of selected region
+ *
+ * This function assigns respective DMA-mapping operations based on reserved
+ * memory region specified by 'memory-region' property in @np node to the @dev
+ * device. When driver needs to use more than one reserved memory region, it
+ * should allocate child devices and initialize regions by name for each of
+ * child device.
  *
- * This function assign memory region pointed by "memory-region" device tree
- * property to the given device.
+ * Returns error code or zero on success.
  */
-int of_reserved_mem_device_init(struct device *dev)
+int of_reserved_mem_init(struct device *dev, struct device_node *np, int idx)
 {
+   struct rmem_assigned_device *rd;
+   struct device_node *target;
struct reserved_mem *rmem;
-   struct device_node *np;
int ret;
 
-   np = of_parse_phandle(dev->of_node, "memory-region", 0);
-   if (!np)
-   return -ENODEV;
+   if (!np || !dev)
+   return -EINVAL;
+
+   target = of_parse_phandle(np, "memory-region", idx);
+   if (!target)
+   return -EINVAL;
 
-   rmem = __find_rmem(np);
-   of_node_put(np);
+   rmem = __find_rmem(target);
+   of_node_put(target);
 
if (!rmem || !rmem->ops || !rmem->ops->device_init)
return -EINVAL;
 
+   rd = kmalloc(sizeof(struct rmem_assigned_device), GFP_KERNEL);
+   if (!rd)
+   return -ENOMEM;
+
ret = rmem->ops->device_init(rmem, dev);
-   if (ret == 0)
+   if (ret == 0) {
+   rd->dev = dev;
+   rd->rmem = rmem;
+
+   mutex_lock(_rmem_assigned_device_mutex);
+   list_add(>list, _rmem_assigned_device_list);
+   mutex_unlock(_rmem_assigned_device_mutex);
+
dev_info(dev, "assigned reserved memory node %s\n", rmem->name);
+   } else {
+   kfree(rd);
+   }
 
return ret;
 }
-EXPORT_SYMBOL_GPL(of_reserved_mem_device_init);
+EXPORT_SYMBOL_GPL(of_reserved_mem_init);
+
+/**
+ * of_reserved_mem_device_init() - assign reserved memory region to given 
device
+ * @dev:   Pointer to the device to configure
+ * @np:Pointer to the device_node with 'reserved-memory' 
property
+ * @name:  Name of the selected region
+ *
+ * This function assigns respective DMA-mapping operations based on reserved
+ * memory region specified by 'memory-region' property in @np node, named @name
+ * to the @dev device.
+ *
+ * Returns error code or zero on success.
+ */
+int of_reserved_mem_init_by_name(struct device *dev, struct device_node *np,
+  const char *name)
+{
+   int idx = of_property_match_string(np, "memory-region-names", name);
+
+   if (idx < 0)
+   return -EINVAL;
+   return of_reserved_mem_init(dev, np, idx);
+}
+EXPORT_SYMBOL_GPL(of_reserved_mem_init_by_name);
 
 /**
  * of_reserved_mem_device_release() - release reserved memory device structures
+ * @dev:   Pointer to the device to deconfigure
  *
  * This function releases structures allocated for memory region handling for
  * the given device.
  */
 void of_reserved_mem_device_release(struct device *dev)
 {
-   struct reserved_mem *rmem;
-   struct device_node *np;
-
-   np = of_parse_phandle(dev->of_node, "memory-region", 0);
-   if (!np)
-   return;
-
-   rmem = __find_rmem(np);
-   of_node_put(np);
+   struct rmem_assigned_device *rd;
+   struct 

[PATCH v2 5/7] media: set proper max seg size for devices on Exynos SoCs

[Marek Szyprowski]

All multimedia devices found on Exynos SoCs support only contiguous
buffers, so set DMA max segment size to DMA_BIT_MASK(32) to let memory
allocator to correctly create contiguous memory mappings.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c  | 1 +
 drivers/media/platform/exynos4-is/fimc-core.c | 1 +
 drivers/media/platform/exynos4-is/fimc-is.c   | 1 +
 drivers/media/platform/exynos4-is/fimc-lite.c | 1 +
 drivers/media/platform/s5p-g2d/g2d.c  | 1 +
 drivers/media/platform/s5p-jpeg/jpeg-core.c   | 1 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c  | 2 ++
 drivers/media/platform/s5p-tv/mixer_video.c   | 1 +
 8 files changed, 9 insertions(+)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9b9e423..4f90be4 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1140,6 +1140,7 @@ static int gsc_probe(struct platform_device *pdev)
goto err_m2m;
 
/* Initialize continious memory allocator */
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
gsc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(gsc->alloc_ctx)) {
ret = PTR_ERR(gsc->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c 
b/drivers/media/platform/exynos4-is/fimc-core.c
index cef2a7f..368e19b 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -1019,6 +1019,7 @@ static int fimc_probe(struct platform_device *pdev)
}
 
/* Initialize contiguous memory allocator */
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
fimc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(fimc->alloc_ctx)) {
ret = PTR_ERR(fimc->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c 
b/drivers/media/platform/exynos4-is/fimc-is.c
index 49658ca..123772f 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -841,6 +841,7 @@ static int fimc_is_probe(struct platform_device *pdev)
if (ret < 0)
goto err_pm;
 
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
is->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(is->alloc_ctx)) {
ret = PTR_ERR(is->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
b/drivers/media/platform/exynos4-is/fimc-lite.c
index 60660c3..a7e47c7 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -1564,6 +1564,7 @@ static int fimc_lite_probe(struct platform_device *pdev)
goto err_sd;
}
 
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
fimc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(fimc->alloc_ctx)) {
ret = PTR_ERR(fimc->alloc_ctx);
diff --git a/drivers/media/platform/s5p-g2d/g2d.c 
b/drivers/media/platform/s5p-g2d/g2d.c
index e1936d9..31f6c23 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -681,6 +681,7 @@ static int g2d_probe(struct platform_device *pdev)
goto put_clk_gate;
}
 
+   vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
dev->alloc_ctx = vb2_dma_contig_init_ctx(>dev);
if (IS_ERR(dev->alloc_ctx)) {
ret = PTR_ERR(dev->alloc_ctx);
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 4a608cb..6bd92f0 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2839,6 +2839,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
goto device_register_rollback;
}
 
+   vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
jpeg->alloc_ctx = vb2_dma_contig_init_ctx(>dev);
if (IS_ERR(jpeg->alloc_ctx)) {
v4l2_err(>v4l2_dev, "Failed to init memory allocator\n");
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3ffe2ec..3e9cdaf 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1143,11 +1143,13 @@ static int s5p_mfc_probe(struct platform_device *pdev)
}
}
 
+   vb2_dma_contig_set_max_seg_size(dev->mem_dev_l, DMA_BIT_MASK(32));
dev->alloc_ctx[0] = vb2_dma_contig_init_ctx(dev->mem_dev_l);
if (IS_ERR(dev->alloc_ctx[0])) {
ret = PTR_ERR(dev->alloc_ctx[0]);
goto err_res;
}
+   vb2_dma_contig_set_max_seg_size(dev->mem_dev_r, DMA_BIT_MASK(32));
dev->alloc_ctx[1] = vb2_dma_contig_init_ctx(dev->mem_dev_r);
if (IS_ERR(dev->alloc_ctx[1])) {
ret = 

[PATCH 4/4] media: exynos4-is: remove non-device-tree init code

[Marek Szyprowski]

Exynos and Samsung S5P platforms has been fully converted to device
tree, so old platform device based init data can be now removed.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos4-is/fimc-core.c | 50 ---
 1 file changed, 50 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-core.c 
b/drivers/media/platform/exynos4-is/fimc-core.c
index 368e19b..a470fe5 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -1155,26 +1155,6 @@ static const struct fimc_pix_limit s5p_pix_limit[4] = {
},
 };
 
-static const struct fimc_variant fimc0_variant_s5p = {
-   .has_inp_rot = 1,
-   .has_out_rot = 1,
-   .has_cam_if  = 1,
-   .min_inp_pixsize = 16,
-   .min_out_pixsize = 16,
-   .hor_offs_align  = 8,
-   .min_vsize_align = 16,
-   .pix_limit   = _pix_limit[0],
-};
-
-static const struct fimc_variant fimc2_variant_s5p = {
-   .has_cam_if  = 1,
-   .min_inp_pixsize = 16,
-   .min_out_pixsize = 16,
-   .hor_offs_align  = 8,
-   .min_vsize_align = 16,
-   .pix_limit   = _pix_limit[1],
-};
-
 static const struct fimc_variant fimc0_variant_s5pv210 = {
.has_inp_rot = 1,
.has_out_rot = 1,
@@ -1207,18 +1187,6 @@ static const struct fimc_variant fimc2_variant_s5pv210 = 
{
.pix_limit   = _pix_limit[2],
 };
 
-/* S5PC100 */
-static const struct fimc_drvdata fimc_drvdata_s5p = {
-   .variant = {
-   [0] = _variant_s5p,
-   [1] = _variant_s5p,
-   [2] = _variant_s5p,
-   },
-   .num_entities   = 3,
-   .lclk_frequency = 13300UL,
-   .out_buf_count  = 4,
-};
-
 /* S5PV210, S5PC110 */
 static const struct fimc_drvdata fimc_drvdata_s5pv210 = {
.variant = {
@@ -1252,23 +1220,6 @@ static const struct fimc_drvdata fimc_drvdata_exynos4x12 
= {
.out_buf_count  = 32,
 };
 
-static const struct platform_device_id fimc_driver_ids[] = {
-   {
-   .name   = "s5p-fimc",
-   .driver_data= (unsigned long)_drvdata_s5p,
-   }, {
-   .name   = "s5pv210-fimc",
-   .driver_data= (unsigned long)_drvdata_s5pv210,
-   }, {
-   .name   = "exynos4-fimc",
-   .driver_data= (unsigned long)_drvdata_exynos4210,
-   }, {
-   .name   = "exynos4x12-fimc",
-   .driver_data= (unsigned long)_drvdata_exynos4x12,
-   },
-   { },
-};
-
 static const struct of_device_id fimc_of_match[] = {
{
.compatible = "samsung,s5pv210-fimc",
@@ -1291,7 +1242,6 @@ static const struct dev_pm_ops fimc_pm_ops = {
 static struct platform_driver fimc_driver = {
.probe  = fimc_probe,
.remove = fimc_remove,
-   .id_table   = fimc_driver_ids,
.driver = {
.of_match_table = fimc_of_match,
.name   = FIMC_DRIVER_NAME,
-- 
1.9.2

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

[PATCH 3/4] media: s5p-mfc: remove non-device-tree init code

[Marek Szyprowski]

Exynos and Samsung S5P platforms has been fully converted to device
tree, so old platform device based init data can be now removed.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 37 +---
 1 file changed, 5 insertions(+), 32 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index bae7c0f..5d0a75e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1489,27 +1489,6 @@ static struct s5p_mfc_variant mfc_drvdata_v8 = {
.fw_name[0] = "s5p-mfc-v8.fw",
 };
 
-static const struct platform_device_id mfc_driver_ids[] = {
-   {
-   .name = "s5p-mfc",
-   .driver_data = (unsigned long)_drvdata_v5,
-   }, {
-   .name = "s5p-mfc-v5",
-   .driver_data = (unsigned long)_drvdata_v5,
-   }, {
-   .name = "s5p-mfc-v6",
-   .driver_data = (unsigned long)_drvdata_v6,
-   }, {
-   .name = "s5p-mfc-v7",
-   .driver_data = (unsigned long)_drvdata_v7,
-   }, {
-   .name = "s5p-mfc-v8",
-   .driver_data = (unsigned long)_drvdata_v8,
-   },
-   {},
-};
-MODULE_DEVICE_TABLE(platform, mfc_driver_ids);
-
 static const struct of_device_id exynos_mfc_match[] = {
{
.compatible = "samsung,mfc-v5",
@@ -1531,24 +1510,18 @@ MODULE_DEVICE_TABLE(of, exynos_mfc_match);
 static void *mfc_get_drv_data(struct platform_device *pdev)
 {
struct s5p_mfc_variant *driver_data = NULL;
+   const struct of_device_id *match;
+
+   match = of_match_node(exynos_mfc_match, pdev->dev.of_node);
+   if (match)
+   driver_data = (struct s5p_mfc_variant *)match->data;
 
-   if (pdev->dev.of_node) {
-   const struct of_device_id *match;
-   match = of_match_node(exynos_mfc_match,
-   pdev->dev.of_node);
-   if (match)
-   driver_data = (struct s5p_mfc_variant *)match->data;
-   } else {
-   driver_data = (struct s5p_mfc_variant *)
-   platform_get_device_id(pdev)->driver_data;
-   }
return driver_data;
 }
 
 static struct platform_driver s5p_mfc_driver = {
.probe  = s5p_mfc_probe,
.remove = s5p_mfc_remove,
-   .id_table   = mfc_driver_ids,
.driver = {
.name   = S5P_MFC_NAME,
.pm = _mfc_pm_ops,
-- 
1.9.2

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

[PATCH 1/4] media: exynos-gsc: remove non-device-tree init code

[Marek Szyprowski]

Exynos platform has been fully converted to device tree, so old platform
device based init data can be now removed.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 33 +---
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 -
 2 files changed, 6 insertions(+), 28 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4f90be4..1b744a6 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -967,15 +967,6 @@ static struct gsc_driverdata gsc_v_100_drvdata = {
.lclk_frequency = 26600UL,
 };
 
-static const struct platform_device_id gsc_driver_ids[] = {
-   {
-   .name   = "exynos-gsc",
-   .driver_data= (unsigned long)_v_100_drvdata,
-   },
-   {},
-};
-MODULE_DEVICE_TABLE(platform, gsc_driver_ids);
-
 static const struct of_device_id exynos_gsc_match[] = {
{
.compatible = "samsung,exynos5-gsc",
@@ -988,17 +979,11 @@ MODULE_DEVICE_TABLE(of, exynos_gsc_match);
 static void *gsc_get_drv_data(struct platform_device *pdev)
 {
struct gsc_driverdata *driver_data = NULL;
+   const struct of_device_id *match;
 
-   if (pdev->dev.of_node) {
-   const struct of_device_id *match;
-   match = of_match_node(exynos_gsc_match,
-   pdev->dev.of_node);
-   if (match)
-   driver_data = (struct gsc_driverdata *)match->data;
-   } else {
-   driver_data = (struct gsc_driverdata *)
-   platform_get_device_id(pdev)->driver_data;
-   }
+   match = of_match_node(exynos_gsc_match, pdev->dev.of_node);
+   if (match)
+   driver_data = (struct gsc_driverdata *)match->data;
 
return driver_data;
 }
@@ -1084,19 +1069,14 @@ static int gsc_probe(struct platform_device *pdev)
if (!gsc)
return -ENOMEM;
 
-   if (dev->of_node)
-   gsc->id = of_alias_get_id(pdev->dev.of_node, "gsc");
-   else
-   gsc->id = pdev->id;
-
-   if (gsc->id >= drv_data->num_entities) {
+   gsc->id = of_alias_get_id(pdev->dev.of_node, "gsc");
+   if (gsc->id >= drv_data->num_entities || gsc->id < 0) {
dev_err(dev, "Invalid platform device id: %d\n", gsc->id);
return -EINVAL;
}
 
gsc->variant = drv_data->variant[gsc->id];
gsc->pdev = pdev;
-   gsc->pdata = dev->platform_data;
 
init_waitqueue_head(>irq_queue);
spin_lock_init(>slock);
@@ -1254,7 +1234,6 @@ static const struct dev_pm_ops gsc_pm_ops = {
 static struct platform_driver gsc_driver = {
.probe  = gsc_probe,
.remove = gsc_remove,
-   .id_table   = gsc_driver_ids,
.driver = {
.name   = GSC_MODULE_NAME,
.pm = _pm_ops,
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
b/drivers/media/platform/exynos-gsc/gsc-core.h
index e93a233..ec4000c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -340,7 +340,6 @@ struct gsc_dev {
void __iomem*regs;
wait_queue_head_t   irq_queue;
struct gsc_m2m_device   m2m;
-   struct exynos_platform_gscaler  *pdata;
unsigned long   state;
struct vb2_alloc_ctx*alloc_ctx;
struct video_device vdev;
-- 
1.9.2

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

[PATCH 2/4] media: s5p-g2d: remove non-device-tree init code

[Marek Szyprowski]

Exynos and Samsung S5P platforms has been fully converted to device
tree, so old platform device based init data can be now removed.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-g2d/g2d.c | 27 +--
 drivers/media/platform/s5p-g2d/g2d.h |  5 -
 2 files changed, 5 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/s5p-g2d/g2d.c 
b/drivers/media/platform/s5p-g2d/g2d.c
index 31f6c23..be411a9 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -720,16 +720,12 @@ static int g2d_probe(struct platform_device *pdev)
 
def_frame.stride = (def_frame.width * def_frame.fmt->depth) >> 3;
 
-   if (!pdev->dev.of_node) {
-   dev->variant = g2d_get_drv_data(pdev);
-   } else {
-   of_id = of_match_node(exynos_g2d_match, pdev->dev.of_node);
-   if (!of_id) {
-   ret = -ENODEV;
-   goto unreg_video_dev;
-   }
-   dev->variant = (struct g2d_variant *)of_id->data;
+   of_id = of_match_node(exynos_g2d_match, pdev->dev.of_node);
+   if (!of_id) {
+   ret = -ENODEV;
+   goto unreg_video_dev;
}
+   dev->variant = (struct g2d_variant *)of_id->data;
 
return 0;
 
@@ -789,22 +785,9 @@ static const struct of_device_id exynos_g2d_match[] = {
 };
 MODULE_DEVICE_TABLE(of, exynos_g2d_match);
 
-static const struct platform_device_id g2d_driver_ids[] = {
-   {
-   .name = "s5p-g2d",
-   .driver_data = (unsigned long)_drvdata_v3x,
-   }, {
-   .name = "s5p-g2d-v4x",
-   .driver_data = (unsigned long)_drvdata_v4x,
-   },
-   {},
-};
-MODULE_DEVICE_TABLE(platform, g2d_driver_ids);
-
 static struct platform_driver g2d_pdrv = {
.probe  = g2d_probe,
.remove = g2d_remove,
-   .id_table   = g2d_driver_ids,
.driver = {
.name = G2D_NAME,
.of_match_table = exynos_g2d_match,
diff --git a/drivers/media/platform/s5p-g2d/g2d.h 
b/drivers/media/platform/s5p-g2d/g2d.h
index b0e52ab..e31df54 100644
--- a/drivers/media/platform/s5p-g2d/g2d.h
+++ b/drivers/media/platform/s5p-g2d/g2d.h
@@ -89,8 +89,3 @@ void g2d_set_flip(struct g2d_dev *d, u32 r);
 void g2d_set_v41_stretch(struct g2d_dev *d,
struct g2d_frame *src, struct g2d_frame *dst);
 void g2d_set_cmd(struct g2d_dev *d, u32 c);
-
-static inline struct g2d_variant *g2d_get_drv_data(struct platform_device 
*pdev)
-{
-   return (struct g2d_variant *)platform_get_device_id(pdev)->driver_data;
-}
-- 
1.9.2

--
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 v10 0/17] Add Analogix Core Display Port Driver

[Heiko Stübner]

Hi Yakir,

Am Mittwoch, 9. Dezember 2015, 11:49:10 schrieb Yakir Yang:
> Thanks a lot for great debugging.
> 
> On 12/08/2015 11:33 PM, Heiko Stübner wrote:
> > Hi Yakir,
> > 
> > Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang:
> >> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> >> 
> >> share the same IP, so a lot of parts can be re-used. I split the common
> >> code into bridge directory, then rk3288 and exynos only need to keep
> >> some platform code. Cause I can't find the exact IP name of exynos dp
> >> controller, so I decide to name dp core driver with "analogix" which I
> >> find in rk3288 eDP TRM
> > 
> > [...]
> > 
> >> Changes in v10:
> >> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
> >> (Heiko) - Fix the wrong macro value of
> >> GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(4) -> BIT(20)
> >> - Remove the surplus "plat_data" check. (Heiko)
> >> -   switch (dp->plat_data && dp->plat_data->dev_type) {
> >> +   switch (dp->plat_data->dev_type) {
> >> 
> >> - Revert parts of Gustavo Padovan's changes in commit:
> >>drm/exynos: do not start enabling DP at bind() phase
> >>
> >>Add dp phy poweron function in bind time.
> > 
> > The hotplug issue is still present, but I think I found the cause. When
> > the first detect call happens, the display simply is still off. I just did
> > some very basic tracing [0] and it seems the display simply is not enabled
> > when it is supposed to get detected.
> 
> Aha, thanks, make a lot of sense.
> 
> > And it seems injecting a drm_panel_prepare early for _testing_ [1] really
> > did make the hotplug work on both my jerry and minnie.
> > 
> > So I guess we should somehow make sure the panel is actually powered when
> > detection is running. Although I'm not sure yet, how that should look
> > like.
> 
> Agree, panel should be powered up before DP controller start to detect
> hotplug signal.
> 
> > Intuition suggests, making drm_panel calls nestable (similar to
> > clk_prepare/unprepare, etc) and simply wrapping the detection code
> > in a prepare-unprepare calls, but I'm not sure if Thierry might have other
> > ideas ;-)
> 
> Due to the panel power status would influence the hotplug status, so I
> think we don't
> need to unprepared the panel unless in driver enter into suspend time.
> Things I want:
> 
> 1. Prepared the panel in driver *bind time*
> 2. Enable the panel in driver *bridge->enable time*
> 3. Disable the panel in driver *bridge->disable time*
> 4. Unprepared the panel in driver*suspend time *
> 5. Re-prepared the panel in driver *resume time*
6. Unprepare the panel in driver at *unbind time*

otherwise going that way looks nice.


> > Also my "log" below suggests some sort of mismatch between
> > prepare/unprepare calls, as there are a lot more of the prepare-side.
> 
> Yes, it's a typo too. I shouldn't place the panel->prepare in
> connector->get_modes,
> cause userspace would try to call get_modes once it receive the hotplug
> event, so
> there wouldn't have a match between panel prepare/unprepare.
> 
> Previously, I just want to ensure that panel should be power-up when
> driver try to
> read the EDID from panel, so for now must remove the prepare from
> get_modes time  :)
> 
> > And the locking issue also seems to be still there [2].
> 
> Hmm, I haven't meet this dead lock on my chromebook (ChromeOS + 4.4-rc3
> Kernel)
> 
> After look at the dead lock trace, I guess this dead lock would happened
> when hotplug
> event happened in bridge->disable time, not sure.  Would try to find
> more in trace log
> and try to reproduce this.

It is not an actual deadlock, but a warning that a deadlock might happen.
So you need to have LOCKDEP on. My kernels are currently running with

CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_ATOMIC_SLEEP=y

and I see this mostly when changing between X11, console and back to X11.


Heiko

> > Heiko
> > 
> > 
> > [0]
> > [2.797383] analogix_dp_reset
> > [2.800709] analogix_dp_init_hpd
> > [2.803960] analogix_dp_init_video
> > [2.807653] rockchip-drm display-subsystem: bound ff97.dp (ops
> > rockchip_dp_component_ops) [2.817176] [drm] Supports vblank timestamp
> > caching Rev 2 (21.10.2013). [2.823799] [drm] No driver support for
> > vblank timestamp query. [2.829947] analogix_dp_detect
> > [2.833015] analogix_dp_get_plug_in_status: hpd status 0
> > ...
> > [2.893425] analogix_dp_get_plug_in_status: hpd status 0
> > [2.893456] rockchip-dp ff97.dp: failed to get hpd plug status, try
> > to force hpd [2.893458] analogix_dp_force_hpd
> > [2.893464] analogix_dp_get_plug_in_status: hpd status 112
> > [2.893470] panel_simple_prepare
> > [2.952183] rockchip-dp ff97.dp: EDID data does not include any
> > extensions. [2.961727] panel_simple_get_modes
> > [3.432154] analogix_dp_detect
> > [3.432158] 

Re: [PATCH 1/2] clk: samsung: exynos5422: add missing parent GSCL block clocks

[Krzysztof Kozlowski]

W dniu 09.12.2015 o 19:14, Sylwester Nawrocki pisze:
> Adding Stephen and linux-clk at Cc.
> 
> On 09/12/15 05:49, Krzysztof Kozlowski wrote:
>> On 08.12.2015 22:46, Marek Szyprowski wrote:
 This patch adds clocks, which are required for preserving parent clock
 configuration on GSCL power domain on/off.

 Signed-off-by: Marek Szyprowski 
 ---
  drivers/clk/samsung/clk-exynos5420.c   | 8 
  include/dt-bindings/clock/exynos5420.h | 2 ++
  2 files changed, 6 insertions(+), 4 deletions(-)
>>
>> I suppose that, with ack from clock folks, this can go through samsung-soc?
> 
> I guess it makes more sense that making a stable branch with just
> this patch to be pulled into arm-soc and clk tree. I'm fine with
> applying this patch through arm-soc, but I think we also need
> Mike's or Stephen ack for this.
> 
> Acked-by: Sylwester Nawrocki 

I am fine with the branch approach (actually in such cases I make them
anyway just in case).

As you suggested I'll wait for Mike's or Stepen's acks.

BR,
Krzysztof

--
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 004/182] gpio: generic: factor into gpio_chip struct

[Liviu Dudau]

On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
> 
> Cc: a...@kernel.org
> Cc: Lee Jones 
> Cc: Alexander Shiyan 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Tony Lindgren 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Alexandre Courbot 
> Cc: Gregory Fong 
> Cc: Brian Norris 
> Cc: Florian Fainelli 
> Cc: Liviu Dudau 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Nicolas Pitre 
> Cc: Olof Johansson 
> Cc: Vladimir Zapolskiy 
> Cc: Rabin Vincent 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Linus Walleij 
> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.
> ---

[]

>  drivers/mfd/vexpress-sysreg.c   |   8 +-

[]

> diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
> index 3e628df9280c..855c0204f09a 100644
> --- a/drivers/mfd/vexpress-sysreg.c
> +++ b/drivers/mfd/vexpress-sysreg.c
> @@ -11,7 +11,7 @@
>   * Copyright (C) 2012 ARM Limited
>   */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -164,7 +164,7 @@ static int vexpress_sysreg_probe(struct platform_device 
> *pdev)
>  {
>   struct resource *mem;
>   void __iomem *base;
> - struct bgpio_chip *mmc_gpio_chip;
> + struct gpio_chip *mmc_gpio_chip;
>   int master;
>   u32 dt_hbi;
>  
> @@ -201,8 +201,8 @@ static int vexpress_sysreg_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   bgpio_init(mmc_gpio_chip, >dev, 0x4, base + SYS_MCI,
>   NULL, NULL, NULL, NULL, 0);
> - mmc_gpio_chip->gc.ngpio = 2;
> - gpiochip_add(_gpio_chip->gc);
> + mmc_gpio_chip->ngpio = 2;
> + gpiochip_add(mmc_gpio_chip);
>  
>   return mfd_add_devices(>dev, PLATFORM_DEVID_AUTO,
>   vexpress_sysreg_cells,

[]

> -- 
> 2.4.3
> 

For the drivers/mfd/vexpress-sysreg.c part:

Acked-by: Liviu Dudau 


-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
--
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 004/182] gpio: generic: factor into gpio_chip struct

[Hartley Sweeten]

On Wednesday, December 09, 2015 6:13 AM, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
>
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
>
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
>
> Cc: a...@kernel.org
> Cc: Lee Jones 
> Cc: Alexander Shiyan 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Tony Lindgren 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Alexandre Courbot 
> Cc: Gregory Fong 
> Cc: Brian Norris 
> Cc: Florian Fainelli 
> Cc: Liviu Dudau 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Nicolas Pitre 
> Cc: Olof Johansson 
> Cc: Vladimir Zapolskiy 
> Cc: Rabin Vincent 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Linus Walleij 
> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.
> ---



> drivers/gpio/gpio-ep93xx.c  |  25 +--



> diff --git a/drivers/gpio/gpio-ep93xx.c b/drivers/gpio/gpio-ep93xx.c
> index 3e3947b35c83..ad279078fed7 100644
> --- a/drivers/gpio/gpio-ep93xx.c
> +++ b/drivers/gpio/gpio-ep93xx.c
> @@ -16,10 +16,11 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> -#include 
> +#include 
> +/* FIXME: this is here for gpio_to_irq() - get rid of this! */
> +#include 
>  
>  #include 
>  #include 
> @@ -28,7 +29,7 @@
>  
>  struct ep93xx_gpio {
>   void __iomem*mmio_base;
> - struct bgpio_chip   bgc[8];
> + struct gpio_chipgc[8];
>  };
>  
>  /*
> @@ -319,26 +320,26 @@ static int ep93xx_gpio_to_irq(struct gpio_chip *chip, 
> unsigned offset)
>   return 64 + gpio;
>  }
>  
> -static int ep93xx_gpio_add_bank(struct bgpio_chip *bgc, struct device *dev,
> +static int ep93xx_gpio_add_bank(struct gpio_chip *gc, struct device *dev,
>   void __iomem *mmio_base, struct ep93xx_gpio_bank *bank)
>  {
>   void __iomem *data = mmio_base + bank->data;
>   void __iomem *dir =  mmio_base + bank->dir;
>   int err;
>  
> - err = bgpio_init(bgc, dev, 1, data, NULL, NULL, dir, NULL, 0);
> + err = bgpio_init(gc, dev, 1, data, NULL, NULL, dir, NULL, 0);
>   if (err)
>   return err;
>  
> - bgc->gc.label = bank->label;
> - bgc->gc.base = bank->base;
> + gc->label = bank->label;
> + gc->base = bank->base;
>  
>   if (bank->has_debounce) {
> - bgc->gc.set_debounce = ep93xx_gpio_set_debounce;
> - bgc->gc.to_irq = ep93xx_gpio_to_irq;
> + gc->set_debounce = ep93xx_gpio_set_debounce;
> + gc->to_irq = ep93xx_gpio_to_irq;
>   }
>  
> - return gpiochip_add(>gc);
> + return gpiochip_add_data(gc, NULL);
>  }
>  
>  static int ep93xx_gpio_probe(struct platform_device *pdev)
> @@ -358,10 +359,10 @@ static int ep93xx_gpio_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(ep93xx_gpio->mmio_base);
>  
>   for (i = 0; i < ARRAY_SIZE(ep93xx_gpio_banks); i++) {
> - struct bgpio_chip *bgc = _gpio->bgc[i];
> + struct gpio_chip *gc = _gpio->gc[i];
>   struct ep93xx_gpio_bank *bank = _gpio_banks[i];
>  
> - if (ep93xx_gpio_add_bank(bgc, >dev,
> + if (ep93xx_gpio_add_bank(gc, >dev,
>ep93xx_gpio->mmio_base, bank))
>   dev_warn(>dev, "Unable to add gpio bank %s\n",
>   bank->label);

For the drivers/gpio/gpio-ep93xx.c part:

Acked-by: H Hartley Sweeten 

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

Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Anand Moon]

Hi Chanwoo Choi,

On 9 December 2015 at 09:37, Chanwoo Choi  wrote:
> This patch-set includes the two features as following. The generic exynos bus
> frequency driver is able to support almost Exynos SoCs for bus frequency
> scaling. And the new passive governor is able to make the dependency on
> between devices for frequency/voltage scaling. I had posted the patch-set[1]
> with the similiar concept. This is is revised version for exynos bus 
> frequency.
> - Generic exynos bus frequency driver
> - New passive governor of DEVFREQ framework
>
> Depends on:
> - This patch-set is based on devfreq.git[2].
> [1] https://lkml.org/lkml/2015/1/7/872
>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
> for-rafael)
>
> Changes from v1:
> (https://lkml.org/lkml/2015/11/26/260)
> - Check whether the instance of regulator is NULL or not
>   when executing regulator_disable() because of only parent
>   devfreq device has the regulator instance. After fixing it,
>   the wake-up from suspend state is well working. (patch1)
> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>   after calling devm_clk_get() (on patch1)
> - Update the documentation to remove the description about
>   DEVFREQ-EVENT subsystem (on patch2)
> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
> - Modify the detailed correlation of buses for Exynos3250
>   on documentation (patch2)
> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
> - Add the PPMU node for exynos4412-odroidu3
> - Add the support of bus frequency for exynos4412-odroidu3
>
> Detailed descirption for patch-set:
> 1. Add generic exynos bus frequency driver
> : This patch-set adds the generic exynos bus frequency driver for AXI bus
> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
> architecture for bus between DRAM and sub-blocks in SoC.
>
>  There are the different buses according to Exynos SoC because Exynos SoC
> has the differnt sub-blocks and bus speed. In spite of this difference
> among Exynos SoCs, this driver is able to support almost Exynos SoC by adding
> unique data of each bus in the devicetree file.
>
>  In devicetree, each bus node has a bus clock, regulator, operation-point
> and devfreq-event devices which measure the utilization of each bus block.
>
> For example,
> - The bus of DMC block in exynos3250.dtsi are listed below:
>
> bus_dmc: bus_dmc {
> compatible = "samsung,exynos-bus";
> clocks = <_dmc CLK_DIV_DMC>;
> clock-names = "bus";
> operating-points-v2 = <_dmc_opp_table>;
> status = "disabled";
> };
>
> bus_dmc_opp_table: opp_table0 {
> compatible = "operating-points-v2";
> opp-shared;
>
> opp00 {
> opp-hz = /bits/ 64 <5000>;
> opp-microvolt = <80>;
> };
> opp01 {
> opp-hz = /bits/ 64 <1>;
> opp-microvolt = <80>;
> };
> opp02 {
> opp-hz = /bits/ 64 <13400>;
> opp-microvolt = <80>;
> };
> opp03 {
> opp-hz = /bits/ 64 <2>;
> opp-microvolt = <80>;
> };
> opp04 {
> opp-hz = /bits/ 64 <4>;
> opp-microvolt = <875000>;
> };
> };
>
> - Usage case to handle the frequency and voltage of bus on runtime
>   in exynos3250-rinato.dts are listed below:
>
> _dmc {
> devfreq-events = <_dmc0_3>, <_dmc1_3>;
> vdd-supply = <_reg>;  /* VDD_MIF */
> status = "okay";
> };
>
> 2. Add new passive governor of DEVFREQ framework (patch5-patch7)
> : This patch-set add the new passive governor for DEVFREQ framework.
> The existing governors (ondemand, performance and so on) are used for DVFS
> (Dynamic Voltage and Frequency Scaling) drivers. The existing governors
> are independently used for specific device driver which don't give the
> influence to other device drviers and also don't receive the effect from
> other device drivers.
>
>  The passive governor depends on operation of parent driver with existing
> governors(ondemand, performance and so on) extremely and is not able to
> decide the new frequency by oneself. According to the decided new frequency
> of parent driver with governor, the passive governor uses it to decide
> the appropriate frequency for own device driver. The passive governor
> must need the following information from device tree:
>
> For exameple,
>  There are one 

Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Krzysztof Kozlowski]

On 09.12.2015 13:07, Chanwoo Choi wrote:

(...)

>  .../devicetree/bindings/devfreq/exynos-bus.txt |  383 +++

How about adding this file to the MAINTAINERS to devfreq exynos entry?
Unfortunately, in current linux-next, I can find the entry for devfreq
exynos. However I saw patches adding such entries... aren't they merged
to linux-next?

Best regards,
Krzysztof

>  arch/arm/boot/dts/exynos3250-monk.dts  |6 +
>  arch/arm/boot/dts/exynos3250-rinato.dts|   47 +
>  arch/arm/boot/dts/exynos3250.dtsi  |  194 
>  arch/arm/boot/dts/exynos4210.dtsi  |  172 
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi|   93 +-
>  arch/arm/boot/dts/exynos4412-trats2.dts|   47 +
>  arch/arm/boot/dts/exynos4x12.dtsi  |  184 
>  drivers/devfreq/Kconfig|   37 +-
>  drivers/devfreq/Makefile   |2 +
>  drivers/devfreq/devfreq.c  |  120 ++-
>  drivers/devfreq/exynos/Makefile|3 +-
>  drivers/devfreq/exynos/exynos-bus.c|  549 ++
>  drivers/devfreq/exynos/exynos4_bus.c   | 1055 
> 
>  drivers/devfreq/exynos/exynos4_bus.h   |  110 --
>  drivers/devfreq/exynos/exynos5_bus.c   |  431 
>  drivers/devfreq/exynos/exynos_ppmu.c   |  119 ---
>  drivers/devfreq/exynos/exynos_ppmu.h   |   86 --
>  drivers/devfreq/governor.h |7 +
>  drivers/devfreq/governor_passive.c |  109 ++
>  drivers/devfreq/governor_performance.c |1 +
>  drivers/devfreq/governor_powersave.c   |1 +
>  drivers/devfreq/governor_simpleondemand.c  |1 +
>  drivers/devfreq/governor_userspace.c   |1 +
>  include/linux/devfreq.h|   28 +
>  25 files changed, 1958 insertions(+), 1828 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
>  delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
>  delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
>  delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h
>  create mode 100644 drivers/devfreq/governor_passive.c
> 

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

Re: [PATCH v2 04/19] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk

[Chanwoo Choi]

On 2015년 12월 10일 09:53, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
>> This patch adds the DMC (Dynamic Memory Controller) bus frequency node
>> which includes the devfreq-events and regulator properties. The bus
>> frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
>> with ondemand governor.
>>
>> The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
>> on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
>> the DMC block.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos3250-monk.dts   | 6 ++
>>  arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
>> b/arch/arm/boot/dts/exynos3250-monk.dts
>> index 443a35085846..d982586a6533 100644
>> --- a/arch/arm/boot/dts/exynos3250-monk.dts
>> +++ b/arch/arm/boot/dts/exynos3250-monk.dts
>> @@ -498,6 +498,12 @@
>>  };
>>  };
>>  
>> +_dmc {
>> +devfreq-events = <_dmc0_3>, <_dmc1_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>>   {
>>  clock-frequency = <2400>;
>>  };
>> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
>> b/arch/arm/boot/dts/exynos3250-rinato.dts
>> index 3e64d5dcdd60..61477943015b 100644
>> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
>> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
>> @@ -675,6 +675,12 @@
>>  };
>>  };
>>  
>> +_dmc {
>> +devfreq-events = <_dmc0_3>, <_dmc1_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
> 
> I would prefer to put this in alphabetical order... which could be
> tricky because the nodes are not entirely sorted. Maybe after the ""
> node?

OK. I'll move it.

> 
> Anyway the change looks good:
> 
> Reviewed-by: Krzysztof Kozlowski 

Thanks for your review.

Regards,
Chanwoo Choi

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

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Chanwoo Choi]

On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
>> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 
>> SoC.
>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
>> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
>> block.
>>
>> Following list specifies the detailed relation between the clock and DMC 
>> block:
>> - The source clock of DMC block : div_dmc
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> index 2f30d632f1cc..7214c5e42150 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -687,6 +687,40 @@
>>  clock-names = "ppmu";
>>  status = "disabled";
>>  };
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <_dmc CLK_DIV_DMC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_dmc_opp_table: opp_table1 {
> 
> This is the firsy opp_table, right? So:
> s/opp_table1/opp_table0/

Right. It is first opp_table in exynos3250.dtsi.
But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.

> 
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <5000>;
>> +opp-microvolt = <80>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <80>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <80>;
> 
> Why 134, not 133 MHz?

When I used the 13300, the source clock is changed to 100Mhz instead of 
133MHz.
I add following test result on exynos3250-rinato board.

Case1.
When I use the 134 MHz, the source clock is changed to 133MHz
: exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) (real: 
13334)

Case2.
When I use the 133 MHz, the source clock is changed to 100MHz
: exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) (real: 
1)

> 
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <80>;
> 
> Shouldn't this be 825 mV, not 800? I think we used previously that value
> for our devices.

OK. I'll modify it.

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

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 10.12.2015 10:09, Chanwoo Choi wrote:
> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 
>>> SoC.
>>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
>>> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
>>> block.
>>>
>>> Following list specifies the detailed relation between the clock and DMC 
>>> block:
>>> - The source clock of DMC block : div_dmc
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>>  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>>>  1 file changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>> index 2f30d632f1cc..7214c5e42150 100644
>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>> @@ -687,6 +687,40 @@
>>> clock-names = "ppmu";
>>> status = "disabled";
>>> };
>>> +
>>> +   bus_dmc: bus_dmc {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = <_dmc CLK_DIV_DMC>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_dmc_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   bus_dmc_opp_table: opp_table1 {
>>
>> This is the firsy opp_table, right? So:
>> s/opp_table1/opp_table0/
> 
> Right. It is first opp_table in exynos3250.dtsi.
> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.

Ok

> 
>>
>>> +   compatible = "operating-points-v2";
>>> +   opp-shared;
>>> +
>>> +   opp00 {
>>> +   opp-hz = /bits/ 64 <5000>;
>>> +   opp-microvolt = <80>;
>>> +   };
>>> +   opp01 {
>>> +   opp-hz = /bits/ 64 <1>;
>>> +   opp-microvolt = <80>;
>>> +   };
>>> +   opp02 {
>>> +   opp-hz = /bits/ 64 <13400>;
>>> +   opp-microvolt = <80>;
>>
>> Why 134, not 133 MHz?
> 
> When I used the 13300, the source clock is changed to 100Mhz instead of 
> 133MHz.
> I add following test result on exynos3250-rinato board.
> 
> Case1.
> When I use the 134 MHz, the source clock is changed to 133MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) (real: 
> 13334)
> 
> Case2.
> When I use the 133 MHz, the source clock is changed to 100MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) (real: 
> 1)

Now I remember that issue. You could use here directly 13334 but
that also would look a little bit weird... so 134 is ok for me. Could
just add a comment that desired frequency is actually "133 MHz"?

Best regards,
Krzysztof

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

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Chanwoo Choi]

On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
> On 10.12.2015 10:09, Chanwoo Choi wrote:
>> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>>> On 09.12.2015 13:07, Chanwoo Choi wrote:
 This patch adds the DMC (Dynamic Memory Controller) bus node for 
 Exynos3250 SoC.
 The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
 SDRAM devices. The bus includes the OPP tables and the source clock for DMC
 block.

 Following list specifies the detailed relation between the clock and DMC 
 block:
 - The source clock of DMC block : div_dmc

 Signed-off-by: Chanwoo Choi 
 ---
  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
  1 file changed, 34 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
 b/arch/arm/boot/dts/exynos3250.dtsi
 index 2f30d632f1cc..7214c5e42150 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -687,6 +687,40 @@
clock-names = "ppmu";
status = "disabled";
};
 +
 +  bus_dmc: bus_dmc {
 +  compatible = "samsung,exynos-bus";
 +  clocks = <_dmc CLK_DIV_DMC>;
 +  clock-names = "bus";
 +  operating-points-v2 = <_dmc_opp_table>;
 +  status = "disabled";
 +  };
 +
 +  bus_dmc_opp_table: opp_table1 {
>>>
>>> This is the firsy opp_table, right? So:
>>> s/opp_table1/opp_table0/
>>
>> Right. It is first opp_table in exynos3250.dtsi.
>> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
>> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.
> 
> Ok
> 
>>
>>>
 +  compatible = "operating-points-v2";
 +  opp-shared;
 +
 +  opp00 {
 +  opp-hz = /bits/ 64 <5000>;
 +  opp-microvolt = <80>;
 +  };
 +  opp01 {
 +  opp-hz = /bits/ 64 <1>;
 +  opp-microvolt = <80>;
 +  };
 +  opp02 {
 +  opp-hz = /bits/ 64 <13400>;
 +  opp-microvolt = <80>;
>>>
>>> Why 134, not 133 MHz?
>>
>> When I used the 13300, the source clock is changed to 100Mhz instead of 
>> 133MHz.
>> I add following test result on exynos3250-rinato board.
>>
>> Case1.
>> When I use the 134 MHz, the source clock is changed to 133MHz
>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) (real: 
>> 13334)
>>
>> Case2.
>> When I use the 133 MHz, the source clock is changed to 100MHz
>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) (real: 
>> 1)
> 
> Now I remember that issue. You could use here directly 13334 but
> that also would look a little bit weird... so 134 is ok for me. Could
> just add a comment that desired frequency is actually "133 MHz"?

Do you prefer among following example?

Example1.
opp02 {
/* The desired frequency is 133MHz because
 * clock change has the dependency on clock driver.
 * When set rate as 134MHz, the clock driver would
 * change the 133MHz actually instead of 134MHz.
 */
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};

Example2.
opp02 {
opp-hz = /bits/ 64 <13334>;
opp-microvolt = <80>;
};

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

Re: [PATCH v2 12/19] ARM: dts: Add bus nodes using VDD_INT for Exynos3250

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
> Exynos3250 has following AXI buses to translate data between
> DRAM and sub-blocks.
> 
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK400 clock for MCUISP
> - ACLK266 clock for ISP
> - ACLK200 clock for FSYS
> - ACLK160 clock for LCD0
> - ACLK100 clock for PERIL
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 160 
> ++
>  1 file changed, 160 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 7214c5e42150..46dee1951ec1 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -721,6 +721,166 @@
>   opp-microvolt = <875000>;
>   };
>   };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_lcd0: bus_lcd0 {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_160>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_fsys: bus_fsys {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_200>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mcuisp: bus_mcuisp {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_400_MCUISP>;
> + clock-names = "bus";
> + operating-points-v2 = <_mcuisp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_isp: bus_isp {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_266>;
> + clock-names = "bus";
> + operating-points-v2 = <_isp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_peril: bus_peril {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACLK_100>;
> + clock-names = "bus";
> + operating-points-v2 = <_peril_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_SCLK_MFC>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_leftbus_opp_table: opp_table2 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <8000>;
> + opp-microvolt = <90>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <100>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <100>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_mcuisp_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Chanwoo Choi]

On 2015년 12월 10일 11:04, Krzysztof Kozlowski wrote:
> On 10.12.2015 11:00, Chanwoo Choi wrote:
>> On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
>>> On 10.12.2015 10:09, Chanwoo Choi wrote:
 On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
>> This patch adds the DMC (Dynamic Memory Controller) bus node for 
>> Exynos3250 SoC.
>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC 
>> standard
>> SDRAM devices. The bus includes the OPP tables and the source clock for 
>> DMC
>> block.
>>
>> Following list specifies the detailed relation between the clock and DMC 
>> block:
>> - The source clock of DMC block : div_dmc
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos3250.dtsi | 34 
>> ++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> index 2f30d632f1cc..7214c5e42150 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -687,6 +687,40 @@
>>  clock-names = "ppmu";
>>  status = "disabled";
>>  };
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <_dmc CLK_DIV_DMC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_dmc_opp_table: opp_table1 {
>
> This is the firsy opp_table, right? So:
> s/opp_table1/opp_table0/

 Right. It is first opp_table in exynos3250.dtsi.
 But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
 So, I have the plan that support the operation-points-v2 for Exynos3250 
 CPU.
>>>
>>> Ok
>>>

>
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <5000>;
>> +opp-microvolt = <80>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <80>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <80>;
>
> Why 134, not 133 MHz?

 When I used the 13300, the source clock is changed to 100Mhz instead 
 of 133MHz.
 I add following test result on exynos3250-rinato board.

 Case1.
 When I use the 134 MHz, the source clock is changed to 133MHz
 : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) 
 (real: 13334)

 Case2.
 When I use the 133 MHz, the source clock is changed to 100MHz
 : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) 
 (real: 1)
>>>
>>> Now I remember that issue. You could use here directly 13334 but
>>> that also would look a little bit weird... so 134 is ok for me. Could
>>> just add a comment that desired frequency is actually "133 MHz"?
>>
>> Do you prefer among following example?
>>
>> Example1.
>>  opp02 {
>>  /* The desired frequency is 133MHz because
>>   * clock change has the dependency on clock driver.
>>   * When set rate as 134MHz, the clock driver would
>>   * change the 133MHz actually instead of 134MHz.
>>   */
>>  opp-hz = /bits/ 64 <13400>;
>>  opp-microvolt = <80>;
>>  };
>>
>> Example2.
>>  opp02 {
>>  opp-hz = /bits/ 64 <13334>;
>>  opp-microvolt = <80>;
>>  };
> 
> I would prefer the second one (13334) but I don't have strong
> feelings about it.

If you ok, I want to maintain the original approach as following:

opp02 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};

Best Regards,
Chanwoo Choi

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

Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Chanwoo Choi]

On 2015년 12월 10일 10:22, Krzysztof Kozlowski wrote:
> On 10.12.2015 09:57, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>
>> (...)
>>
>>>  .../devicetree/bindings/devfreq/exynos-bus.txt |  383 +++
>>
>> How about adding this file to the MAINTAINERS to devfreq exynos entry?

OK. I'll add new entry for 'devfreq exynos' as following:
 
+SAMSUNG BUS DEVICE FREQUENCY SUPPORT
+M: Chanwoo Choi 
+L: linux...@vger.kernel.org
+L: linux-samsung-soc@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
+S: Supported
+F: drivers/devfreq/exynos/exynos-bus.c
+F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt

>> Unfortunately, in current linux-next, I can find the entry for devfreq
> 
> D'oh! I meant:^ I cannot find the entry for...
> 
> BR,
> Krzysztof
> 
>> exynos. However I saw patches adding such entries... aren't they merged
>> to linux-next?

Yes, it is not merged to linux-next because any git repository
don't apply this patchset. To merge the devfreq patchset to linux-next,
devfreq maintainer should send the request mail to Stephen Rothwell.

[snip]

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

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 10.12.2015 11:17, Chanwoo Choi wrote:
> On 2015년 12월 10일 11:04, Krzysztof Kozlowski wrote:
>> On 10.12.2015 11:00, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
 On 10.12.2015 10:09, Chanwoo Choi wrote:
> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>> This patch adds the DMC (Dynamic Memory Controller) bus node for 
>>> Exynos3250 SoC.
>>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC 
>>> standard
>>> SDRAM devices. The bus includes the OPP tables and the source clock for 
>>> DMC
>>> block.
>>>
>>> Following list specifies the detailed relation between the clock and 
>>> DMC block:
>>> - The source clock of DMC block : div_dmc
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>>  arch/arm/boot/dts/exynos3250.dtsi | 34 
>>> ++
>>>  1 file changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>> index 2f30d632f1cc..7214c5e42150 100644
>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>> @@ -687,6 +687,40 @@
>>> clock-names = "ppmu";
>>> status = "disabled";
>>> };
>>> +
>>> +   bus_dmc: bus_dmc {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = <_dmc CLK_DIV_DMC>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_dmc_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   bus_dmc_opp_table: opp_table1 {
>>
>> This is the firsy opp_table, right? So:
>> s/opp_table1/opp_table0/
>
> Right. It is first opp_table in exynos3250.dtsi.
> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
> So, I have the plan that support the operation-points-v2 for Exynos3250 
> CPU.

 Ok

>
>>
>>> +   compatible = "operating-points-v2";
>>> +   opp-shared;
>>> +
>>> +   opp00 {
>>> +   opp-hz = /bits/ 64 <5000>;
>>> +   opp-microvolt = <80>;
>>> +   };
>>> +   opp01 {
>>> +   opp-hz = /bits/ 64 <1>;
>>> +   opp-microvolt = <80>;
>>> +   };
>>> +   opp02 {
>>> +   opp-hz = /bits/ 64 <13400>;
>>> +   opp-microvolt = <80>;
>>
>> Why 134, not 133 MHz?
>
> When I used the 13300, the source clock is changed to 100Mhz instead 
> of 133MHz.
> I add following test result on exynos3250-rinato board.
>
> Case1.
> When I use the 134 MHz, the source clock is changed to 133MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) 
> (real: 13334)
>
> Case2.
> When I use the 133 MHz, the source clock is changed to 100MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) 
> (real: 1)

 Now I remember that issue. You could use here directly 13334 but
 that also would look a little bit weird... so 134 is ok for me. Could
 just add a comment that desired frequency is actually "133 MHz"?
>>>
>>> Do you prefer among following example?
>>>
>>> Example1.
>>> opp02 {
>>> /* The desired frequency is 133MHz because
>>>  * clock change has the dependency on clock driver.
>>>  * When set rate as 134MHz, the clock driver would
>>>  * change the 133MHz actually instead of 134MHz.
>>>  */
>>> opp-hz = /bits/ 64 <13400>;
>>> opp-microvolt = <80>;
>>> };
>>>
>>> Example2.
>>> opp02 {
>>> opp-hz = /bits/ 64 <13334>;
>>> opp-microvolt = <80>;
>>> };
>>
>> I would prefer the second one (13334) but I don't have strong
>> feelings about it.
> 
> If you ok, I want to maintain the original approach as following:
> 
>   opp02 {
>   opp-hz = /bits/ 64 <13400>;
>   opp-microvolt = <80>;
>   };

OK

Best regards,
Krzysztof

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

Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Chanwoo Choi]

On 2015년 12월 10일 10:25, Krzysztof Kozlowski wrote:
> On 10.12.2015 09:49, Chanwoo Choi wrote:
>> Hi,
>>
> (...)
> 
>>>
 +
 +  bus_dmc: bus_dmc {
 +  compatible = "samsung,exynos-bus";
 +  clocks = <_dmc CLK_DIV_DMC>;
 +  clock-names = "bus";
 +  operating-points-v2 = <_dmc_opp_table>;
 +  status = "disabled";
 +  };
 +
 +  bus_dmc_opp_table: opp_table0 {
 +  compatible = "operating-points-v2";
 +  opp-shared;
 +
 +  opp00 {
>>>
>>> Maybe use convention with frequency, like:
>>> opp@5000
>>> This also used in opp.txt examples.
>>
>> In the Documentations/devicetree/bindings/opp/opp.txt,
>> the example uses the 'opp@0x'. I check the opp.txt of Linux 4.4-rc4.
> 
> Yes, it was changed by Viresh in "PM / OPP: Rename OPP nodes as
> opp@". You can find the most actual bindings in linux-next.

OK. I'll.

Best Regards,
Chanwoo Choi

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

Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Michael Welling]

On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
...
> @@ -55,16 +54,16 @@ static int moxart_gpio_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - bgc->gc.label = "moxart-gpio";
> - bgc->gc.request = gpiochip_generic_request;
> - bgc->gc.free = gpiochip_generic_free;
> - bgc->data = bgc->read_reg(bgc->reg_set);
> - bgc->gc.base = 0;
> - bgc->gc.ngpio = 32;
> - bgc->gc.parent = dev;
> - bgc->gc.owner = THIS_MODULE;
> + gc->label = "moxart-gpio";
> + gc->request = gpiochip_generic_request;
> + gc->free = gpiochip_generic_free;
> + gc->bgpio_data = bgc->read_reg(bgc->reg_set);
> + gc->base = 0;
> + gc->ngpio = 32;
> + gc->parent = dev;
> + gc->owner = THIS_MODULE;
>  
> - ret = gpiochip_add(>gc);
> + ret = gpiochip_add_data(gc, NULL);
>   if (ret) {

gpiochip_add is still mentioned in the dev_err below.

>   dev_err(dev, "%s: gpiochip_add failed\n",
>   dev->of_node->full_name);
...

> @@ -226,14 +225,14 @@ static int sdv_gpio_probe(struct pci_dev *pdev,
>   writel(mux_val, sd->gpio_pub_base + GPMUXCTL);
>   }
>  
> - ret = bgpio_init(>bgpio, >dev, 4,
> + ret = bgpio_init(>chip, >dev, 4,
>   sd->gpio_pub_base + GPINR, sd->gpio_pub_base + GPOUTR,
>   NULL, sd->gpio_pub_base + GPOER, NULL, 0);
>   if (ret)
>   goto unmap;
> - sd->bgpio.gc.ngpio = SDV_NUM_PUB_GPIOS;
> + sd->chip.ngpio = SDV_NUM_PUB_GPIOS;
>  
> - ret = gpiochip_add(>bgpio.gc);
> + ret = gpiochip_add_data(>chip, sd);
>   if (ret < 0) {

Also still mentioned here in the dev_err.

>   dev_err(>dev, "gpiochip_add() failed.\n");
>   goto unmap;
...
 
> @@ -201,8 +201,8 @@ static int vexpress_sysreg_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   bgpio_init(mmc_gpio_chip, >dev, 0x4, base + SYS_MCI,
>   NULL, NULL, NULL, NULL, 0);

Was going to complain about this one not switching to _data but it was
addressed in a follow up patch.

> - mmc_gpio_chip->gc.ngpio = 2;
> - gpiochip_add(_gpio_chip->gc);
> + mmc_gpio_chip->ngpio = 2;
> + gpiochip_add(mmc_gpio_chip);
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/19] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk

[Krzysztof Kozlowski]

On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus frequency node
> which includes the devfreq-events and regulator properties. The bus
> frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
> with ondemand governor.
> 
> The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
> on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
> the DMC block.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos3250-monk.dts   | 6 ++
>  arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
> b/arch/arm/boot/dts/exynos3250-monk.dts
> index 443a35085846..d982586a6533 100644
> --- a/arch/arm/boot/dts/exynos3250-monk.dts
> +++ b/arch/arm/boot/dts/exynos3250-monk.dts
> @@ -498,6 +498,12 @@
>   };
>  };
>  
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
>   {
>   clock-frequency = <2400>;
>  };
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 3e64d5dcdd60..61477943015b 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -675,6 +675,12 @@
>   };
>  };
>  
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};

I would prefer to put this in alphabetical order... which could be
tricky because the nodes are not entirely sorted. Maybe after the ""
node?

Anyway the change looks good:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


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

Re: [PATCH v2 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor

[Chanwoo Choi]

On 2015년 12월 10일 10:31, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch updates the documentation for passive bus devices and adds the
>> detailed example of Exynos3250.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  .../devicetree/bindings/devfreq/exynos-bus.txt | 244 
>> -
>>  1 file changed, 241 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
>> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> index 54a1f9c46c88..c4fdc70f8eac 100644
>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -13,18 +13,23 @@ SoC has the different sub-blocks. So, this difference 
>> should be specified
>>  in devicetree file instead of each device driver. In result, this driver
>>  is able to support the bus frequency for all Exynos SoCs.
>>  
>> -Required properties for bus device:
>> +Required properties for all bus devices:
>>  - compatible: Should be "samsung,exynos-bus".
>>  - clock-names : the name of clock used by the bus, "bus".
>>  - clocks : phandles for clock specified in "clock-names" property.
>>  - #clock-cells: should be 1.
>>  - operating-points-v2: the OPP table including frequency/voltage information
>>to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
>> +
>> +Required properties for only parent bus device:
> 
> Maybe:
> "Required properties only for parent bus devices:"

OK. I'll modify it.

> 
> In this binding documentation file the idea of "parent" is not
> explained. I now it is related to passive devfreq governor but looking
> at the binding itself it is a new idea, not covered here.

OK. I'll add the detailed description of 'parent' and
correlation between 'parent' and 'passive' device.

> 
>>  - vdd-supply: the regulator to provide the buses with the voltage.
>>  - devfreq-events: the devfreq-event device to monitor the curret utilization
>>of buses.
>>  
>> -Optional properties for bus device:
>> +Required properties for only passive bus device:
> 
> "Required properties only for passive bus devices:"

OK. I'll modify it.

> 
>> +- devfreq: the parent bus device.
>> +
>> +Optional properties for only parent bus device:
>>  - exynos,saturation-ratio: the percentage value which is used to calibrate
>> the performance count againt total cycle count.
>>  
>> @@ -33,7 +38,20 @@ Example1:
>>  power line (regulator). The MIF (Memory Interface) AXI bus is used to
>>  transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
>>  
>> -- power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
>> +- MIF (Memory Interface) block
>> +: VDD_MIF |--- DMC (Dynamic Memory Controller)
>> +
>> +- INT (Internal) block
>> +: VDD_INT |--- LEFTBUS (parent device)
>> +  |--- PERIL
>> +  |--- MFC
>> +  |--- G3D
>> +  |--- RIGHTBUS
>> +  |--- FSYS
>> +  |--- LCD0
>> +  |--- PERIR
>> +  |--- ISP
>> +  |--- CAM
>>  
>>  - MIF bus's frequency/voltage table
>>  ---
>> @@ -46,6 +64,24 @@ Example1:
>>  |L5| 40 |875000   |
>>  ---
>>  
>> +- INT bus's frequency/voltage table
>> +--
>> +|Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL  ||VDD_INT |
>> +| name|   |LCD0|   |   |   |||
>> +| |   |FSYS|   |   |   |||
>> +| |   |MFC |   |   |   |||
>> +--
>> +|Mode |*parent|passive |passive|passive|passive|||
>> +--
>> +|Lv   |Frequency   ||Voltage |
>> +--
>> +|L1   |5  |5   |5  |5  |5  ||90  |
>> +|L2   |8  |8   |8  |8  |8  ||90  |
>> +|L3   |10 |10  |10 |10 |10 ||100 |
>> +|L4   |134000 |134000  |20 |20 |   ||100 |
>> +|L5   |20 |20  |40 |30 |   ||100 |
>> +--
>> +
>>  Example2 :
>>  The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>>  are listed below:
>> @@ -84,6 +120,167 @@ Example2 :
>>  };
>>  };
>>  
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +

Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Chanwoo Choi]

Hi,

On 2015년 12월 10일 09:39, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
>> This patch adds the documentation for generic exynos bus frequency
>> driver.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  .../devicetree/bindings/devfreq/exynos-bus.txt | 94 
>> ++
>>  1 file changed, 94 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
>> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> new file mode 100644
>> index ..54a1f9c46c88
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -0,0 +1,94 @@
>> +* Generic Exynos Bus frequency device
>> +
>> +The Samsung Exynos SoC have many buses for data transfer between DRAM
>> +and sub-blocks in SoC. Almost Exynos SoC have the common architecture
>> +for buses. Generally, the each bus of Exynos SoC includes the source clock
>> +and power line and then is able to change the clock according to the usage
>> +of each buses on runtime. When gathering the usage of each buses on runtime,
>> +thie driver uses the PPMU (Platform Performance Monitoring Unit) which
> 
> s/thie/the/

OK.

> 
>> +is able to measure the current load of sub-blocks.
>> +
>> +There are a little different composition among Exynos SoC because each 
>> Exynos
>> +SoC has the different sub-blocks. So, this difference should be specified
>> +in devicetree file instead of each device driver. In result, this driver
>> +is able to support the bus frequency for all Exynos SoCs.
>> +
>> +Required properties for bus device:
>> +- compatible: Should be "samsung,exynos-bus".
>> +- clock-names : the name of clock used by the bus, "bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- #clock-cells: should be 1.
> 
> This is a clock consumer, right? So the clock-cells is not valid here.

You're right. I'll remove '#clock-cells'.

> 
>> +- operating-points-v2: the OPP table including frequency/voltage information
>> +  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
>> +- vdd-supply: the regulator to provide the buses with the voltage.
>> +- devfreq-events: the devfreq-event device to monitor the curret utilization
> 
> s/curret/current/
> 
>> +  of buses.
>> +
>> +Optional properties for bus device:
>> +- exynos,saturation-ratio: the percentage value which is used to calibrate
>> +   the performance count againt total cycle count.
> 
> s/againt/against/

OK.

> 
>> +
>> +Example1:
>> +Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
>> +power line (regulator). The MIF (Memory Interface) AXI bus is used to
>> +transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
>> +
>> +- power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
>> +
>> +- MIF bus's frequency/voltage table
>> +---
>> +|Lv| Freq   | Voltage |
>> +---
>> +|L1| 5  |80   |
>> +|L2| 10 |80   |
>> +|L3| 134000 |80   |
>> +|L4| 20 |80   |
>> +|L5| 40 |875000   |
>> +---
>> +
>> +Example2 :
>> +The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>> +are listed below:
> 
> s/are/is/ (one bus is listed)

OK.

> 
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <_dmc CLK_DIV_DMC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_dmc_opp_table: opp_table0 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
> 
> Maybe use convention with frequency, like:
>   opp@5000
> This also used in opp.txt examples.

In the Documentations/devicetree/bindings/opp/opp.txt,
the example uses the 'opp@0x'. I check the opp.txt of Linux 4.4-rc4.

> 
> 
>> +opp-hz = /bits/ 64 <5000>;
>> +opp-microvolt = <80>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <80>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <80>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <80>;
>> +};
>> +opp04 {
>> +opp-hz = /bits/ 64 <4>;
>> +opp-microvolt = <875000>;
>> +};
>> +};
>> +
>> +Usage case to handle the frequency and voltage of bus on runtime
>> +in exynos3250-rinato.dts are listed below:
> 
> s/are/is/

OK.

> 
>> +
>> +

Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Krzysztof Kozlowski]

On 10.12.2015 09:57, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
> 
> (...)
> 
>>  .../devicetree/bindings/devfreq/exynos-bus.txt |  383 +++
> 
> How about adding this file to the MAINTAINERS to devfreq exynos entry?
> Unfortunately, in current linux-next, I can find the entry for devfreq

D'oh! I meant:^ I cannot find the entry for...

BR,
Krzysztof

> exynos. However I saw patches adding such entries... aren't they merged
> to linux-next?
> 
> Best regards,
> Krzysztof
> 
>>  arch/arm/boot/dts/exynos3250-monk.dts  |6 +
>>  arch/arm/boot/dts/exynos3250-rinato.dts|   47 +
>>  arch/arm/boot/dts/exynos3250.dtsi  |  194 
>>  arch/arm/boot/dts/exynos4210.dtsi  |  172 
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi|   93 +-
>>  arch/arm/boot/dts/exynos4412-trats2.dts|   47 +
>>  arch/arm/boot/dts/exynos4x12.dtsi  |  184 
>>  drivers/devfreq/Kconfig|   37 +-
>>  drivers/devfreq/Makefile   |2 +
>>  drivers/devfreq/devfreq.c  |  120 ++-
>>  drivers/devfreq/exynos/Makefile|3 +-
>>  drivers/devfreq/exynos/exynos-bus.c|  549 ++
>>  drivers/devfreq/exynos/exynos4_bus.c   | 1055 
>> 
>>  drivers/devfreq/exynos/exynos4_bus.h   |  110 --
>>  drivers/devfreq/exynos/exynos5_bus.c   |  431 
>>  drivers/devfreq/exynos/exynos_ppmu.c   |  119 ---
>>  drivers/devfreq/exynos/exynos_ppmu.h   |   86 --
>>  drivers/devfreq/governor.h |7 +
>>  drivers/devfreq/governor_passive.c |  109 ++
>>  drivers/devfreq/governor_performance.c |1 +
>>  drivers/devfreq/governor_powersave.c   |1 +
>>  drivers/devfreq/governor_simpleondemand.c  |1 +
>>  drivers/devfreq/governor_userspace.c   |1 +
>>  include/linux/devfreq.h|   28 +
>>  25 files changed, 1958 insertions(+), 1828 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
>>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
>>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
>>  delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
>>  delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
>>  delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h
>>  create mode 100644 drivers/devfreq/governor_passive.c
>>
> 
> 

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

Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Krzysztof Kozlowski]

On 09.12.2015 22:12, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
> 
> Cc: a...@kernel.org
> Cc: Lee Jones 
> Cc: Alexander Shiyan 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Tony Lindgren 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Alexandre Courbot 
> Cc: Gregory Fong 
> Cc: Brian Norris 
> Cc: Florian Fainelli 
> Cc: Liviu Dudau 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Nicolas Pitre 
> Cc: Olof Johansson 
> Cc: Vladimir Zapolskiy 
> Cc: Rabin Vincent 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Linus Walleij 
> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.
> ---
>  arch/arm/mach-clps711x/board-autcpu12.c |   2 +-
>  arch/arm/mach-clps711x/board-p720t.c|   2 +-
>  arch/arm/mach-imx/mach-mx21ads.c|   2 +-
>  arch/arm/mach-omap1/board-ams-delta.c   |   2 +-
>  arch/arm/mach-s3c64xx/mach-crag6410.c   |   2 +-

For s3c64xx:
Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH v2 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch updates the documentation for passive bus devices and adds the
> detailed example of Exynos3250.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 244 
> -
>  1 file changed, 241 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index 54a1f9c46c88..c4fdc70f8eac 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -13,18 +13,23 @@ SoC has the different sub-blocks. So, this difference 
> should be specified
>  in devicetree file instead of each device driver. In result, this driver
>  is able to support the bus frequency for all Exynos SoCs.
>  
> -Required properties for bus device:
> +Required properties for all bus devices:
>  - compatible: Should be "samsung,exynos-bus".
>  - clock-names : the name of clock used by the bus, "bus".
>  - clocks : phandles for clock specified in "clock-names" property.
>  - #clock-cells: should be 1.
>  - operating-points-v2: the OPP table including frequency/voltage information
>to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
> +
> +Required properties for only parent bus device:

Maybe:
"Required properties only for parent bus devices:"

In this binding documentation file the idea of "parent" is not
explained. I now it is related to passive devfreq governor but looking
at the binding itself it is a new idea, not covered here.

>  - vdd-supply: the regulator to provide the buses with the voltage.
>  - devfreq-events: the devfreq-event device to monitor the curret utilization
>of buses.
>  
> -Optional properties for bus device:
> +Required properties for only passive bus device:

"Required properties only for passive bus devices:"

> +- devfreq: the parent bus device.
> +
> +Optional properties for only parent bus device:
>  - exynos,saturation-ratio: the percentage value which is used to calibrate
> the performance count againt total cycle count.
>  
> @@ -33,7 +38,20 @@ Example1:
>   power line (regulator). The MIF (Memory Interface) AXI bus is used to
>   transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
>  
> - - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
> + - MIF (Memory Interface) block
> + : VDD_MIF |--- DMC (Dynamic Memory Controller)
> +
> + - INT (Internal) block
> + : VDD_INT |--- LEFTBUS (parent device)
> +   |--- PERIL
> +   |--- MFC
> +   |--- G3D
> +   |--- RIGHTBUS
> +   |--- FSYS
> +   |--- LCD0
> +   |--- PERIR
> +   |--- ISP
> +   |--- CAM
>  
>   - MIF bus's frequency/voltage table
>   ---
> @@ -46,6 +64,24 @@ Example1:
>   |L5| 40 |875000   |
>   ---
>  
> + - INT bus's frequency/voltage table
> + --
> + |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL  ||VDD_INT |
> + | name|   |LCD0|   |   |   |||
> + | |   |FSYS|   |   |   |||
> + | |   |MFC |   |   |   |||
> + --
> + |Mode |*parent|passive |passive|passive|passive|||
> + --
> + |Lv   |Frequency   ||Voltage |
> + --
> + |L1   |5  |5   |5  |5  |5  ||90  |
> + |L2   |8  |8   |8  |8  |8  ||90  |
> + |L3   |10 |10  |10 |10 |10 ||100 |
> + |L4   |134000 |134000  |20 |20 |   ||100 |
> + |L5   |20 |20  |40 |30 |   ||100 |
> + --
> +
>  Example2 :
>   The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>   are listed below:
> @@ -84,6 +120,167 @@ Example2 :
>   };
>   };
>  
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_lcd0: bus_lcd0 {
> + compatible 

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 10.12.2015 11:00, Chanwoo Choi wrote:
> On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
>> On 10.12.2015 10:09, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
 On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus node for 
> Exynos3250 SoC.
> The DMC is an AMBA AXI-compliant slave to interface external JEDEC 
> standard
> SDRAM devices. The bus includes the OPP tables and the source clock for 
> DMC
> block.
>
> Following list specifies the detailed relation between the clock and DMC 
> block:
> - The source clock of DMC block : div_dmc
>
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>  1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 2f30d632f1cc..7214c5e42150 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -687,6 +687,40 @@
>   clock-names = "ppmu";
>   status = "disabled";
>   };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {

 This is the firsy opp_table, right? So:
 s/opp_table1/opp_table0/
>>>
>>> Right. It is first opp_table in exynos3250.dtsi.
>>> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
>>> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.
>>
>> Ok
>>
>>>

> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <80>;

 Why 134, not 133 MHz?
>>>
>>> When I used the 13300, the source clock is changed to 100Mhz instead of 
>>> 133MHz.
>>> I add following test result on exynos3250-rinato board.
>>>
>>> Case1.
>>> When I use the 134 MHz, the source clock is changed to 133MHz
>>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) 
>>> (real: 13334)
>>>
>>> Case2.
>>> When I use the 133 MHz, the source clock is changed to 100MHz
>>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) 
>>> (real: 1)
>>
>> Now I remember that issue. You could use here directly 13334 but
>> that also would look a little bit weird... so 134 is ok for me. Could
>> just add a comment that desired frequency is actually "133 MHz"?
> 
> Do you prefer among following example?
> 
> Example1.
>   opp02 {
>   /* The desired frequency is 133MHz because
>* clock change has the dependency on clock driver.
>* When set rate as 134MHz, the clock driver would
>* change the 133MHz actually instead of 134MHz.
>*/
>   opp-hz = /bits/ 64 <13400>;
>   opp-microvolt = <80>;
>   };
> 
> Example2.
>   opp02 {
>   opp-hz = /bits/ 64 <13334>;
>   opp-microvolt = <80>;
>   };

I would prefer the second one (13334) but I don't have strong
feelings about it.

Best regards,
Krzysztof

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

Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250

[Krzysztof Kozlowski]

On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 
> SoC.
> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
> block.
> 
> Following list specifies the detailed relation between the clock and DMC 
> block:
> - The source clock of DMC block : div_dmc
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 2f30d632f1cc..7214c5e42150 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -687,6 +687,40 @@
>   clock-names = "ppmu";
>   status = "disabled";
>   };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {

This is the firsy opp_table, right? So:
s/opp_table1/opp_table0/

> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <80>;

Why 134, not 133 MHz?

> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <80>;

Shouldn't this be 825 mV, not 800? I think we used previously that value
for our devices.

Best regards,
Krzysztof


> + };
> + opp04 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <875000>;
> + };
> + };
>   };
>  };
>  
> 

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

Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Krzysztof Kozlowski]

On 10.12.2015 09:49, Chanwoo Choi wrote:
> Hi,
> 
(...)

>>
>>> +
>>> +   bus_dmc: bus_dmc {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = <_dmc CLK_DIV_DMC>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_dmc_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   bus_dmc_opp_table: opp_table0 {
>>> +   compatible = "operating-points-v2";
>>> +   opp-shared;
>>> +
>>> +   opp00 {
>>
>> Maybe use convention with frequency, like:
>>  opp@5000
>> This also used in opp.txt examples.
> 
> In the Documentations/devicetree/bindings/opp/opp.txt,
> the example uses the 'opp@0x'. I check the opp.txt of Linux 4.4-rc4.

Yes, it was changed by Viresh in "PM / OPP: Rename OPP nodes as
opp@". You can find the most actual bindings in linux-next.

Best regards,
Krzysztof



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

Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Chanwoo Choi]

Hi Anand,

First of all, thanks for trying to test this series.

On 2015년 12월 10일 04:05, Anand Moon wrote:
> Hi Chanwoo Choi,
> 
> On 9 December 2015 at 09:37, Chanwoo Choi  wrote:
>> This patch-set includes the two features as following. The generic exynos bus
>> frequency driver is able to support almost Exynos SoCs for bus frequency
>> scaling. And the new passive governor is able to make the dependency on
>> between devices for frequency/voltage scaling. I had posted the patch-set[1]
>> with the similiar concept. This is is revised version for exynos bus 
>> frequency.
>> - Generic exynos bus frequency driver
>> - New passive governor of DEVFREQ framework
>>
>> Depends on:
>> - This patch-set is based on devfreq.git[2].
>> [1] https://lkml.org/lkml/2015/1/7/872
>>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
>> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
>> for-rafael)
>>
>> Changes from v1:
>> (https://lkml.org/lkml/2015/11/26/260)
>> - Check whether the instance of regulator is NULL or not
>>   when executing regulator_disable() because of only parent
>>   devfreq device has the regulator instance. After fixing it,
>>   the wake-up from suspend state is well working. (patch1)
>> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>>   after calling devm_clk_get() (on patch1)
>> - Update the documentation to remove the description about
>>   DEVFREQ-EVENT subsystem (on patch2)
>> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
>> - Modify the detailed correlation of buses for Exynos3250
>>   on documentation (patch2)
>> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
>> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
>> - Add the PPMU node for exynos4412-odroidu3
>> - Add the support of bus frequency for exynos4412-odroidu3
>>
>> Detailed descirption for patch-set:
>> 1. Add generic exynos bus frequency driver
>> : This patch-set adds the generic exynos bus frequency driver for AXI bus
>> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
>> architecture for bus between DRAM and sub-blocks in SoC.
>>
>>  There are the different buses according to Exynos SoC because Exynos SoC
>> has the differnt sub-blocks and bus speed. In spite of this difference
>> among Exynos SoCs, this driver is able to support almost Exynos SoC by adding
>> unique data of each bus in the devicetree file.
>>
>>  In devicetree, each bus node has a bus clock, regulator, operation-point
>> and devfreq-event devices which measure the utilization of each bus block.
>>
>> For example,
>> - The bus of DMC block in exynos3250.dtsi are listed below:
>>
>> bus_dmc: bus_dmc {
>> compatible = "samsung,exynos-bus";
>> clocks = <_dmc CLK_DIV_DMC>;
>> clock-names = "bus";
>> operating-points-v2 = <_dmc_opp_table>;
>> status = "disabled";
>> };
>>
>> bus_dmc_opp_table: opp_table0 {
>> compatible = "operating-points-v2";
>> opp-shared;
>>
>> opp00 {
>> opp-hz = /bits/ 64 <5000>;
>> opp-microvolt = <80>;
>> };
>> opp01 {
>> opp-hz = /bits/ 64 <1>;
>> opp-microvolt = <80>;
>> };
>> opp02 {
>> opp-hz = /bits/ 64 <13400>;
>> opp-microvolt = <80>;
>> };
>> opp03 {
>> opp-hz = /bits/ 64 <2>;
>> opp-microvolt = <80>;
>> };
>> opp04 {
>> opp-hz = /bits/ 64 <4>;
>> opp-microvolt = <875000>;
>> };
>> };
>>
>> - Usage case to handle the frequency and voltage of bus on runtime
>>   in exynos3250-rinato.dts are listed below:
>>
>> _dmc {
>> devfreq-events = <_dmc0_3>, <_dmc1_3>;
>> vdd-supply = <_reg>;  /* VDD_MIF */
>> status = "okay";
>> };
>>
>> 2. Add new passive governor of DEVFREQ framework (patch5-patch7)
>> : This patch-set add the new passive governor for DEVFREQ framework.
>> The existing governors (ondemand, performance and so on) are used for DVFS
>> (Dynamic Voltage and Frequency Scaling) drivers. The existing governors
>> are independently used for specific device driver which don't give the
>> influence to other device drviers and also don't receive the effect from
>> other device drivers.
>>
>>  The passive governor depends on operation of parent driver with existing
>> governors(ondemand, performance and so on) extremely and is not able to
>> decide the new frequency by oneself. According to the decided new frequency
>> of parent driver 

Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Krzysztof Kozlowski]

On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the documentation for generic exynos bus frequency
> driver.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 94 
> ++
>  1 file changed, 94 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> new file mode 100644
> index ..54a1f9c46c88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -0,0 +1,94 @@
> +* Generic Exynos Bus frequency device
> +
> +The Samsung Exynos SoC have many buses for data transfer between DRAM
> +and sub-blocks in SoC. Almost Exynos SoC have the common architecture
> +for buses. Generally, the each bus of Exynos SoC includes the source clock
> +and power line and then is able to change the clock according to the usage
> +of each buses on runtime. When gathering the usage of each buses on runtime,
> +thie driver uses the PPMU (Platform Performance Monitoring Unit) which

s/thie/the/

> +is able to measure the current load of sub-blocks.
> +
> +There are a little different composition among Exynos SoC because each Exynos
> +SoC has the different sub-blocks. So, this difference should be specified
> +in devicetree file instead of each device driver. In result, this driver
> +is able to support the bus frequency for all Exynos SoCs.
> +
> +Required properties for bus device:
> +- compatible: Should be "samsung,exynos-bus".
> +- clock-names : the name of clock used by the bus, "bus".
> +- clocks : phandles for clock specified in "clock-names" property.
> +- #clock-cells: should be 1.

This is a clock consumer, right? So the clock-cells is not valid here.

> +- operating-points-v2: the OPP table including frequency/voltage information
> +  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
> +- vdd-supply: the regulator to provide the buses with the voltage.
> +- devfreq-events: the devfreq-event device to monitor the curret utilization

s/curret/current/

> +  of buses.
> +
> +Optional properties for bus device:
> +- exynos,saturation-ratio: the percentage value which is used to calibrate
> +   the performance count againt total cycle count.

s/againt/against/

> +
> +Example1:
> + Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
> + power line (regulator). The MIF (Memory Interface) AXI bus is used to
> + transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
> +
> + - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
> +
> + - MIF bus's frequency/voltage table
> + ---
> + |Lv| Freq   | Voltage |
> + ---
> + |L1| 5  |80   |
> + |L2| 10 |80   |
> + |L3| 134000 |80   |
> + |L4| 20 |80   |
> + |L5| 40 |875000   |
> + ---
> +
> +Example2 :
> + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
> + are listed below:

s/are/is/ (one bus is listed)

> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {

Maybe use convention with frequency, like:
opp@5000
This also used in opp.txt examples.


> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <80>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <80>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <875000>;
> + };
> + };
> +
> + Usage case to handle the frequency and voltage of bus on runtime
> + in exynos3250-rinato.dts are listed below:

s/are/is/

> +
> + _dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;  /* VDD_MIF */
> + status = "okay";
> + };
> 

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

Re: [PATCH v2 13/19] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.

s/noes/nodes/

> Exynos4x12 has the following AXI buses to translate data
> between DRAM and DMC/ACP/C2C.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi | 72 
> +++
>  1 file changed, 72 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index b77dac61ffb5..3bcf0939755e 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -282,6 +282,78 @@
>   clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
>   #iommu-cells = <0>;
>   };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_acp: bus_acp {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_ACP>;
> + clock-names = "bus";
> + operating-points-v2 = <_acp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_c2c: bus_c2c {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_C2C>;
> + clock-names = "bus";
> + operating-points-v2 = <_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <90>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <90>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <95>;

The exyno4_bus.c (from mainline) uses 267 MHz here. Why choosing 200 MHz?

Best regards,
Krzysztof

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

Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Chanwoo Choi]

Hi Anand,

On 2015년 12월 10일 13:14, Anand Moon wrote:
> Hi Chanwoo Choi,
> 
> On 10 December 2015 at 05:42, Chanwoo Choi  wrote:
>> Hi Anand,
>>
>> First of all, thanks for trying to test this series.
>>
>> On 2015년 12월 10일 04:05, Anand Moon wrote:
>>> Hi Chanwoo Choi,
>>>
>>> On 9 December 2015 at 09:37, Chanwoo Choi  wrote:
 This patch-set includes the two features as following. The generic exynos 
 bus
 frequency driver is able to support almost Exynos SoCs for bus frequency
 scaling. And the new passive governor is able to make the dependency on
 between devices for frequency/voltage scaling. I had posted the 
 patch-set[1]
 with the similiar concept. This is is revised version for exynos bus 
 frequency.
 - Generic exynos bus frequency driver
 - New passive governor of DEVFREQ framework

 Depends on:
 - This patch-set is based on devfreq.git[2].
 [1] https://lkml.org/lkml/2015/1/7/872
: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
 [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
 for-rafael)

 Changes from v1:
 (https://lkml.org/lkml/2015/11/26/260)
 - Check whether the instance of regulator is NULL or not
   when executing regulator_disable() because of only parent
   devfreq device has the regulator instance. After fixing it,
   the wake-up from suspend state is well working. (patch1)
 - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
   after calling devm_clk_get() (on patch1)
 - Update the documentation to remove the description about
   DEVFREQ-EVENT subsystem (on patch2)
 - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
 - Modify the detailed correlation of buses for Exynos3250
   on documentation (patch2)
 - Add the MFC bus node for Exynos3250 (on patch11, patch12)
 - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
 - Add the PPMU node for exynos4412-odroidu3
 - Add the support of bus frequency for exynos4412-odroidu3

 Detailed descirption for patch-set:
 1. Add generic exynos bus frequency driver
 : This patch-set adds the generic exynos bus frequency driver for AXI bus
 of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
 architecture for bus between DRAM and sub-blocks in SoC.

  There are the different buses according to Exynos SoC because Exynos SoC
 has the differnt sub-blocks and bus speed. In spite of this difference
 among Exynos SoCs, this driver is able to support almost Exynos SoC by 
 adding
 unique data of each bus in the devicetree file.

  In devicetree, each bus node has a bus clock, regulator, operation-point
 and devfreq-event devices which measure the utilization of each bus block.

 For example,
 - The bus of DMC block in exynos3250.dtsi are listed below:

 bus_dmc: bus_dmc {
 compatible = "samsung,exynos-bus";
 clocks = <_dmc CLK_DIV_DMC>;
 clock-names = "bus";
 operating-points-v2 = <_dmc_opp_table>;
 status = "disabled";
 };

 bus_dmc_opp_table: opp_table0 {
 compatible = "operating-points-v2";
 opp-shared;

 opp00 {
 opp-hz = /bits/ 64 <5000>;
 opp-microvolt = <80>;
 };
 opp01 {
 opp-hz = /bits/ 64 <1>;
 opp-microvolt = <80>;
 };
 opp02 {
 opp-hz = /bits/ 64 <13400>;
 opp-microvolt = <80>;
 };
 opp03 {
 opp-hz = /bits/ 64 <2>;
 opp-microvolt = <80>;
 };
 opp04 {
 opp-hz = /bits/ 64 <4>;
 opp-microvolt = <875000>;
 };
 };

 - Usage case to handle the frequency and voltage of bus on runtime
   in exynos3250-rinato.dts are listed below:

 _dmc {
 devfreq-events = <_dmc0_3>, <_dmc1_3>;
 vdd-supply = <_reg>;  /* VDD_MIF */
 status = "okay";
 };

 2. Add new passive governor of DEVFREQ framework (patch5-patch7)
 : This patch-set add the new passive governor for DEVFREQ framework.
 The existing governors (ondemand, performance and so on) are used for DVFS
 (Dynamic Voltage and Frequency Scaling) drivers. The existing governors
 are independently used for specific device 

Re: [PATCH v2 03/22] drm/exynos: gsc: add device tree support and remove usage of static mappings

[Krzysztof Kozlowski]

On 10.12.2015 15:48, Inki Dae wrote:
> CCing Mr. Kukjin and Krzysztof
> 
> 
> Hi Kukjin and Krzysztof,
> 
> Below patch includes dt binding about gsc device but it'd be nice this patch 
> to exynos drm tree with others.
> So could you give me Acked-by so that I can merge it to exynos drm tree?
> 
> Thanks,
> Inki Dae
> 
> 2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
>> From: Seung-Woo Kim 
>>
>> This patch adds device tree support for exynos_drm_gsc. This patch
>> also fixed build issue on non-Exynos platforms, thus dependency on
>> !ARCH_MULTIPLATFORM can be now removed. The driver cannot be used
>> simultaneously with V4L2 Mem2Mem GScaller driver thought.
>>
>> Signed-off-by: Seung-Woo Kim 
>> [updated commit message, removed the need for wb-lcd property, because
>> all gscallers have support for lcd writeback, replaced dependency on
>> !ARCH_MULTIPLATFORM with !VIDEO_SAMSUNG_EXYNOS_GSC]
>> Signed-off-by: Marek Szyprowski 
>> ---
>>  .../devicetree/bindings/media/exynos5-gsc.txt  |  4 +++
>>  drivers/gpu/drm/exynos/Kconfig |  2 +-
>>  drivers/gpu/drm/exynos/exynos_drm_gsc.c| 30 
>> +++---
>>  drivers/gpu/drm/exynos/regs-gsc.h  |  4 +--
>>  4 files changed, 33 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
>> b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> index 0604d42f38d1..5fe9372abb37 100644
>> --- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> +++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> @@ -7,6 +7,10 @@ Required properties:
>>  - reg: should contain G-Scaler physical address location and length.
>>  - interrupts: should contain G-Scaler interrupt number
>>  
>> +Optional properties:
>> +- samsung,sysreg: handle to syscon used to control the system registers to
>> +  set writeback input and destination
>> +
>>  Example:
>>  
>>  gsc_0:  gsc@0x13e0 {


Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Chanwoo Choi]

On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
> On 10.12.2015 15:43, Chanwoo Choi wrote:
>> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
>>> On 10.12.2015 15:08, Chanwoo Choi wrote:
 On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>> Exynos4x12 has the following AXI buses to translate data between
>> DRAM and sub-blocks.
>>
>> Following list specifies the detailed relation between DRAM and 
>> sub-blocks:
>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>> - ACLK160 clock for CAM/TV/LCD
>> : The minimum clock of ACLK160 should be over 160MHz.
>>   When drop the clock under 160MHz, show the broken image.
>> - ACLK133 clock for FSYS
>> - GDL clock for LEFTBUS
>> - GDR clock for RIGHTBUS
>> - SCLK_MFC clock for MFC
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
>> ++
>>  1 file changed, 112 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 3bcf0939755e..8bc4aee156b5 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -354,6 +354,118 @@
>>  opp-microvolt = <95>;
>>  };
>>  };
>> +
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDR>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>
> These two nodes are symmetrical. The MFC below and other buses in other
> DTS share opps. How about changing the binding so multiple clocks could
> be specified at once ("bus0", "bus1")? I think there is no need for a
> bus device for each clock.

 The your commented method is possible.

 But, I focus on implementing the generic bus frequency driver.

 If specific bus device-tree node includes the one more clocks,
 when adding the new Exynos SoC, the exynos-bus.c should be added
 for new Exynos SoC. Because, each Exynos SoC has the different
 set of bus device.

 If we use my approach, we don't need to modify the exynos-bus.c
 driver to support for the bus frequency of new Exynos SoC.
>>>
>>> This won't change. The driver will just support from 1 to N clocks for
>>> given bus device and set the same OPP to all of them. This will only
>>> limit the number of duplicated entries. This won't affect the generic
>>> approach of driver itself.
>>
>> You're right aspect of only implementation of device driver.
>>
>> But,
>> If we use your commented approach, we can show the information
>> of only parent device through sysfs. We cannot see the information
>> of passive device. The some information includes the current
>> frequency and correlation of parent device. (But, current patchset
>> don' include the topology information between parent device and
>> passive device. I'll do it on later patches).
>>
>> For example, 
>> We can see the following bus device through /sys/class/devfreq.
>>
>> drwxr-xr-x  2 root root 0 Dec 31 17:00 .
>> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_display -> 
>> ../../devices/platform/bus_display/devfreq/bus_display
>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_fsys -> 
>> ../../devices/platform/bus_fsys/devfreq/bus_fsys
>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_leftbus -> 
>> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_peri -> 
>> ../../devices/platform/bus_peri/devfreq/bus_peri
>>
>>
>> We don't see the following bus device because of following bus device
>> has the same frequency table with bus_leftbus device.
>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_mfc -> 
>> ../../devices/platform/bus_mfc/devfreq/bus_mfc
>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_rightbus -> 
>> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
> 
> Right, but why do you want to see these bus devices? AFAIU, they will

I think that the framework should show the accurate information of H/w device
through sysfs. On the exynos-bus.c driver, it is important the show the
accurate set of handled bus devices which are included in Exynos SoC.

> always behave exactly the same as LEFTBUS. Their PPMU 

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Chanwoo Choi]

On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>> Exynos4x12 has the following AXI buses to translate data between
>> DRAM and sub-blocks.
>>
>> Following list specifies the detailed relation between DRAM and sub-blocks:
>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>> - ACLK160 clock for CAM/TV/LCD
>> : The minimum clock of ACLK160 should be over 160MHz.
>>   When drop the clock under 160MHz, show the broken image.
>> - ACLK133 clock for FSYS
>> - GDL clock for LEFTBUS
>> - GDR clock for RIGHTBUS
>> - SCLK_MFC clock for MFC
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
>> ++
>>  1 file changed, 112 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 3bcf0939755e..8bc4aee156b5 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -354,6 +354,118 @@
>>  opp-microvolt = <95>;
>>  };
>>  };
>> +
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDR>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
> 
> These two nodes are symmetrical. The MFC below and other buses in other
> DTS share opps. How about changing the binding so multiple clocks could
> be specified at once ("bus0", "bus1")? I think there is no need for a
> bus device for each clock.

The your commented method is possible.

But, I focus on implementing the generic bus frequency driver.

If specific bus device-tree node includes the one more clocks,
when adding the new Exynos SoC, the exynos-bus.c should be added
for new Exynos SoC. Because, each Exynos SoC has the different
set of bus device.

If we use my approach, we don't need to modify the exynos-bus.c
driver to support for the bus frequency of new Exynos SoC.

Best Regards,
Chanwoo Choi

> 
> Best regards,
> Krzysztof
> 
>> +
>> +bus_display: bus_display {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_ACLK160>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_display_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_fsys: bus_fsys {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_ACLK133>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_fsys_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_peri: bus_peri {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_ACLK100>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_peri_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_mfc: bus_mfc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_SCLK_MFC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_leftbus_opp_table: opp_table3 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <925000>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <95>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <100>;
>> +};
>> +};
>> +
>> +bus_display_opp_table: opp_table4 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <95>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <100>;
>> +};
>> +};
>> +
>> +bus_fsys_opp_table: opp_table5 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = 

Re: [PATCH v2 16/19] ARM: dts: Add PPMU node for exynos4412-odroidu3

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch add dt node for PPMU_{DMC0|DMC1|LEFTBUS|RIGHTBUS} for
> exynos4412-odroidu3 board. Each PPMU dt node includes one event of
> 'PPMU Count3'.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 40 
> +
>  1 file changed, 40 insertions(+)
> 

The patch itself is good but now I see that it is duplicated with
Rinato, Monk and Trats2. Probably for all other Exynos4 and
one-cluster-Exynos5 boards this would be exactly the same as well.

How about making a DTSI file with common PPMU events configuration?

Best regards,
Krzysztof

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

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 10.12.2015 16:07, Chanwoo Choi wrote:
> On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
>> On 10.12.2015 15:43, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
 On 10.12.2015 15:08, Chanwoo Choi wrote:
> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>> Exynos4x12 has the following AXI buses to translate data between
>>> DRAM and sub-blocks.
>>>
>>> Following list specifies the detailed relation between DRAM and 
>>> sub-blocks:
>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>> - ACLK160 clock for CAM/TV/LCD
>>> : The minimum clock of ACLK160 should be over 160MHz.
>>>   When drop the clock under 160MHz, show the broken image.
>>> - ACLK133 clock for FSYS
>>> - GDL clock for LEFTBUS
>>> - GDR clock for RIGHTBUS
>>> - SCLK_MFC clock for MFC
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
>>> ++
>>>  1 file changed, 112 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 3bcf0939755e..8bc4aee156b5 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -354,6 +354,118 @@
>>> opp-microvolt = <95>;
>>> };
>>> };
>>> +
>>> +   bus_leftbus: bus_leftbus {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = < CLK_DIV_GDL>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_leftbus_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   bus_rightbus: bus_rightbus {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = < CLK_DIV_GDR>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_leftbus_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>
>> These two nodes are symmetrical. The MFC below and other buses in other
>> DTS share opps. How about changing the binding so multiple clocks could
>> be specified at once ("bus0", "bus1")? I think there is no need for a
>> bus device for each clock.
>
> The your commented method is possible.
>
> But, I focus on implementing the generic bus frequency driver.
>
> If specific bus device-tree node includes the one more clocks,
> when adding the new Exynos SoC, the exynos-bus.c should be added
> for new Exynos SoC. Because, each Exynos SoC has the different
> set of bus device.
>
> If we use my approach, we don't need to modify the exynos-bus.c
> driver to support for the bus frequency of new Exynos SoC.

 This won't change. The driver will just support from 1 to N clocks for
 given bus device and set the same OPP to all of them. This will only
 limit the number of duplicated entries. This won't affect the generic
 approach of driver itself.
>>>
>>> You're right aspect of only implementation of device driver.
>>>
>>> But,
>>> If we use your commented approach, we can show the information
>>> of only parent device through sysfs. We cannot see the information
>>> of passive device. The some information includes the current
>>> frequency and correlation of parent device. (But, current patchset
>>> don' include the topology information between parent device and
>>> passive device. I'll do it on later patches).
>>>
>>> For example, 
>>> We can see the following bus device through /sys/class/devfreq.
>>>
>>> drwxr-xr-x  2 root root 0 Dec 31 17:00 .
>>> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
>>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_display -> 
>>> ../../devices/platform/bus_display/devfreq/bus_display
>>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_fsys -> 
>>> ../../devices/platform/bus_fsys/devfreq/bus_fsys
>>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_leftbus -> 
>>> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
>>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_peri -> 
>>> ../../devices/platform/bus_peri/devfreq/bus_peri
>>>
>>>
>>> We don't see the following bus device because of following bus device
>>> has the same frequency table with bus_leftbus device.
>>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_mfc -> 
>>> ../../devices/platform/bus_mfc/devfreq/bus_mfc
>>> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_rightbus -> 
>>> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
>>
>> Right, but why do you want to see these bus devices? AFAIU, they will
> 
> I think that the framework should show the accurate information of H/w device
> through sysfs. On the exynos-bus.c driver, it is important 

Re: [PATCH v2 17/19] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato

[Chanwoo Choi]

On 2015년 12월 10일 15:58, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus device-tree node of INT (internal) block
>> to enable the bus frequency. The following sub-blocks share
> 
> "to enable the bus frequency scaling"
> 
>> the VDD_INT power source:
>> - LEFTBUS (parent device)
>> - RIGHTBUS
>> - PERIL
>> - LCD0
>> - FSYS
>> - MCUISP / ISP
>> - MFC
>>
>> The LEFTBUS is parent device with devfreq ondemand governor
>> and the rest devices has the dependency on LEFTBUS bus.
> 
> How about:
> "and the rest of devices depend on the LEFTBUS device."
> ?

OK, I'll modify it.

> 
> The patch is good:
> 
> Reviewed-by: Krzysztof Kozlowski 

Thanks for your review.

Best Regards,
Chanwoo Choi

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

Re: [PATCH v2 19/19] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3

[Chanwoo Choi]

On 2015년 12월 10일 16:08, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
>> (Internal) block to enable the bus frequency.
>>
>> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
>> bus is parent device in INT block using VDD_INT.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 
>> +
>>  arch/arm/boot/dts/exynos4412-trats2.dts | 47 
>> +
>>  2 files changed, 94 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index 171dea1e3e4a..12d08242a179 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -544,3 +544,50 @@
>>  };
>>  };
>>  };
>> +
>> +_dmc {
>> +devfreq-events = <_dmc0_3>, <_dmc1_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>> +_acp {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
>> +
>> +_c2c {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
>> +
>> +_leftbus {
>> +devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>> +_rightbus {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_display {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_fsys {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_peri {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_mfc {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
>> b/arch/arm/boot/dts/exynos4412-trats2.dts
>> index 40a474c4374b..aecd545803ad 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -1286,3 +1286,50 @@
>>  vtmu-supply = <_reg>;
>>  status = "okay";
>>  };
>> +
>> +_dmc {
>> +devfreq-events = <_dmc0_3>, <_dmc1_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>> +_acp {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
>> +
>> +_c2c {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
>> +
>> +_leftbus {
>> +devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> +vdd-supply = <_reg>;
>> +status = "okay";
>> +};
>> +
>> +_rightbus {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_display {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_fsys {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_peri {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +_mfc {
>> +devfreq = <_leftbus>;
>> +status = "okay";
>> +};
> 
> The nodes in both files are mostly sorted alphabetically. Could you
> place them in such order as well?

Okay. I'll sort them alphabetically.

Best Regards,
Chanwoo Choi



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

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 10.12.2015 15:08, Chanwoo Choi wrote:
> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>> Exynos4x12 has the following AXI buses to translate data between
>>> DRAM and sub-blocks.
>>>
>>> Following list specifies the detailed relation between DRAM and sub-blocks:
>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>> - ACLK160 clock for CAM/TV/LCD
>>> : The minimum clock of ACLK160 should be over 160MHz.
>>>   When drop the clock under 160MHz, show the broken image.
>>> - ACLK133 clock for FSYS
>>> - GDL clock for LEFTBUS
>>> - GDR clock for RIGHTBUS
>>> - SCLK_MFC clock for MFC
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
>>> ++
>>>  1 file changed, 112 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 3bcf0939755e..8bc4aee156b5 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -354,6 +354,118 @@
>>> opp-microvolt = <95>;
>>> };
>>> };
>>> +
>>> +   bus_leftbus: bus_leftbus {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = < CLK_DIV_GDL>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_leftbus_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   bus_rightbus: bus_rightbus {
>>> +   compatible = "samsung,exynos-bus";
>>> +   clocks = < CLK_DIV_GDR>;
>>> +   clock-names = "bus";
>>> +   operating-points-v2 = <_leftbus_opp_table>;
>>> +   status = "disabled";
>>> +   };
>>
>> These two nodes are symmetrical. The MFC below and other buses in other
>> DTS share opps. How about changing the binding so multiple clocks could
>> be specified at once ("bus0", "bus1")? I think there is no need for a
>> bus device for each clock.
> 
> The your commented method is possible.
> 
> But, I focus on implementing the generic bus frequency driver.
> 
> If specific bus device-tree node includes the one more clocks,
> when adding the new Exynos SoC, the exynos-bus.c should be added
> for new Exynos SoC. Because, each Exynos SoC has the different
> set of bus device.
> 
> If we use my approach, we don't need to modify the exynos-bus.c
> driver to support for the bus frequency of new Exynos SoC.

This won't change. The driver will just support from 1 to N clocks for
given bus device and set the same OPP to all of them. This will only
limit the number of duplicated entries. This won't affect the generic
approach of driver itself.

Best regards,
Krzysztof

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

Re: [PATCH v2 17/19] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus device-tree node of INT (internal) block
> to enable the bus frequency. The following sub-blocks share

"to enable the bus frequency scaling"

> the VDD_INT power source:
> - LEFTBUS (parent device)
> - RIGHTBUS
> - PERIL
> - LCD0
> - FSYS
> - MCUISP / ISP
> - MFC
> 
> The LEFTBUS is parent device with devfreq ondemand governor
> and the rest devices has the dependency on LEFTBUS bus.

How about:
"and the rest of devices depend on the LEFTBUS device."
?

The patch is good:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH v2 19/19] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
> 
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 
> +
>  arch/arm/boot/dts/exynos4412-trats2.dts | 47 
> +
>  2 files changed, 94 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 171dea1e3e4a..12d08242a179 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -544,3 +544,50 @@
>   };
>   };
>  };
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 40a474c4374b..aecd545803ad 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -1286,3 +1286,50 @@
>   vtmu-supply = <_reg>;
>   status = "okay";
>  };
> +
> +_dmc {
> + devfreq-events = <_dmc0_3>, <_dmc1_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_acp {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_c2c {
> + devfreq = <_dmc>;
> + status = "okay";
> +};
> +
> +_leftbus {
> + devfreq-events = <_leftbus_3>, <_rightbus_3>;
> + vdd-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_rightbus {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_display {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_fsys {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_peri {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};
> +
> +_mfc {
> + devfreq = <_leftbus>;
> + status = "okay";
> +};

The nodes in both files are mostly sorted alphabetically. Could you
place them in such order as well?

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

Re: [PATCH v2 13/19] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12

[Chanwoo Choi]

On 2015년 12월 10일 12:17, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.
> 
> s/noes/nodes/

OK.

> 
>> Exynos4x12 has the following AXI buses to translate data
>> between DRAM and DMC/ACP/C2C.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos4x12.dtsi | 72 
>> +++
>>  1 file changed, 72 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index b77dac61ffb5..3bcf0939755e 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -282,6 +282,78 @@
>>  clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
>>  #iommu-cells = <0>;
>>  };
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_DMC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_acp: bus_acp {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_ACP>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_acp_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_c2c: bus_c2c {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_C2C>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_dmc_opp_table: opp_table1 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <90>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <90>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <95>;
> 
> The exyno4_bus.c (from mainline) uses 267 MHz here. Why choosing 200 MHz?

There is no special reason.
I'll change it (200MHz -> 267MHz).

Best Regards,
Chanwoo Choi

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

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Chanwoo Choi]

On 2015년 12월 10일 16:12, Krzysztof Kozlowski wrote:
> On 10.12.2015 16:07, Chanwoo Choi wrote:
>> On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
>>> On 10.12.2015 15:43, Chanwoo Choi wrote:
 On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
> On 10.12.2015 15:08, Chanwoo Choi wrote:
>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>>> On 09.12.2015 13:08, Chanwoo Choi wrote:
 This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
 Exynos4x12 has the following AXI buses to translate data between
 DRAM and sub-blocks.

 Following list specifies the detailed relation between DRAM and 
 sub-blocks:
 - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
 - ACLK160 clock for CAM/TV/LCD
 : The minimum clock of ACLK160 should be over 160MHz.
   When drop the clock under 160MHz, show the broken image.
 - ACLK133 clock for FSYS
 - GDL clock for LEFTBUS
 - GDR clock for RIGHTBUS
 - SCLK_MFC clock for MFC

 Signed-off-by: Chanwoo Choi 
 ---
  arch/arm/boot/dts/exynos4x12.dtsi | 112 
 ++
  1 file changed, 112 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
 b/arch/arm/boot/dts/exynos4x12.dtsi
 index 3bcf0939755e..8bc4aee156b5 100644
 --- a/arch/arm/boot/dts/exynos4x12.dtsi
 +++ b/arch/arm/boot/dts/exynos4x12.dtsi
 @@ -354,6 +354,118 @@
opp-microvolt = <95>;
};
};
 +
 +  bus_leftbus: bus_leftbus {
 +  compatible = "samsung,exynos-bus";
 +  clocks = < CLK_DIV_GDL>;
 +  clock-names = "bus";
 +  operating-points-v2 = <_leftbus_opp_table>;
 +  status = "disabled";
 +  };
 +
 +  bus_rightbus: bus_rightbus {
 +  compatible = "samsung,exynos-bus";
 +  clocks = < CLK_DIV_GDR>;
 +  clock-names = "bus";
 +  operating-points-v2 = <_leftbus_opp_table>;
 +  status = "disabled";
 +  };
>>>
>>> These two nodes are symmetrical. The MFC below and other buses in other
>>> DTS share opps. How about changing the binding so multiple clocks could
>>> be specified at once ("bus0", "bus1")? I think there is no need for a
>>> bus device for each clock.
>>
>> The your commented method is possible.
>>
>> But, I focus on implementing the generic bus frequency driver.
>>
>> If specific bus device-tree node includes the one more clocks,
>> when adding the new Exynos SoC, the exynos-bus.c should be added
>> for new Exynos SoC. Because, each Exynos SoC has the different
>> set of bus device.
>>
>> If we use my approach, we don't need to modify the exynos-bus.c
>> driver to support for the bus frequency of new Exynos SoC.
>
> This won't change. The driver will just support from 1 to N clocks for
> given bus device and set the same OPP to all of them. This will only
> limit the number of duplicated entries. This won't affect the generic
> approach of driver itself.

 You're right aspect of only implementation of device driver.

 But,
 If we use your commented approach, we can show the information
 of only parent device through sysfs. We cannot see the information
 of passive device. The some information includes the current
 frequency and correlation of parent device. (But, current patchset
 don' include the topology information between parent device and
 passive device. I'll do it on later patches).

 For example, 
 We can see the following bus device through /sys/class/devfreq.

 drwxr-xr-x  2 root root 0 Dec 31 17:00 .
 drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
 lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_display -> 
 ../../devices/platform/bus_display/devfreq/bus_display
 lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_fsys -> 
 ../../devices/platform/bus_fsys/devfreq/bus_fsys
 lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_leftbus -> 
 ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
 lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_peri -> 
 ../../devices/platform/bus_peri/devfreq/bus_peri


 We don't see the following bus device because of following bus device
 has the same frequency table with bus_leftbus device.
 lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_mfc -> 
 ../../devices/platform/bus_mfc/devfreq/bus_mfc
 lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_rightbus -> 
 ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
>>>
>>> Right, but why do you want to see these bus devices? AFAIU, they will
>>

Re: [PATCH v2 18/19] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3

[Chanwoo Choi]

On 2015년 12월 10일 16:02, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch expands the voltage range of buck1/3 regulator due to as 
>> following:
>> - MIF (Memory Interface) bus frequency needs the 9uV ~ 105uV V.
>> - INT (Internal) bus frequency needs 9uV ~ 100uV.
> 
> 9->90 and duplicated "uV V". Maybe just:
> 900 - 1050 mV
> 900 - 1000 mV
> ?

OK. I'll modify the patch description.

> 
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
> 
> For the contents of patch:
> 
> Reviewed-by: Krzysztof Kozlowski 

Best Regards,
Chanwoo CHoi

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

Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Anand Moon]

Hi Chanwoo Choi,

On 10 December 2015 at 05:42, Chanwoo Choi  wrote:
> Hi Anand,
>
> First of all, thanks for trying to test this series.
>
> On 2015년 12월 10일 04:05, Anand Moon wrote:
>> Hi Chanwoo Choi,
>>
>> On 9 December 2015 at 09:37, Chanwoo Choi  wrote:
>>> This patch-set includes the two features as following. The generic exynos 
>>> bus
>>> frequency driver is able to support almost Exynos SoCs for bus frequency
>>> scaling. And the new passive governor is able to make the dependency on
>>> between devices for frequency/voltage scaling. I had posted the patch-set[1]
>>> with the similiar concept. This is is revised version for exynos bus 
>>> frequency.
>>> - Generic exynos bus frequency driver
>>> - New passive governor of DEVFREQ framework
>>>
>>> Depends on:
>>> - This patch-set is based on devfreq.git[2].
>>> [1] https://lkml.org/lkml/2015/1/7/872
>>>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
>>> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
>>> for-rafael)
>>>
>>> Changes from v1:
>>> (https://lkml.org/lkml/2015/11/26/260)
>>> - Check whether the instance of regulator is NULL or not
>>>   when executing regulator_disable() because of only parent
>>>   devfreq device has the regulator instance. After fixing it,
>>>   the wake-up from suspend state is well working. (patch1)
>>> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>>>   after calling devm_clk_get() (on patch1)
>>> - Update the documentation to remove the description about
>>>   DEVFREQ-EVENT subsystem (on patch2)
>>> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
>>> - Modify the detailed correlation of buses for Exynos3250
>>>   on documentation (patch2)
>>> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
>>> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
>>> - Add the PPMU node for exynos4412-odroidu3
>>> - Add the support of bus frequency for exynos4412-odroidu3
>>>
>>> Detailed descirption for patch-set:
>>> 1. Add generic exynos bus frequency driver
>>> : This patch-set adds the generic exynos bus frequency driver for AXI bus
>>> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
>>> architecture for bus between DRAM and sub-blocks in SoC.
>>>
>>>  There are the different buses according to Exynos SoC because Exynos SoC
>>> has the differnt sub-blocks and bus speed. In spite of this difference
>>> among Exynos SoCs, this driver is able to support almost Exynos SoC by 
>>> adding
>>> unique data of each bus in the devicetree file.
>>>
>>>  In devicetree, each bus node has a bus clock, regulator, operation-point
>>> and devfreq-event devices which measure the utilization of each bus block.
>>>
>>> For example,
>>> - The bus of DMC block in exynos3250.dtsi are listed below:
>>>
>>> bus_dmc: bus_dmc {
>>> compatible = "samsung,exynos-bus";
>>> clocks = <_dmc CLK_DIV_DMC>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_dmc_opp_table>;
>>> status = "disabled";
>>> };
>>>
>>> bus_dmc_opp_table: opp_table0 {
>>> compatible = "operating-points-v2";
>>> opp-shared;
>>>
>>> opp00 {
>>> opp-hz = /bits/ 64 <5000>;
>>> opp-microvolt = <80>;
>>> };
>>> opp01 {
>>> opp-hz = /bits/ 64 <1>;
>>> opp-microvolt = <80>;
>>> };
>>> opp02 {
>>> opp-hz = /bits/ 64 <13400>;
>>> opp-microvolt = <80>;
>>> };
>>> opp03 {
>>> opp-hz = /bits/ 64 <2>;
>>> opp-microvolt = <80>;
>>> };
>>> opp04 {
>>> opp-hz = /bits/ 64 <4>;
>>> opp-microvolt = <875000>;
>>> };
>>> };
>>>
>>> - Usage case to handle the frequency and voltage of bus on runtime
>>>   in exynos3250-rinato.dts are listed below:
>>>
>>> _dmc {
>>> devfreq-events = <_dmc0_3>, <_dmc1_3>;
>>> vdd-supply = <_reg>;  /* VDD_MIF */
>>> status = "okay";
>>> };
>>>
>>> 2. Add new passive governor of DEVFREQ framework (patch5-patch7)
>>> : This patch-set add the new passive governor for DEVFREQ framework.
>>> The existing governors (ondemand, performance and so on) are used for DVFS
>>> (Dynamic Voltage and Frequency Scaling) drivers. The existing governors
>>> are independently used for specific device driver which don't give the
>>> influence to other device drviers and also don't receive the effect from
>>> other device drivers.
>>>
>>>  The passive governor depends on 

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
> Exynos4x12 has the following AXI buses to translate data between
> DRAM and sub-blocks.
> 
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD
> : The minimum clock of ACLK160 should be over 160MHz.
>   When drop the clock under 160MHz, show the broken image.
> - ACLK133 clock for FSYS
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
> ++
>  1 file changed, 112 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 3bcf0939755e..8bc4aee156b5 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -354,6 +354,118 @@
>   opp-microvolt = <95>;
>   };
>   };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };

These two nodes are symmetrical. The MFC below and other buses in other
DTS share opps. How about changing the binding so multiple clocks could
be specified at once ("bus0", "bus1")? I think there is no need for a
bus device for each clock.

Best regards,
Krzysztof

> +
> + bus_display: bus_display {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK160>;
> + clock-names = "bus";
> + operating-points-v2 = <_display_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_fsys: bus_fsys {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK133>;
> + clock-names = "bus";
> + operating-points-v2 = <_fsys_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_peri: bus_peri {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK100>;
> + clock-names = "bus";
> + operating-points-v2 = <_peri_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_SCLK_MFC>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_leftbus_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <925000>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <95>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_display_opp_table: opp_table4 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <95>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_fsys_opp_table: opp_table5 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <925000>;
> + };
> + };
> +
> + bus_peri_opp_table: opp_table6 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + 

Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12

[Krzysztof Kozlowski]

On 10.12.2015 15:43, Chanwoo Choi wrote:
> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
>> On 10.12.2015 15:08, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
 On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
> Exynos4x12 has the following AXI buses to translate data between
> DRAM and sub-blocks.
>
> Following list specifies the detailed relation between DRAM and 
> sub-blocks:
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD
> : The minimum clock of ACLK160 should be over 160MHz.
>   When drop the clock under 160MHz, show the broken image.
> - ACLK133 clock for FSYS
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
>
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi | 112 
> ++
>  1 file changed, 112 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 3bcf0939755e..8bc4aee156b5 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -354,6 +354,118 @@
>   opp-microvolt = <95>;
>   };
>   };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = < CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <_leftbus_opp_table>;
> + status = "disabled";
> + };

 These two nodes are symmetrical. The MFC below and other buses in other
 DTS share opps. How about changing the binding so multiple clocks could
 be specified at once ("bus0", "bus1")? I think there is no need for a
 bus device for each clock.
>>>
>>> The your commented method is possible.
>>>
>>> But, I focus on implementing the generic bus frequency driver.
>>>
>>> If specific bus device-tree node includes the one more clocks,
>>> when adding the new Exynos SoC, the exynos-bus.c should be added
>>> for new Exynos SoC. Because, each Exynos SoC has the different
>>> set of bus device.
>>>
>>> If we use my approach, we don't need to modify the exynos-bus.c
>>> driver to support for the bus frequency of new Exynos SoC.
>>
>> This won't change. The driver will just support from 1 to N clocks for
>> given bus device and set the same OPP to all of them. This will only
>> limit the number of duplicated entries. This won't affect the generic
>> approach of driver itself.
> 
> You're right aspect of only implementation of device driver.
> 
> But,
> If we use your commented approach, we can show the information
> of only parent device through sysfs. We cannot see the information
> of passive device. The some information includes the current
> frequency and correlation of parent device. (But, current patchset
> don' include the topology information between parent device and
> passive device. I'll do it on later patches).
> 
> For example, 
> We can see the following bus device through /sys/class/devfreq.
> 
> drwxr-xr-x  2 root root 0 Dec 31 17:00 .
> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_display -> 
> ../../devices/platform/bus_display/devfreq/bus_display
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_fsys -> 
> ../../devices/platform/bus_fsys/devfreq/bus_fsys
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_leftbus -> 
> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_peri -> 
> ../../devices/platform/bus_peri/devfreq/bus_peri
> 
> 
> We don't see the following bus device because of following bus device
> has the same frequency table with bus_leftbus device.
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_mfc -> 
> ../../devices/platform/bus_mfc/devfreq/bus_mfc
> lrwxrwxrwx  1 root root 0 Dec 31 17:00 bus_rightbus -> 
> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus

Right, but why do you want to see these bus devices? AFAIU, they will
always behave exactly the same as LEFTBUS. Their PPMU counters will be
the same... or not? The MFC does not have its own PPMU counter. There
are separate counters for left and right bus... but they are attached to
the "_leftbus" node. The "_rightbus" does not use the PPMU
counter and it follows the parent governor decisions... so this is
purely an artificial creation just to handle one clock.

I just can't see the benefit of such additional bus device.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH v2 18/19] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3

[Krzysztof Kozlowski]

On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch expands the voltage range of buck1/3 regulator due to as following:
> - MIF (Memory Interface) bus frequency needs the 9uV ~ 105uV V.
> - INT (Internal) bus frequency needs 9uV ~ 100uV.

9->90 and duplicated "uV V". Maybe just:
900 - 1050 mV
900 - 1000 mV
?

> 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

For the contents of patch:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


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

Re: [PATCH v2 12/19] ARM: dts: Add bus nodes using VDD_INT for Exynos3250

[Chanwoo Choi]

On 2015년 12월 10일 11:09, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
>> Exynos3250 has following AXI buses to translate data between
>> DRAM and sub-blocks.
>>
>> Following list specifies the detailed relation between DRAM and sub-blocks:
>> - ACLK400 clock for MCUISP
>> - ACLK266 clock for ISP
>> - ACLK200 clock for FSYS
>> - ACLK160 clock for LCD0
>> - ACLK100 clock for PERIL
>> - GDL clock for LEFTBUS
>> - GDR clock for RIGHTBUS
>> - SCLK_MFC clock for MFC
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  arch/arm/boot/dts/exynos3250.dtsi | 160 
>> ++
>>  1 file changed, 160 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> index 7214c5e42150..46dee1951ec1 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -721,6 +721,166 @@
>>  opp-microvolt = <875000>;
>>  };
>>  };
>> +
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_GDR>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_lcd0: bus_lcd0 {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_ACLK_160>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_fsys: bus_fsys {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_ACLK_200>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_mcuisp: bus_mcuisp {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_ACLK_400_MCUISP>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_mcuisp_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_isp: bus_isp {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_ACLK_266>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_isp_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_peril: bus_peril {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_DIV_ACLK_100>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_peril_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_mfc: bus_mfc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = < CLK_SCLK_MFC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_leftbus_opp_table: opp_table2 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <5000>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <8000>;
>> +opp-microvolt = <90>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <100>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <100>;
>> +};
>> +opp04 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <100>;
>> +};
>> +};
>> +
>> +bus_mcuisp_opp_table: opp_table3 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> 

Re: [PATCH v2 03/22] drm/exynos: gsc: add device tree support and remove usage of static mappings

[Inki Dae]

CCing Mr. Kukjin and Krzysztof


Hi Kukjin and Krzysztof,

Below patch includes dt binding about gsc device but it'd be nice this patch to 
exynos drm tree with others.
So could you give me Acked-by so that I can merge it to exynos drm tree?

Thanks,
Inki Dae

2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
> From: Seung-Woo Kim 
> 
> This patch adds device tree support for exynos_drm_gsc. This patch
> also fixed build issue on non-Exynos platforms, thus dependency on
> !ARCH_MULTIPLATFORM can be now removed. The driver cannot be used
> simultaneously with V4L2 Mem2Mem GScaller driver thought.
> 
> Signed-off-by: Seung-Woo Kim 
> [updated commit message, removed the need for wb-lcd property, because
> all gscallers have support for lcd writeback, replaced dependency on
> !ARCH_MULTIPLATFORM with !VIDEO_SAMSUNG_EXYNOS_GSC]
> Signed-off-by: Marek Szyprowski 
> ---
>  .../devicetree/bindings/media/exynos5-gsc.txt  |  4 +++
>  drivers/gpu/drm/exynos/Kconfig |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c| 30 
> +++---
>  drivers/gpu/drm/exynos/regs-gsc.h  |  4 +--
>  4 files changed, 33 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
> b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> index 0604d42f38d1..5fe9372abb37 100644
> --- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> +++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> @@ -7,6 +7,10 @@ Required properties:
>  - reg: should contain G-Scaler physical address location and length.
>  - interrupts: should contain G-Scaler interrupt number
>  
> +Optional properties:
> +- samsung,sysreg: handle to syscon used to control the system registers to
> +  set writeback input and destination
> +
>  Example:
>  
>  gsc_0:  gsc@0x13e0 {
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 96e86cf4455b..83efca941388 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -118,7 +118,7 @@ config DRM_EXYNOS_ROTATOR
>  
>  config DRM_EXYNOS_GSC
>   bool "GScaler"
> - depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !ARCH_MULTIPLATFORM
> + depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !VIDEO_SAMSUNG_EXYNOS_GSC
>   help
> Choose this option if you want to use Exynos GSC for DRM.
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index ed55d37b6330..7aecd23cfa11 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -15,7 +15,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -126,6 +127,7 @@ struct gsc_capability {
>   * @ippdrv: prepare initialization using ippdrv.
>   * @regs_res: register resources.
>   * @regs: memory mapped io registers.
> + * @sysreg: handle to SYSREG block regmap.
>   * @lock: locking of operations.
>   * @gsc_clk: gsc gate clock.
>   * @sc: scaler infomations.
> @@ -138,6 +140,7 @@ struct gsc_context {
>   struct exynos_drm_ippdrvippdrv;
>   struct resource *regs_res;
>   void __iomem*regs;
> + struct regmap   *sysreg;
>   struct mutexlock;
>   struct clk  *gsc_clk;
>   struct gsc_scaler   sc;
> @@ -437,9 +440,12 @@ static int gsc_sw_reset(struct gsc_context *ctx)
>  
>  static void gsc_set_gscblk_fimd_wb(struct gsc_context *ctx, bool enable)
>  {
> - u32 gscblk_cfg;
> + unsigned int gscblk_cfg;
>  
> - gscblk_cfg = readl(SYSREG_GSCBLK_CFG1);
> + if (!ctx->sysreg)
> + return;
> +
> + regmap_read(ctx->sysreg, SYSREG_GSCBLK_CFG1, _cfg);
>  
>   if (enable)
>   gscblk_cfg |= GSC_BLK_DISP1WB_DEST(ctx->id) |
> @@ -448,7 +454,7 @@ static void gsc_set_gscblk_fimd_wb(struct gsc_context 
> *ctx, bool enable)
>   else
>   gscblk_cfg |= GSC_BLK_PXLASYNC_LO_MASK_WB(ctx->id);
>  
> - writel(gscblk_cfg, SYSREG_GSCBLK_CFG1);
> + regmap_write(ctx->sysreg, SYSREG_GSCBLK_CFG1, gscblk_cfg);
>  }
>  
>  static void gsc_handle_irq(struct gsc_context *ctx, bool enable,
> @@ -1663,6 +1669,15 @@ static int gsc_probe(struct platform_device *pdev)
>   if (!ctx)
>   return -ENOMEM;
>  
> + if (dev->of_node) {
> + ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
> + "samsung,sysreg");
> + if (IS_ERR(ctx->sysreg)) {
> + dev_warn(dev, "failed to get system register.\n");
> + ctx->sysreg = NULL;
> + }
> + }
> +
>   /* clock control */
>   ctx->gsc_clk = devm_clk_get(dev, "gscl");
>   if (IS_ERR(ctx->gsc_clk)) {
> @@ -1796,6 +1811,12 @@ static const struct dev_pm_ops gsc_pm_ops = {
>   

Re: [PATCH v2 2/7] ARM: dts: exynos4412-odroid*: enable MFC device

[Krzysztof Kozlowski]

On 09.12.2015 22:58, Marek Szyprowski wrote:
> Enable support for Multimedia Codec (MFC) device for all Exynos4412-based
> Odroid boards.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index edf0fc8..5825abf 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -18,6 +18,24 @@
>   stdout-path = _1;
>   };
>  
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mfc_left: region@7700 {
> + compatible = "shared-dma-pool";
> + reusable;
> + reg = <0x7700 0x100>;

Doesn't this exceed the memory of Odroid X?

For other Exynos4412 boards the length is 0x80. I am curious: any
particular reason for the difference?

Best regards,
Krzysztof

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

Re: [PATCH v2 2/7] ARM: dts: exynos4412-odroid*: enable MFC device

[Krzysztof Kozlowski]

On 10.12.2015 16:44, Krzysztof Kozlowski wrote:
> On 09.12.2015 22:58, Marek Szyprowski wrote:
>> Enable support for Multimedia Codec (MFC) device for all Exynos4412-based

... and one more finding: I think the abbreviation is Multi Format Codec.

BR,
Krzysztof

>> Odroid boards.
>>
>> Signed-off-by: Marek Szyprowski 
>> ---
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 
>> 
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index edf0fc8..5825abf 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -18,6 +18,24 @@
>>  stdout-path = _1;
>>  };
>>  
>> +reserved-memory {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +mfc_left: region@7700 {
>> +compatible = "shared-dma-pool";
>> +reusable;
>> +reg = <0x7700 0x100>;
> 
> Doesn't this exceed the memory of Odroid X?
> 
> For other Exynos4412 boards the length is 0x80. I am curious: any
> particular reason for the difference?
> 
> Best regards,
> Krzysztof
> 
> 

--
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 004/182] gpio: generic: factor into gpio_chip struct

[Tony Lindgren]

* Linus Walleij  [151209 05:14]:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
...

> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.

For omap:

Acked-by: Tony Lindgren 
--
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