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

[Rob Herring]

On Wed, Dec 16, 2015 at 9:37 AM, Marek Szyprowski
 wrote:
> 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 
> ---
>  .../bindings/reserved-memory/reserved-memory.txt   |   2 +
>  .../devicetree/bindings/resource-names.txt |   1 +
>  drivers/of/of_reserved_mem.c   | 104 
> +
>  include/linux/of_reserved_mem.h|  31 +-
>  4 files changed, 115 insertions(+), 23 deletions(-)
>
> diff --git 
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index 3da0ebdba8d9..43a14957fd64 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -74,6 +74,8 @@ Regions in the /reserved-memory node may be referenced by 
> other device
>  nodes by adding a memory-region property to the device node.
>
>  memory-region (optional) - phandle, specifier pairs to children of 
> /reserved-memory
> +memory-region-names (optional) - supplemental names property, provide array 
> of
> +names to identify memory regions
>
>  Example
>  ---
> diff --git a/Documentation/devicetree/bindings/resource-names.txt 
> b/Documentation/devicetree/bindings/resource-names.txt
> index e280fef6f265..51823e99b983 100644
> --- a/Documentation/devicetree/bindings/resource-names.txt
> +++ b/Documentation/devicetree/bindings/resource-names.txt
> @@ -12,6 +12,7 @@ Resource Property Supplemental Names Property
>  regreg-names
>  clocks clock-names
>  interrupts interrupt-names
> +memory-region  memory-region-names

The other cases of *-names should correspond to actual h/w names for a
h/w block. memory-regions are not really h/w. So I'd prefer to not add
memory-region-names. If you want a name for the region, put it in the
region node. The name for each client node is not going to be
different.

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

Re: [PATCH 1/3] Device tree binding documentation for gpio-switch

[Rob Herring]

On Mon, Dec 14, 2015 at 8:28 AM, Linus Walleij <linus.wall...@linaro.org> wrote:
> On Fri, Dec 11, 2015 at 3:06 PM, Rob Herring <robh...@kernel.org> wrote:
>> On Fri, Dec 11, 2015 at 6:39 AM, Linus Walleij <linus.wall...@linaro.org> 
>> wrote:
>>> On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
>>> <martyn.we...@collabora.co.uk> wrote:

[...]

>>> Markus Pargmann also did a series that add initial values to
>>> hogs, which is the inverse usecase of this, where you want to
>>> *output* something by default, then maybe also make it available
>>> to userspace.
>>>
>>> So what we need to see here is a patch series that does all of these
>>> things:
>>>
>>> - Name lines
>>>
>>> - Sets them to initial values
>>>
>>> - Mark them as read-only
>>>
>>> - Mark them as "not used by the operating system" so that they
>>>   can be default-exported to userspace.
>>
>> No! This should not be a DT property.
>>
>> Whether I want to control a GPIO in the kernel or userspace is not
>> known and can change over time. It could simply depend on kernel
>> config. There is also the case that a GPIO has no connection or kernel
>> driver until some time later when a DT overlay for an expansion board
>> is applied.
>
> That's correct. So from a DT point of view, what really matters is
> to give things a name, and the hogs and initvals syntax already
> has a structure for this that is in use
> (from Documentation/devicetree/bindings/gpio/gpio.txt):
>
> qe_pio_a: gpio-controller@1400 {
> compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
> reg = <0x1400 0x18>;
> gpio-controller;
> #gpio-cells = <2>;
>
> line_b {
> gpio-hog;
> gpios = <6 0>;
> output-low;
> line-name = "foo-bar-gpio";
> };
> };
>
> Markus use this also for initial values. That could easily be used in
> a budget version like this:
>
> line_b {
> /* Just naming */
> gpios = <6 0>;
> line-name = "foo-bar-gpio";
> };
>
> That could grow kind of big though. Or maybe not? How many
> GPIO lines are actually properly named in a typical system?

We should limit it to GPIOs with no connection to another node. For
example, I don't want to see a SD card detect in the list as that
should be in the SD host node. However, that is hard to enforce and
can change over time. Removing it would break userspace potentially.
Of course if the kernel starts own a signal that userspace used, then
that potentially breaks userspace regardless of the DT changing. OTOH,
using GPIOs in userspace is kind of use at your own risk.

The only real differences between this and Martyn's proposal are the
location of the nodes and having a compatible string. A compatible
string may be good to have. It indicates type of signal, but not
specific use. Similar to how gpio-key compatible defines the function,
but not what key code, or gpio-led does not say what color LED. A
compatible here could cover switches, mode/id/revision strapping
signals, jumpers, presence detect, etc.

> The problem is that naming is usually imposed by consumers (they
> are the ones who know how the line is used).
>
> And then I do not mean naming it after the pin on the capsule
> where it comes out as per the datasheet, but
> naming it after the actual use.

Right. We need a way to query "I need the GPIO that does X" which
works across boards.

> Naming it after the hardware specs is something the operating
> system can do, in Linux' case by the array char *names; inside the
> struct gpio_chip and should not be part of the bindings IMO.

Agreed. That just came up with STM32 gpio bindings[1].

> I would rather imagine this is something used in a top-level board
> file naming it: "header-2-22" for the 22nd pin on some second header
> on my BeagleBone Black or something like that. And those may not
> be so vast in numbers so they could be named using this pattern.

Exactly. This is one of the cases I care about. However, this is not
really a function, but it is SOC independent at least.

We also have to consider how to handle add-on boards. We probably need
a connector node which can remap connector signals to host signals in
order to have overlays independent of the host board DT. For GPIOs
this is probably a gpio-map property similar to interrupt-map. The
complicated part will be connectors that require pinmux setup of the
host.

Rob

[1] https://lkml.org/lkml/2015/12/11/600
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Device tree binding documentation for gpio-switch

[Rob Herring]

On Fri, Dec 11, 2015 at 6:39 AM, Linus Walleij  wrote:
> On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
>  wrote:
>
>> This patch adds documentation for the gpio-switch binding. This binding
>> provides a mechanism to bind named links to gpio, with the primary
>> purpose of enabling standardised access to switches that might be standard
>> across a group of devices but implemented differently on each device.
>>
>> Signed-off-by: Martyn Welch 
>
> As mentioned in the comment to the second patch, this solves the
> following generic problem:
>
> Expose a GPIO line to userspace using a specific name
>
> That means basically naming GPIO lines and marking them as
> "not used by the operating system".
>
> This is something that has been proposed before, and postponed
> because the kernel lacks the right infrastructure.

That doesn't necessarily mean we can't define a binding.

> Markus Pargmann also did a series that add initial values to
> hogs, which is the inverse usecase of this, where you want to
> *output* something by default, then maybe also make it available
> to userspace.
>
> So what we need to see here is a patch series that does all of these
> things:
>
> - Name lines
>
> - Sets them to initial values
>
> - Mark them as read-only
>
> - Mark them as "not used by the operating system" so that they
>   can be default-exported to userspace.

No! This should not be a DT property.

Whether I want to control a GPIO in the kernel or userspace is not
known and can change over time. It could simply depend on kernel
config. There is also the case that a GPIO has no connection or kernel
driver until some time later when a DT overlay for an expansion board
is applied.

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

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

[Rob Herring]

On Fri, Dec 11, 2015 at 12:10:13AM +0900, Chanwoo Choi wrote:
> On Thu, Dec 10, 2015 at 11:21 PM, Rob Herring <r...@kernel.org> wrote:
> > On Wed, Dec 09, 2015 at 01:08:01PM +0900, Chanwoo Choi wrote:
> >> This patch updates the documentation for passive bus devices and adds the
> >> detailed example of Exynos3250.
> >>
> >> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> >> ---
> >>  .../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:
> >>  - 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:
> >> +- 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
> >
> > This still has the same problem as before. I would expect that the bus
> > hierarchy in the dts match the hierarchy here. You just have flat nodes
> > in the example below. So all IP blocks affected by frequency scaling
> > should be under the bus node defining the OPPs. Something like this:
> 
> The each bus of sub-block has not h/w dependency among sub-blocks
> and has the owned source clock / OPP table. Just they share the same
> power line. So, I think that flat nodes in the example below is not problem.

I'm talking about the peripherals not described here. Is the ISP block 
not a child of the bus_isp node? Same for the display controller block 
and bus_lcd0. And so on.

Rob

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

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

[Rob Herring]

On Wed, Dec 09, 2015 at 01:08:01PM +0900, 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:
>  - 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:
> +- 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

This still has the same problem as before. I would expect that the bus 
hierarchy in the dts match the hierarchy here. You just have flat nodes 
in the example below. So all IP blocks affected by frequency scaling 
should be under the bus node defining the OPPs. Something like this:

soc {
compatible = "simple-bus";
bus {
compatible = "my-awesome-dvfs-bus"; /* simple-bus too if 
no setup needed first */
reg = <0x0 0x0>; // Bus control registers
clocks = < BUS_CLK>;
operating-points-v2 = <>;
device@0 {
compatible = "my-awesome-device-1";
};
device@1 {
compatible = "my-awesome-device-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

[Rob Herring]

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.

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

> +
>  /**
>   * 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 given device.
>   */
>  void of_reserved_mem_device_release(struct device *dev)
>  {
> -   struct reserved_mem *rmem;
> -   struct device_node *np;
> -
> -   np = 

Re: [PATCH v10 08/17] dt-bindings: add document for rockchip variant of analogix_dp

[Rob Herring]

On Mon, Dec 07, 2015 at 02:39:34PM +0800, Yakir Yang wrote:
> Rockchip DP driver is a helper driver of analogix_dp coder driver,
> so most of the DT property should be descriped in analogix_dp document.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> Reviewed-by: Heiko Stuebner <he...@sntech.de>

I already acked the previous v10 you sent.

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Changes in v10: None
> Changes in v9:
> - Document more details for 'ports' property.
> 
> Changes in v8:
> - Modify the commit subject name. (Heiko)
> 
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Add eDP hotplug pinctrl property. (Heiko)
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  .../display/rockchip/analogix_dp-rockchip.txt  | 91 
> ++
>  1 file changed, 91 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> new file mode 100644
> index 000..dae86c4
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> @@ -0,0 +1,91 @@
> +Rockchip RK3288 specific extensions to the Analogix Display Port
> +
> +
> +Required properties:
> +- compatible: "rockchip,rk3288-edp";
> +
> +- reg: physical base address of the controller and length
> +
> +- clocks: from common clock binding: handle to dp clock.
> +   of memory mapped region.
> +
> +- clock-names: from common clock binding:
> +Required elements: "dp" "pclk"
> +
> +- resets: Must contain an entry for each entry in reset-names.
> +   See ../reset/reset.txt for details.
> +
> +- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
> +- pinctrl-0: pin-control mode. should be <_hpd>
> +
> +- reset-names: Must include the name "dp"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +
> +- ports: there are 2 port nodes with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +Port 0: contained 2 endpoints, connecting to the ouput of vop.
> +Port 1: contained 1 endpoint, connecting to the input of panel.
> +
> +For the below properties, please refer to Analogix DP binding document:
> + * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> +- phys (required)
> +- phy-names (required)
> +- hpd-gpios (optional)
> +---
> +
> +Example:
> + dp-controller: dp@ff97 {
> + compatible = "rockchip,rk3288-dp";
> + reg = <0xff97 0x4000>;
> + interrupts = ;
> + clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
> + clock-names = "dp", "pclk";
> + phys = <_phy>;
> + phy-names = "dp";
> +
> + rockchip,grf = <>;
> + resets = < 111>;
> + reset-names = "dp";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_hpd>;
> +
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + edp_in: port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + edp_in_vopb: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_out_edp>;
> + };
> + edp_in_vopl: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_out_edp>;
> + };
> + };
> +
> + edp_out: port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + edp_out_panel: endpoint {
> + reg = <0>;
> + remote-endpoint = <_in_edp>
> + };
> + };
> + };
> + };
> +
> + pinctrl {
> + edp {
> + edp_hpd: edp-hpd {
> + rockchip,pins = <7 11 RK_FUNC_2 
> _pull_none>;
> + };
> + };
> + };
> -- 
> 1.9.1
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 10/17] dt-bindings: add document for rockchip dp phy

[Rob Herring]

On Mon, Dec 07, 2015 at 02:39:50PM +0800, Yakir Yang wrote:
> Add dt binding documentation for rockchip display port PHY.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> Reviewed-by: Heiko Stuebner <he...@sntech.de>

One possible typo below, otherwise:

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Changes in v10: None
> Changes in v9: None
> Changes in v8:
> - Remove the specific address in the example node name. (Heiko)
> 
> Changes in v7:
> - Simplify the commit message. (Kishon)
> 
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Update the rockchip,grf explain in document, and correct the clock required
>   elemets in document. (Rob & Heiko)
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..00902cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,22 @@
> +Rockchip Soc Seroes Display Port PHY
   ^
Is this supposed to be SerDes?

> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> +  - "rockchip.rk3288-dp-phy"
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "24m"
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: edp-phy {
> + compatible = "rockchip,rk3288-dp-phy";
> + rockchip,grf = <>;
> + clocks = < SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +};
> -- 
> 1.9.1
> 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 05/17] dt-bindings: add document for analogix display port driver

[Rob Herring]

On Mon, Dec 07, 2015 at 02:39:07PM +0800, Yakir Yang wrote:
> Analogix dp driver is split from exynos dp driver, so we just
> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
> 
> Beside update some exynos dtsi file with the latest change
> according to the devicetree binding documents.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Changes in v10: None
> Changes in v9: None
> Changes in v8:
> - Correct the right document path of display-timing.txt (Heiko)
> - Correct the misspell of 'from' to 'frm'. (Heiko)
> 
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Split all DTS changes, and provide backward compatibility. Mark old
>   properties as deprecated but still support them. (Krzysztof)
> - Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
> - Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
> "analogix,color-space" & "analogix,color-depth"   &
> "analogix,link-rate"   & "analogix,lane-count"&
> "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
> "vsync-active-high"& "hsync-active-high"  & "interlaces"
> 
> Changes in v3:
> - Add devicetree binding documents. (Heiko)
> - Remove sync pol & colorimetry properies from the new analogix dp driver
>   devicetree binding. (Thierry)
> - Update the exist exynos dtsi file with the latest DP DT properies.
> 
> Changes in v2: None
> 
>  .../bindings/display/bridge/analogix_dp.txt| 50 +
>  .../bindings/display/exynos/exynos_dp.txt  | 65 
> --
>  2 files changed, 72 insertions(+), 43 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> new file mode 100644
> index 000..7659a7a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> @@ -0,0 +1,50 @@
> +Analogix Display Port bridge bindings
> +
> +Required properties for dp-controller:
> + -compatible:
> + platform specific such as:
> +  * "samsung,exynos5-dp"
> +  * "rockchip,rk3288-dp"
> + -reg:
> + physical base address of the controller and length
> + of memory mapped region.
> + -interrupts:
> + interrupt combiner values.
> + -clocks:
> + from common clock binding: handle to dp clock.
> + -clock-names:
> + from common clock binding: Shall be "dp".
> + -interrupt-parent:
> + phandle to Interrupt combiner node.
> + -phys:
> + from general PHY binding: the phandle for the PHY device.
> + -phy-names:
> + from general PHY binding: Should be "dp".
> +
> +Optional properties for dp-controller:
> + -hpd-gpios:
> + Hotplug detect GPIO.
> + Indicates which GPIO should be used for hotplug detection
> + -port@[X]: SoC specific port nodes with endpoint definitions as defined
> + in Documentation/devicetree/bindings/media/video-interfaces.txt,
> + please refer to the SoC specific binding document:
> + * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> + * 
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> +
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +---
> +
> +Example:
> +
> + dp-controller {
> + compatible = "samsung,exynos5-dp";
> + reg = <0x145b 0x1>;
> + interrupts = <10 3>;
> + interrupt-parent = <>;
> + clocks = < 342>;
> + clock-names = "dp";
> +
> + phys = <_phy>;
> + phy-names = "dp";
> + };
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 64693f2..9905081 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -31,45 +31,31 @@ Re

Re: [PATCH v2 3/4] dt-bindings: exynos-dp: update ports node binding for panel

[Rob Herring]

On Mon, Dec 07, 2015 at 09:52:37PM +0900, Inki Dae wrote:
> This patch updates a ports node binding for panel.
> 
> With this, dp node can have a ports node which describes
> a remote endpoint node that can be connected to panel or bridge
> node.
> 
> Changelog v2:
> - remove unnecessary properties and numbering.
> - update description about eDP device.
> 
> Signed-off-by: Inki Dae <inki@samsung.com>
> Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../bindings/display/exynos/exynos_dp.txt  | 41 
> +++---
>  1 file changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 64693f2..22efeba 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -1,3 +1,20 @@
> +Device-Tree bindings for Samsung Exynos Embedded DisplayPort Transmitter(eDP)
> +
> +DisplayPort is industry standard to accommodate the growing board adoption
> +of digital display technology within the PC and CE industries.
> +It consolidates the internal and external connection methods to reduce device
> +complexity and cost. It also supports necessary features for important cross
> +industry applications and provides performance scalability to enable the next
> +generation of displays that feature higher color depths, refresh rates, and
> +display resolutions.
> +
> +eDP (embedded display port) device is compliant with Embedded DisplayPort
> +standard as follows,
> +- DisplayPort standard 1.1a for Exynos5250 and Exynos5260.
> +- DisplayPort standard 1.3 for Exynos5422s and Exynos5800.
> +
> +eDP resides between FIMD and panel or FIMD and bridge such as LVDS.
> +
>  The Exynos display port interface should be configured based on
>  the type of panel connected to it.
>  
> @@ -66,8 +83,15 @@ Optional properties for dp-controller:
>   Hotplug detect GPIO.
>   Indicates which GPIO should be used for hotplug
>   detection
> - -video interfaces: Device node can contain video interface port
> - nodes according to [1].
> +Video interfaces:
> +  Device node can contain video interface port nodes according to [1].
> +  The following are properties specific to those nodes:
> +
> +  endpoint node connected to bridge or panel node:
> +   - remote-endpoint: specifies the endpoint in panel or bridge node.
> +   This node is required in all kinds of exynos dp
> +   to represent the connection between dp and bridge
> +   or dp and panel.
>  
>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> @@ -111,9 +135,18 @@ Board Specific portion:
>   };
>  
>   ports {
> - port@0 {
> + port {
>   dp_out: endpoint {
> - remote-endpoint = <_in>;
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +
> + panel {
> + ...
> + port {
> + dp_in: endpoint {
> + remote-endpoint = <_out>;
>   };
>   };
>   };
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10.1 14/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Rob Herring]

On Wed, Dec 09, 2015 at 10:10:39AM +0800, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
> 
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Changes in v10.1:
> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
> 
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>   hpd when hpd detect failed.
> 
> Changes in v2: None
> 
>  .../bindings/display/bridge/analogix_dp.txt|  4 ++-
>  .../bindings/display/exynos/exynos_dp.txt  |  1 +
>  .../display/rockchip/analogix_dp-rockchip.txt  |  1 +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 
> ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
>  6 files changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> index 7659a7a..4f2ba8c 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> @@ -22,6 +22,9 @@ Required properties for dp-controller:
>   from general PHY binding: Should be "dp".
>  
>  Optional properties for dp-controller:
> + -force-hpd:
> + Indicate driver need force hpd when hpd detect failed, this
> + is used for some eDP screen which don't have hpd signal.
>   -hpd-gpios:
>   Hotplug detect GPIO.
>   Indicates which GPIO should be used for hotplug detection
> @@ -31,7 +34,6 @@ Optional properties for dp-controller:
>   * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>   * 
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>  
> -
>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> ---
>  
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 9905081..8800164 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP 
> binding document:
>   -phys (required)
>   -phy-names (required)
>   -hpd-gpios (optional)
> + -analogix,need-force-hpd (optional)
>   -video interfaces (optional)
>  
>  Deprecated properties for DisplayPort:
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> index dae86c4..187a708e 100644
> --- 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> @@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP 
> binding document:
>  - phys (required)
>  - phy-names (required)
>  - hpd-gpios (optional)
> +- force-hpd (optional)
>  
> ---
>  
>  Example:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index a11504b..00aee44 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct 
> analogix_dp_device *dp)
>  {
>   int timeout_loop = 0;
>  
> - while (analogix_dp_get_plug_in_status(dp) != 0) {
> + while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
> + if (analogix_dp_get_plug_in_status(dp) == 0)
> + return 0;
> +
>   timeout_loop++;
> - if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
> - dev_err(dp->dev, "failed to get hpd plug status\n");
> - return -ETIMED

Re: [PATCH 1/3] Device tree binding documentation for gpio-switch

[Rob Herring]

+Linus W

On Fri, Dec 04, 2015 at 05:31:13PM +, Martyn Welch wrote:
> This patch adds documentation for the gpio-switch binding. This binding
> provides a mechanism to bind named links to gpio, with the primary
> purpose of enabling standardised access to switches that might be standard
> across a group of devices but implemented differently on each device.

This is good and what I suggested, but it now makes me wonder if switch 
is generic enough. This boils down to needing to expose single gpio 
lines to userspace with a defined function/use. IIRC, there's been some 
discussion about this before along with improving the userspace 
interface for GPIO in general. So I'd like to get Linus' thoughts on 
this.


> Signed-off-by: Martyn Welch 
> ---
>  .../devicetree/bindings/misc/gpio-switch.txt   | 47 
> ++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/gpio-switch.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/gpio-switch.txt 
> b/Documentation/devicetree/bindings/misc/gpio-switch.txt
> new file mode 100644
> index 000..13528bd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/gpio-switch.txt
> @@ -0,0 +1,47 @@
> +Device-Tree bindings for gpio attached switches.
> +
> +This provides a mechanism to provide a named link to specified gpios. This 
> can
> +be useful in instances such as when theres a need to monitor a switch, which 
> is
> +common across a family of devices, but attached to different gpios and even
> +implemented in different ways on differnet devices.
> +
> +Required properties:
> + - compatible = "gpio-switch";
> +
> +Each signal is represented as a sub-node of "gpio-switch". The naming of
> +sub-nodes is arbitrary.
> +
> +Required sub-node properties:
> +
> + - label: Name to be given to gpio switch.
> + - gpios: OF device-tree gpio specification.
> +
> +Optional sub-node properties:
> +
> + - read-only: Boolean flag to mark the gpio as read-only, i.e. the line
> +   should not be driven by the host.

In terms a a switch use, allowing driving it would be an override of the 
switch. Is that the idea here?

> +
> +Example nodes:
> +
> +gpio-switch {
> +compatible = "gpio-switch";

Both from a binding and driver perspective, there is no point in 
grouping these. Each node can simply have this compatible string.

> +
> +write-protect {
> +label = "write-protect";
> +gpios = < 0 GPIO_ACTIVE_LOW>;
> +read-only;
> +};
> +
> +developer-switch {
> +label = "developer-switch";
> +gpios = < 3 GPIO_ACTIVE_HIGH>;
> +read-only;
> +};
> +
> +recovery-switch {
> +label = "recovery-switch";
> +gpios = < 7 GPIO_ACTIVE_LOW>;
> +read-only;
> +};
> +};
> +
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] dt-bindings: regulator/mfd: Reorganize S2MPA01 bindings

[Rob Herring]

On Fri, Dec 04, 2015 at 10:10:05AM +0900, Krzysztof Kozlowski wrote:
> The mfd/s2mpa01.txt duplicates some of the information about bindings
> with old mfd/s2mps11.txt. Now common part exists entirely in
> mfd/samsung,sec-core.txt so:
>  - add company prefix to file name (regulator/samsung,s2mpa01.txt),
>  - remove duplicated information,
>  - reorganize the contents to match style of
>regulator/samsung,s2mps11.txt.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Next time, use git format-patch -M option.

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  Documentation/devicetree/bindings/mfd/s2mpa01.txt  | 90 
> --
>  .../devicetree/bindings/mfd/samsung,sec-core.txt   |  4 +-
>  .../bindings/regulator/samsung,s2mpa01.txt | 79 +++
>  3 files changed, 82 insertions(+), 91 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/mfd/s2mpa01.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt 
> b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> deleted file mode 100644
> index c13d3d8c3947..
> --- a/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> +++ /dev/null
> @@ -1,90 +0,0 @@
> -
> -* Samsung S2MPA01 Voltage and Current Regulator
> -
> -The Samsung S2MPA01 is a multi-function device which includes high
> -efficiency buck converters including Dual-Phase buck converter, various LDOs,
> -and an RTC. It is interfaced to the host controller using an I2C interface.
> -Each sub-block is addressed by the host system using different I2C slave
> -addresses.
> -
> -Required properties:
> -- compatible: Should be "samsung,s2mpa01-pmic".
> -- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
> -
> -Optional properties:
> -- interrupt-parent: Specifies the phandle of the interrupt controller to 
> which
> -  the interrupts from s2mpa01 are delivered to.
> -- interrupts: An interrupt specifier for the sole interrupt generated by the
> -  device.
> -
> -Optional nodes:
> -- regulators: The regulators of s2mpa01 that have to be instantiated should 
> be
> -  included in a sub-node named 'regulators'. Regulator nodes and constraints
> -  included in this sub-node use the standard regulator bindings which are
> -  documented elsewhere.
> -
> -Properties for BUCK regulator nodes:
> -- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500
> -  (default), 25000, or 5. May be 0 for disabling the ramp delay on
> -  BUCK{1,2,3,4}.
> -
> - In the absence of the regulator-ramp-delay property, the default ramp
> - delay will be used.
> -
> -  NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be 
> set
> -  for a particular group of BUCKs. So provide same 
> regulator-ramp-delay=.
> -
> -  The following BUCKs share ramp settings:
> -  * 1 and 6
> -  * 2 and 4
> -  * 8, 9, and 10
> -
> -The following are the names of the regulators that the s2mpa01 PMIC block
> -supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
> -as per the datasheet of s2mpa01.
> -
> - - LDOn
> -   - valid values for n are 1 to 26
> -   - Example: LDO1, LD02, LDO26
> - - BUCKn
> -   - valid values for n are 1 to 10.
> -   - Example: BUCK1, BUCK2, BUCK9
> -
> -Example:
> -
> - s2mpa01_pmic@66 {
> - compatible = "samsung,s2mpa01-pmic";
> - reg = <0x66>;
> -
> - regulators {
> - ldo1_reg: LDO1 {
> - regulator-name = "VDD_ALIVE";
> - regulator-min-microvolt = <100>;
> - regulator-max-microvolt = <100>;
> - };
> -
> - ldo2_reg: LDO2 {
> - regulator-name = "VDDQ_MMC2";
> - regulator-min-microvolt = <280>;
> - regulator-max-microvolt = <280>;
> - regulator-always-on;
> - };
> -
> - buck1_reg: BUCK1 {
> - regulator-name = "vdd_mif";
> - regulator-min-microvolt = <95>;
> - regulator-max-microvolt = <135>;
> - regulator-always-on;
> - regulator-boot-on;
> -  

Re: [PATCH 2/3] dt-bindings: regulator/mfd: Reorganize S5M8767 bindings

[Rob Herring]

On Fri, Dec 04, 2015 at 10:10:04AM +0900, Krzysztof Kozlowski wrote:
> The regulator/s5m8767-regulator.txt duplicates some of the information
> about bindings with old mfd/s2mps11.txt. Now common part exists entirely
> in mfd/samsung,sec-core.txt so:
>  - add company prefix to file name (regulator/samsung,s5m8767.txt),
>  - remove duplicated information,
>  - reorganize the contents to match style of
>regulator/samsung,s2mps11.txt.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../devicetree/bindings/mfd/samsung,sec-core.txt   |   4 +-
>  .../bindings/regulator/s5m8767-regulator.txt   | 163 
> -
>  .../bindings/regulator/samsung,s5m8767.txt | 145 ++
>  MAINTAINERS|   2 +-
>  4 files changed, 149 insertions(+), 165 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt 
> b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
> index ef0166d0f643..4aeb95c82304 100644
> --- a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
> +++ b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
> @@ -14,6 +14,7 @@ addressed by the host system using different I2C slave 
> addresses.
>  This document describes bindings for main device node. Optional sub-blocks
>  must be a sub-nodes to it. Bindings for them can be found in:
>   - bindings/regulator/samsung,s2mps11.txt
> + - bindings/regulator/samsung,s5m8767.txt
>   - bindings/clock/samsung,s2mps11.txt
>  
>  
> @@ -23,7 +24,8 @@ Required properties:
>   - "samsung,s2mps13-pmic",
>   - "samsung,s2mps14-pmic",
>   - "samsung,s2mps15-pmic",
> - - "samsung,s2mpu02-pmic".
> + - "samsung,s2mpu02-pmic",
> + - "samsung,s5m8767-pmic".
>   - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
>  
>  Optional properties:
> diff --git 
> a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt 
> b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
> deleted file mode 100644
> index 20191315e444..
> --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
> +++ /dev/null
> @@ -1,163 +0,0 @@
> -* Samsung S5M8767 Voltage and Current Regulator
> -
> -The Samsung S5M8767 is a multi-function device which includes voltage and
> -current regulators, rtc, charger controller and other sub-blocks. It is
> -interfaced to the host controller using a i2c interface. Each sub-block is
> -addressed by the host system using different i2c slave address. This document
> -describes the bindings for 'pmic' sub-block of s5m8767.
> -
> -Required properties:
> -- compatible: Should be "samsung,s5m8767-pmic".
> -- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
> -
> -- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt 
> (uV)
> -  units for buck2 when changing voltage using gpio dvs. Refer to [1] below
> -  for additional information.
> -
> -- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt 
> (uV)
> -  units for buck3 when changing voltage using gpio dvs. Refer to [1] below
> -  for additional information.
> -
> -- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt 
> (uV)
> -  units for buck4 when changing voltage using gpio dvs. Refer to [1] below
> -  for additional information.
> -
> -- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used
> -  for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines.
> -
> -[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
> -property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage'
> -property should specify atleast one voltage level (which would be a
> -safe operating voltage).
> -
> -If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
> -property is specified, then all the eight voltage values for the
> -'s5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified.
> -
> -Optional properties:
> -- interrupt-parent: Specifies the phandle of the interrupt controller to 
> which
> -  the interrupts from s5m8767 are delivered to.
> -- interrupts: Interrupt specifiers for two interrupt sources.
> -  - First interrupt specifier is for 'irq1' interrupt.
> -  - Second interrupt specifier is for 'alert' interrupt.
&g

Re: [PATCH 1/3] dt-bindings: regulator/clock/mfd: Reorganize S2MPS-family bindings

[Rob Herring]

On Fri, Dec 04, 2015 at 10:10:03AM +0900, Krzysztof Kozlowski wrote:
> Bindings for Samsung S2M and S5M family PMICs are in mess. They are
> spread over different files and subdirectories in a non-consistent way.
> The devices and respective drivers for them share a lot in common so
> everything could be organized in a more readable way.
> 
> Reorganize the S2MPS11/13/14/15 Device Tree bindings to match the
> drivers for this family of devices:
>  - move mfd/s2mps11.txt to mfd/samsung,sec-core.txt for the main MFD
>driver (common for entire family),
>  - split clock block to clock/samsung,s2mps11.txt,
>  - split regulator block to regulator/samsung,s2mps11.txt.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../devicetree/bindings/clock/samsung,s2mps11.txt  |  49 +++
>  Documentation/devicetree/bindings/mfd/s2mps11.txt  | 153 
> -
>  .../devicetree/bindings/mfd/samsung,sec-core.txt   |  84 +++
>  .../bindings/regulator/samsung,s2mps11.txt | 102 ++
>  MAINTAINERS|   4 +-
>  5 files changed, 238 insertions(+), 154 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
>  delete mode 100644 Documentation/devicetree/bindings/mfd/s2mps11.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt 
> b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> new file mode 100644
> index ..2726c1d58a79
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> @@ -0,0 +1,49 @@
> +Binding for Samsung S2M and S5M family clock generator block
> +
> +
> +This is a part of device tree bindings for S2M and S5M family multi-function
> +devices.
> +More information can be found in bindings/mfd/sec-core.txt file.
> +
> +The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz
> +outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs.
> +
> +To register these as clocks with common clock framework instantiate under
> +main device node a sub-node named "clocks".
> +
> +It uses the common clock binding documented in:
> + - Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +
> +Required properties of the "clocks" sub-node:
> + - #clock-cells: should be 1.
> + - compatible: Should be one of: "samsung,s2mps11-clk", 
> "samsung,s2mps13-clk",
> +   "samsung,s2mps14-clk", "samsung,s5m8767-clk"
> +   The S2MPS15 uses the same compatible as S2MPS13, as both provides similar
> +   clocks.
> +
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +Clock   ID   Devices
> +--
> +32KhzAP  0S2MPS11/13/14/15, S5M8767
> +32KhzCP  1S2MPS11/13/15, S5M8767
> +32KhzBT  2S2MPS11/13/14/15, S5M8767
> +
> +Include dt-bindings/clock/samsung,s2mps11.h file to use preprocessor defines
> +in device tree sources.
> +
> +
> +Example:
> +
> + s2mps11_pmic@66 {
> + compatible = "samsung,s2mps11-pmic";
> + reg = <0x66>;
> +
> + s2m_osc: clocks {
> + compatible = "samsung,s2mps11-clk";
> + #clock-cells = <1>;
> + clock-output-names = "xx", "yy", "zz";
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> deleted file mode 100644
> index 09b94c97faac..
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ /dev/null
> @@ -1,153 +0,0 @@
> -
> -* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
> -
> -The Samsung S2MPS11 is a multi-function device which includes voltage and
> -current regulators, RTC, charger controller and other sub-blocks. It is
> -interfaced to the host controller using an I2C interface. Each sub-block is
> -addressed by the host system using different I2C slave addresses.
> -
> -Required properties:
> -- compatible: Should be one of the following
> - - "samsung,s2mps11-pmic"
> 

Re: [PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel

[Rob Herring]

On Wed, Dec 2, 2015 at 5:57 AM, Inki Dae  wrote:
> This patch adds of_graph dt binding support for panel device
> and also keeps the backward compatibility.
>
> i.e.,
> The dts file for Exynos5800 based peach pi board
> has a panel property so we need to keep the backward compatibility.
>
> Changelog v2:
> - return -EINVAL if getting a port node failed.
>
> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 94f02a0..0b53045 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
>  static int exynos_dp_probe(struct platform_device *pdev)
>  {
> struct device *dev = >dev;
> -   struct device_node *panel_node, *bridge_node, *endpoint;
> +   struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
> struct exynos_dp_device *dp;
> int ret;
>
> @@ -1403,15 +1403,32 @@ static int exynos_dp_probe(struct platform_device 
> *pdev)
>
> platform_set_drvdata(pdev, dp);
>
> +   /* This is for the backward compatibility. */
> panel_node = of_parse_phandle(dev->of_node, "panel", 0);
> if (panel_node) {
> dp->panel = of_drm_find_panel(panel_node);
> of_node_put(panel_node);
> if (!dp->panel)
> return -EPROBE_DEFER;
> +   } else {
> +   endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> +   if (endpoint) {
> +   panel_node = 
> of_graph_get_remote_port_parent(endpoint);
> +   if (panel_node) {
> +   dp->panel = of_drm_find_panel(panel_node);
> +   of_node_put(panel_node);
> +   if (!dp->panel)
> +   return -EPROBE_DEFER;
> +   } else {
> +   DRM_ERROR("no port node for panel device.\n");
> +   return -EINVAL;
> +   }
> +   }

This should be a fairly common sequence, so please make it one. Only
which port is the panel should vary.

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

Re: [PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel

[Rob Herring]

On Thu, Dec 03, 2015 at 06:30:10PM +0900, Inki Dae wrote:
> This patch updates a ports node binding for panel.
> 
> With this, dp node can have a ports node which describes
> a remote endpoint node that can be connected to panel or bridge
> node.
> 
> Signed-off-by: Inki Dae 
> ---
>  .../bindings/display/exynos/exynos_dp.txt  | 28 
> ++
>  1 file changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 64693f2..15b52cb 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
>   Hotplug detect GPIO.
>   Indicates which GPIO should be used for hotplug
>   detection
> - -video interfaces: Device node can contain video interface port
> - nodes according to [1].
> +Video interfaces:
> +  Device node can contain video interface port nodes according to [1].
> +  The following are properties specific to those nodes:
> +
> +  endpoint node connected to bridge or panel node:
> +   - remote-endpoint: specifies the endpoint in panel or bridge node.
> +   This node is required in all kinds of exynos dp
> +   to represent the connection between dp and bridge
> +   ,or dp and panel.

Fix your punctuation.

>  
>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> @@ -111,9 +118,22 @@ Board Specific portion:
>   };
>  
>   ports {
> - port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;

You don't need these.

> +
> + port {
>   dp_out: endpoint {
> - remote-endpoint = <_in>;
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +
> + panel@0 {
> + reg = <0>;

Drop the @0 and reg as you only have 1.

> + ...
> + port {
> + dp_in: endpoint {
> + remote-endpoint = <_out>;
>   };
>   };
>   };
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rob Herring]

On Thu, Nov 26, 2015 at 10:47:33PM +0900, 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 | 226 
> -
>  1 file changed, 223 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index 5d90623bd173..c4a6fe30075e 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -12,18 +12,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:
>  - 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:
> +- 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.
>  
> @@ -32,7 +37,19 @@ 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 block (dmc clock)
> + - MIF (Memory Interface) block
> + : VDD_MIF |--- DMC
> +
> + - INT (Internal) block
> + : VDD_INT |--- LEFTBUS  |--- PERIL
> +   |(parent) |--- MFC
> +   | |--- G3D
> +   |
> +   |--- RIGHTBUS |--- FSYS
> + |--- LCD0
> + |--- PERIR
> + |--- ISP
> + |--- CAM

I would expect the DT to mirror this topology which doesn't seem to be 
the case in the example.


>   - MIF bus's frequency/voltage table
>   ---
> @@ -45,6 +62,20 @@ Example1:
>   |L5| 40 |875000   |
>   ---
>  
> + - INT bus's frequency/voltage table
> + ---
> + |Lv| Freq   | Voltage |
> + ---
> + |  |LEFTBUS|RIGHTBUS|LCD0   |FSYS   |MCUISP |ISP|PERIL  |VDD_INT  |
> + |  |*parent|passive |passive|passive|passive|passive|passive| |
> + ---
> + |L1|5  |5   |5  |5  |5  |5  |5  |90   |
> + |L2|8  |8   |8  |8  |8  |8  |8  |90   |
> + |L3|10 |10  |10 |10 |10 |10 |10 |100  |
> + |L4|133000 |133000  |133000 |133000 |20 |20 |   |100  |
> + |L5|20 |20  |20 |20 |40 |30 |   |100  |
> + ---

Do you really have 5 states? It look like there are 2 to me because the 
OPP tables only really need to have the max freq at each voltage point. 

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

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

[Rob Herring]

On Thu, Nov 26, 2015 at 10:47:26PM +0900, 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 | 92 
> ++
>  1 file changed, 92 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 ..5d90623bd173
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -0,0 +1,92 @@
> +* 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 exynos-ppmu.c driver with DEVFREQ-EVENT framework.

Please don't refer to Linux subsystem specifics in bindings. It looks 
like you are creating devices to match what you have for drivers, not 
what the h/w looks like.


> +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.
> +- 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
> +  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.
> +
> +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 block (dmc clock)
> +
> + - MIF bus's frequency/voltage table
> + ---
> + |Lv| Freq   | Voltage |
> + ---
> + |L1| 5  |80   |
> + |L2| 10 |80   |
> + |L3| 133000 |80   |
> + |L4| 20 |80   |
> + |L5| 40 |875000   |
> + ---
> +
> +Example2 :
> + The bus of DMC block in exynos3250.dtsi are listed below:

What is DMC?

> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";

I would expect the children of this bus to be under this node.

> + 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 <13300>;
> + 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>;

What do these phandles point to exactly?

> + vdd-supply = <_reg>;  /* VDD_MIF */
> + status = "okay";
> + };
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v3] dt-bindings: Consolidate SRAM bindings from all vendors

[Rob Herring]

On Thu, Nov 19, 2015 at 09:42:49AM +0900, Krzysztof Kozlowski wrote:
> SRAM bindings for various SoCs, using the mmio-sram genalloc
> API, are spread over different places - per SoC vendor. Since all of
> these are quite similar (they depend on mmio-sram) move them to a common
> place.
> 
> Suggested-by: Rob Herring <robh...@kernel.org>
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Cc: Heiko Stuebner <he...@sntech.de>
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Kukjin Kim <kg...@kernel.org>
> Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> Acked-by: Heiko Stuebner <he...@sntech.de>

Applied, thanks. I said I would apply for 4.4, but it is not really 
urgent, so I've just applied it for 4.5.

Rob

> 
> ---
> 
> Changes since v2:
> 1. Update paths to sram.txt.
> 
> Changes since v1:
> 1. New patch. Extended suggestion from Rob.
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt  | 2 
> +-
>  .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt}  | 0
>  .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt}  | 2 
> +-
>  .../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt}   | 2 
> +-
>  Documentation/devicetree/bindings/{misc => sram}/sram.txt   | 0
>  .../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} | 2 
> +-
>  6 files changed, 4 insertions(+), 4 deletions(-)
>  rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt => 
> sram/rockchip-pmu-sram.txt} (100%)
>  rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt => 
> sram/rockchip-smp-sram.txt} (92%)
>  rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt => 
> sram/samsung-sram.txt} (95%)
>  rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
>  rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt => 
> sram/sunxi-sram.txt} (97%)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index 86302de67c2c..313dabdc14f9 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -63,7 +63,7 @@ Required properties:
>  - compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
>  
>  The rest of the properties should follow the generic mmio-sram description
> -found in ../../misc/sysram.txt
> +found in ../../sram/sram.txt
>  
>  Each sub-node represents the reserved area for SCPI.
>  
> diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt 
> b/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
> rename to Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
> diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt 
> b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
> similarity index 92%
> rename from Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
> rename to Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
> index d9416fb8db6f..800701ecffca 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
> +++ b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
> @@ -12,7 +12,7 @@ Required sub-node properties:
>  - compatible : should be "rockchip,rk3066-smp-sram"
>  
>  The rest of the properties should follow the generic mmio-sram discription
> -found in ../../misc/sram.txt
> +found in Documentation/devicetree/bindings/sram/sram.txt
>  
>  Example:
>  
> diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt 
> b/Documentation/devicetree/bindings/sram/samsung-sram.txt
> similarity index 95%
> rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> rename to Documentation/devicetree/bindings/sram/samsung-sram.txt
> index 4a0a4f70a0ce..6bc474b2b885 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> +++ b/Documentation/devicetree/bindings/sram/samsung-sram.txt
> @@ -15,7 +15,7 @@ Required sub-node properties:
>   "samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM
>  
>  The rest of the properties should follow the generic mmio-sram discription
> -found in ../../misc/sysram.txt
> +found in Documentation/devicetree/bindings/sram/sram.txt
>  
>  Example:
>  
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt 
> b/Documentation/devicetree/bindings/

Re: [PATCH v8 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Rob Herring]

On Thu, Nov 12, 2015 at 7:12 AM, Pavel Fedin <p.fe...@samsung.com> wrote:
> Add documentation for new subnode properties, allowing bank configuration.
> Based on u-boot implementation, but heavily reworked.
>
> Also, fix size of SROMc mapping in the example.
>
> Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Acked-by: Rob Herring <r...@kernel.org>

One nit below.

> compatible = "samsung,exynos-srom";
> -   reg = <0x1257 0x10>;
> +   reg = <0x1257 0x14>;
> +
> +   ethernet@3 {

This should actually be "ethernet@3,0"

Fields (not cells) in the unit address should be separated by commas.

> +   compatible = "smsc,lan9115";
> +   reg = <3 0 0x1>;   // Bank 3, offset = 0
> +   phy-mode = "mii";
> +   interrupt-parent = <>;
> +   interrupts = <5 8>;
> +   reg-io-width = <2>;
> +   smsc,irq-push-pull;
> +   smsc,force-internal-phy;
> +
> +   samsung,srom-page-mode = <1>;
> +   samsung,srom-timing = <9 12 1 9 1 1>;
> +   };
> };
> --
> 2.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV

[Rob Herring]

On Mon, Oct 26, 2015 at 12:59:56PM +0100, Andrzej Hajda wrote:
> DECON-TV(Display and Enhancement Controller for TV) is a variation
> of DECON IP. Its main purpose is to produce video stream for HDMI IP.
> 
> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Hi Krzysztof,
> 
> I have decided to skip cleanup part as it would require more work,
> not related to this patchset.
> 
> Regards
> Andrzej
> 
>  Documentation/devicetree/bindings/video/exynos5433-decon.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> index 3dff78b..c9fd7b3 100644
> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> @@ -5,7 +5,8 @@ Exynos series of SoCs which transfers the image data from a 
> video memory
>  buffer to an external LCD interface.
>  
>  Required properties:
> -- compatible: value should be "samsung,exynos5433-decon";
> +- compatible: value should be one of:
> + "samsung,exynos5433-decon", "samsung,exynos5433-decon-tv";
>  - reg: physical base address and length of the DECON registers set.
>  - interrupts: should contain a list of all DECON IP block interrupts in the
> order: VSYNC, LCD_SYSTEM. The interrupt specifier format
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Rob Herring]

On Thu, Nov 12, 2015 at 09:27:21AM +0800, Yakir Yang wrote:
> Hi Rob,
> 
> On 11/12/2015 07:10 AM, Rob Herring wrote:
> >On Fri, Oct 30, 2015 at 09:09:15AM +0800, Yakir Yang wrote:
> >>Some edp screen do not have hpd signal, so we can't just return
> >>failed when hpd plug in detect failed.
> >>
> >>This is an hardware property, so we need add a devicetree property
> >>"analogix,need-force-hpd" to indicate this sutiation.
> >>
> >>Tested-by: Heiko Stuebner <he...@sntech.de>
> >>Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> >>Signed-off-by: Yakir Yang <y...@rock-chips.com>
> >>---
> >I didn't find this one in v10. Did it get dropped?
> 
> You are in my 'to' list, but I haven't send the whole v10 out,
> most of them don't need update :)

Okay, it's just gmail's inability to follow threading...
 
> This series should be:
>  [v8 0/17 ...]
>   | [v8 1/17 ...]
>   | [v8 2/17 ...]
>   | [v8 3/17 ...]
>   | [...]
>   | [v8 15/17 ...]
>   | [v8 16/17 ...]
>   | [v8 17/17 ...]
>   |
>   | [v9 10/17 ...]
>   | [v9 15/17 ...]
>  | We are here
>   | [v9 09/17 ...]
>   | [v10 09/17 ...]
>  | Received an acked from you


> >>diff --git 
> >>a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> >>b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> >>index 7659a7a..74f0e80 100644
> >>--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> >>+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> >>@@ -22,6 +22,9 @@ Required properties for dp-controller:
> >>from general PHY binding: Should be "dp".
> >>  Optional properties for dp-controller:
> >>+   -analogix,need-force-hpd:
> >>+   Indicate driver need force hpd when hpd detect failed, this
> >>+   is used for some eDP screen which don't have hpd signal.
> >This should be a generic property.
> 
> This property would only need in some no-hpd case, it would be dropped if
> panel keep the hotplug signal, that's why I thought it should be optional.

I agree it is optional. I just mean drop the analogix and put in a 
common binding doc (i.e. create a display/bridge/common.txt). Needing to 
ignore HPD is probably a common problem.

> I thought if we put this a property to generic property, then we must need
> to define it in normal device node, not sure whether it is right :)

Sorry, I don't follow.

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

Re: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Rob Herring]

On Wed, Nov 11, 2015 at 12:44 AM, Pavel Fedin  wrote:
>  Hello!
>
>> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in 
>> > the
>> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, 
>> > Tacs.
>> > +Each value is specified in cycles and has the 
>> > following
>> > +meaning and valid range:
>> > +Tacp : Page mode access cycle at Page mode (0 - 
>> > 15)
>> > +Tcah : Address holding time after CSn (0 - 15)
>> > +Tcoh : Chip selection hold on OEn (0 - 15)
>> > +Tacc : Access cycle (0 - 31, the actual time is N 
>> > + 1)
>> > +Tcos : Chip selection set-up before OEn (0 - 15)
>> > +Tacs : Address set-up before CSn (0 - 15)
>>
>> This is not easily extended. Perhaps a property per value instead.
>
>  We had a discussion with Krzysztof about it, he agreed with this form of the 
> property.
> My concern was that it's just too much typing, and makes little sense because 
> these
> settings always go together. If register layout changes, or parameter set 
> changes in
> incompatible way, then it's another device, not exynos-srom anymore.
>  So would you agree with that, or is your position strong?

I'm thinking for a new version of the controller which could add (or
remove) new timing parameters, but then I guess you can interpret the
field differently based on the compatible string. Anyway, your problem
to deal with.

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

Re: [PATCH v9 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Rob Herring]

On Fri, Oct 30, 2015 at 09:09:15AM +0800, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
> 
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
> 
> Tested-by: Heiko Stuebner 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---

I didn't find this one in v10. Did it get dropped?

> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>   hpd when hpd detect failed.
> 
> Changes in v2: None
> 
>  .../bindings/display/bridge/analogix_dp.txt|  4 ++-
>  .../bindings/display/exynos/exynos_dp.txt  |  1 +
>  .../display/rockchip/analogix_dp-rockchip.txt  |  1 +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 
> +++---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
>  6 files changed, 47 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> index 7659a7a..74f0e80 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> @@ -22,6 +22,9 @@ Required properties for dp-controller:
>   from general PHY binding: Should be "dp".
>  
>  Optional properties for dp-controller:
> + -analogix,need-force-hpd:
> + Indicate driver need force hpd when hpd detect failed, this
> + is used for some eDP screen which don't have hpd signal.

This should be a generic property.

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

Re: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Rob Herring]

On Fri, Nov 6, 2015 at 4:03 AM, Pavel Fedin  wrote:
> Add documentation for new subnode properties, allowing bank configuration.
> Based on u-boot implementation, but heavily reworked.
>
> Also, fix size of SROMc mapping in the example.
>
> Signed-off-by: Pavel Fedin 
> Reviewed-by: Krzysztof Kozlowski 
> ---
>  .../bindings/arm/samsung/exynos-srom.txt   | 71 
> +-
>  1 file changed, 69 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
> b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> index 33886d5..3ff2950 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> @@ -5,8 +5,75 @@ Required properties:
>
>  - reg: offset and length of the register set
>
> -Example:
> +Optional properties:
> +The SROM controller can be used to attach external peripherals. In this case
> +extra properties, describing the bus behind it, should be specified as below:
> +
> +- #address-cells: Must be set to 2 to allow memory address translation

2 is for CS# and offset.

> +
> +- #size-cells: Must be set to 1 to allow CS address passing

size is the size, not the address.

> +
> +- ranges: Must be set up to reflect the memory layout with four integer 
> values
> + per bank:
> +0  

s/physical/parent/

You could have another level of translation above for the parent.

> +
> +Sub-nodes:
> +The actual device nodes should be added as subnodes to the SROMc node. These
> +subnodes, except regular device specification, should contain the following
> +properties, describing configuration of the relevant SROM bank:
> +
> +Required properties:
> +- reg: bank number, base address (relative to start of the bank) and size of
> +   the memory mapped for the device. Note that base address will be
> +   typically 0 as this is the start of the bank.
> +
> +- samsung,srom-timing : array of 6 integers, specifying bank timings in the
> +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
> +Each value is specified in cycles and has the 
> following
> +meaning and valid range:
> +Tacp : Page mode access cycle at Page mode (0 - 15)
> +Tcah : Address holding time after CSn (0 - 15)
> +Tcoh : Chip selection hold on OEn (0 - 15)
> +Tacc : Access cycle (0 - 31, the actual time is N + 
> 1)
> +Tcos : Chip selection set-up before OEn (0 - 15)
> +Tacs : Address set-up before CSn (0 - 15)

This is not easily extended. Perhaps a property per value instead.

> +
> +Optional properties:
> +- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is 
> used.
> +
> +- samsung,srom-page-mode : page mode configuration for the bank:
> +  0 - normal (one data)
> +  1 - four data
> +  If omitted, default of 0 is used.
> +
> +Example: basic definition, no banks are configured
> +   sromc@1257 {
> +   compatible = "samsung,exynos-srom";
> +   reg = <0x1257 0x14>;
> +   };
> +
> +Example: SROMc with SMSC911x ethernet chip on bank 3
> sromc@1257 {
> +   #address-cells = <2>;
> +   #size-cells = <1>;
> +   ranges = <0 0 0x0400 0x2   // Bank0
> + 1 0 0x0500 0x2   // Bank1
> + 2 0 0x0600 0x2   // Bank2
> + 3 0 0x0700 0x2>; // Bank3
> +
> compatible = "samsung,exynos-srom";
> -   reg = <0x1257 0x10>;
> +   reg = <0x1257 0x14>;
> +
> +   ethernet@3 {
> +   compatible = "smsc,lan9115";
> +   reg = <3 0 0x1>;   // Bank 3, offset = 0
> +   phy-mode = "mii";
> +   interrupt-parent = <>;
> +   interrupts = <5 8>;
> +   reg-io-width = <2>;
> +   smsc,irq-push-pull;
> +   smsc,force-internal-phy;
> +
> +   samsung,srom-config = <1 9 12 1 9 1 1>;

This doesn't match the doc.

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

Re: [PATCH v5 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Rob Herring]

On Fri, Oct 30, 2015 at 11:55:31AM +0530, Alim Akhtar wrote:
> From: Thomas Abraham 
> 
> Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
> is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
> This also supports RTC and three 32.768KHz clock outputs.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Thomas Abraham 
> Signed-off-by: Alim Akhtar 
> ---
>  Documentation/devicetree/bindings/mfd/s2mps11.txt |   21 
> ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> index 890f0b0e1643..4c0543ceec25 100644
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> @@ -1,5 +1,5 @@
>  
> -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator
> +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
>  
>  The Samsung S2MPS11 is a multi-function device which includes voltage and
>  current regulators, RTC, charger controller and other sub-blocks. It is
> @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. 
> Each sub-block is
>  addressed by the host system using different I2C slave addresses.
>  
>  Required properties:
> -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
> -   or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
> +- compatible: Should be one of the following
> + - "samsung,s2mps11-pmic"
> + - "samsung,s2mps13-pmic"
> + - "samsung,s2mps14-pmic"
> + - "samsung,s2mps15-pmic"
> + - "samsung,s2mpu02-pmic".
>  - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
>  
>  Optional properties:
> @@ -24,7 +28,7 @@ Optional properties:
>unwanted buck warm reset (setting buck voltages to default values).
>  
>  Optional nodes:
> -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 
> 32.768
> +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) 
> buffered 32.768

s5m8767 doesn't seem to be documented. Can you please fix or remove.

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

Re: [PATCH v10 09/17] dt-bindings: add document for rockchip variant of analogix_dp

[Rob Herring]

On Sat, Oct 31, 2015 at 1:42 AM, Yakir Yang <y...@rock-chips.com> wrote:
> Rockchip DP driver is a helper driver of analogix_dp coder driver,
> so most of the DT property should be descriped in analogix_dp document.
>
> Reviewed-by: Heiko Stuebner <he...@sntech.de>
> Signed-off-by: Yakir Yang <y...@rock-chips.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Changes in v10:
> - Removed the duplicated signed-of.
>
> Changes in v9:
> - Document more details for 'ports' property.
>
> Changes in v8:
> - Modify the commit subject name. (Heiko)
>
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Add eDP hotplug pinctrl property. (Heiko)
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  .../display/rockchip/analogix_dp-rockchip.txt  | 91 
> ++
>  1 file changed, 91 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> new file mode 100644
> index 000..dae86c4
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> @@ -0,0 +1,91 @@
> +Rockchip RK3288 specific extensions to the Analogix Display Port
> +
> +
> +Required properties:
> +- compatible: "rockchip,rk3288-edp";
> +
> +- reg: physical base address of the controller and length
> +
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +
> +- clock-names: from common clock binding:
> +  Required elements: "dp" "pclk"
> +
> +- resets: Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
> +
> +- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
> +- pinctrl-0: pin-control mode. should be <_hpd>
> +
> +- reset-names: Must include the name "dp"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +
> +- ports: there are 2 port nodes with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +Port 0: contained 2 endpoints, connecting to the ouput of vop.
> +Port 1: contained 1 endpoint, connecting to the input of panel.
> +
> +For the below properties, please refer to Analogix DP binding document:
> + * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> +- phys (required)
> +- phy-names (required)
> +- hpd-gpios (optional)
> +---
> +
> +Example:
> +   dp-controller: dp@ff97 {
> +   compatible = "rockchip,rk3288-dp";
> +   reg = <0xff97 0x4000>;
> +   interrupts = ;
> +   clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
> +   clock-names = "dp", "pclk";
> +   phys = <_phy>;
> +   phy-names = "dp";
> +
> +   rockchip,grf = <>;
> +   resets = < 111>;
> +   reset-names = "dp";
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_hpd>;
> +
> +   status = "disabled";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   edp_in: port@0 {
> +   reg = <0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   edp_in_vopb: endpoint@0 {
> +   reg = <0>;
> +   remote-endpoint = <_out_edp>;
> +   };
> +   edp_in_vopl: endpoint@1 {
> +   reg = <1>;
> +   remote-endpoint = <_out_edp>;
> +   };
> +   };
> +
> +   edp_out: port@1 {
> +   reg = <1>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   edp_out_panel

Re: [PATCH v8 11/17] dt-bindings: add document for rockchip dp phy

[Rob Herring]

On Wed, Oct 28, 2015 at 3:31 AM, Yakir Yang <y...@rock-chips.com> wrote:
> Add dt binding documentation for rockchip display port PHY.
>
> Reviewed-by: Heiko Stuebner <he...@sntech.de>
> Signed-off-by: Yakir Yang <y...@rock-chips.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Changes in v8:
> - Remove the specific address in the example node name. (Heiko)
>
> Changes in v7:
> - Simplify the commit message. (Kishon)
>
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Update the rockchip,grf explain in document, and correct the clock required
>   elemets in document. (Rob & Heiko)
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..00902cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,22 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> +- "rockchip.rk3288-dp-phy"
> +- clocks: from common clock binding: handle to dp clock.
> +   of memory mapped region.
> +- clock-names: from common clock binding:
> +   Required elements: "24m"
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: edp-phy {
> +   compatible = "rockchip,rk3288-dp-phy";
> +   rockchip,grf = <>;
> +   clocks = < SCLK_EDP_24M>;
> +   clock-names = "24m";
> +   #phy-cells = <0>;
> +};
> --
> 1.9.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 09/17] dt-bindings: add document for rockchip variant of analogix_dp

[Rob Herring]

On Wed, Oct 28, 2015 at 3:28 AM, Yakir Yang  wrote:
> Rockchip DP driver is a helper driver of analogix_dp coder driver,
> so most of the DT property should be descriped in analogix_dp document.
>
> Reviewed-by: Heiko Stuebner 
> Signed-off-by: Yakir Yang 
> ---

Looks mostly fine to me.

[...]

> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +
> +- ports: contain a port node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.

Please document that you have 2 ports 0 and 1, port0 has 2 endpoints
for ? and port1 has 1 endpoint connected to a panel(or another
bridge). Otherwise that is only evident from the example.

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

Re: [PATCH v3 1/3] dt-bindings: Consolidate SRAM bindings from all vendors

[Rob Herring]

On Fri, Oct 23, 2015 at 3:05 PM, Kukjin Kim <kg...@kernel.org> wrote:
> On 10/24/15 04:47, Kukjin Kim wrote:
>> On 10/23/15 10:39, Krzysztof Kozlowski wrote:
>>> SRAM bindings for various SoCs, using the mmio-sram genalloc
>>> API, are spread over different places - per SoC vendor. Since all of
>>> these are quite similar (they depend on mmio-sram) move them to a common
>>> place.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>> Cc: Heiko Stuebner <he...@sntech.de>
>>> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
>>> Cc: Chen-Yu Tsai <w...@csie.org>
>>> Cc: Kukjin Kim <kg...@kernel.org>
>
> Acked-by: Kukjin Kim <kg...@kernel.org>
>
>>> Suggested-by: Rob Herring <robh...@kernel.org>
>>>
>> Applied with Heiko and Maxime's ack.
>>
> + Sudeep
>
> Oops, I can't because of ..bindings/arm/arm,scpi.txt, this series should
> be handled with "DT binding for ARM System Control and Power
> Interface(SCPI) protocol"

I'll take it after the merge window.

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

Re: [PATCH v2 1/3] dt-bindings: Consolidate SRAM bindings from all vendors

[Rob Herring]

On Thu, Oct 22, 2015 at 8:34 AM, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> On Thu, Oct 22, 2015 at 06:19:31PM +0900, Krzysztof Kozlowski wrote:
>> On 22.10.2015 18:05, Maxime Ripard wrote:
>> > Hi,
>> >
>> > On Thu, Oct 22, 2015 at 10:25:28AM +0900, Krzysztof Kozlowski wrote:
>> >> SRAM bindings for various SoCs, using the mmio-sram genalloc
>> >> API, are spread over different places - per SoC vendor. Since all of
>> >> these are quite similar (they depend on mmio-sram) move them to a common
>> >> place.
>> >>
>> >> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>> >> Cc: Heiko Stuebner <he...@sntech.de>
>> >> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
>> >> Cc: Chen-Yu Tsai <w...@csie.org>
>> >> Cc: Kukjin Kim <kg...@kernel.org>
>> >> Suggested-by: Rob Herring <robh...@kernel.org>
>> >>
>> >> ---
>> >>
>> >> Changes since v1:
>> >> 1. New patch. Extended suggestion from Rob.
>> >> ---
>> >>  .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt}   
>> >>  | 0
>> >>  .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt}   
>> >>  | 0
>> >>  .../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt}
>> >>  | 0
>> >>  Documentation/devicetree/bindings/{misc => sram}/sram.txt
>> >>  | 0
>> >>  .../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt}  
>> >>  | 0
>> >>  5 files changed, 0 insertions(+), 0 deletions(-)
>> >>  rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt => 
>> >> sram/rockchip-pmu-sram.txt} (100%)
>> >>  rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt => 
>> >> sram/rockchip-smp-sram.txt} (100%)
>> >>  rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt => 
>> >> sram/samsung-sram.txt} (100%)
>> >>  rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
>> >>  rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt => 
>> >> sram/sunxi-sram.txt} (100%)
>> >
>> > I'm not sure about that one. The SRAM bindins we have for sunxi is for
>> > an SRAM controller, that maps the SRAM either to the CPU or to the
>> > devices.
>> >
>> > It's not really related to the other users, and wouldn't it be
>> > confusing to have a driver in drivers/soc, and a Documentation in
>> > another sub-directory?
>>
>> I guess the only relation to other users is the "mmio-sram". In the same
>> time this is still similar to e.g. Samsung's sram bindings (where the
>> memory is mapped to CPU only).
>>
>> Being located in drivers/soc is not an issue here - code for other
>> vendors may be moved there as well in the future.
>>
>> Of course I do not insist. Actually Rob's comment was only about moving
>> sram.txt and Samsung's sram to common place.

I certainly appreciate your finding other instances.

>> Anyway I will be sending v3 of these because while looking more
>> carefully I found hard-coded paths to bindings/misc/sram.txt. I'll fix
>> it in next version.
>
> I didn't really have the context. If Rob feels like we should do that,
> then go ahead.

I'm trying to group by binding type rather than arch or vendor for
common bindings. I think bindings/sram is fine to host both ctrlr and
memory range bindings.

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

Re: [PATCH 1/2] dt-bindings: Consolidate Exynos SoC bindings under Samsung directory

[Rob Herring]

On Tue, Oct 20, 2015 at 8:30 PM, Krzysztof Kozlowski
 wrote:
> Exynos SoC Device Tree bindings are spread over arm/exynos/ and
> arm/samsung/ directories. There is no need for that separation and it
> actually confuses. Put everything under arm/samsung/.

Thanks for the clean-up.

>
> Signed-off-by: Krzysztof Kozlowski 
> Cc: Kukjin Kim 
> ---
>  .../devicetree/bindings/arm/{exynos => samsung}/power_domain.txt  | 0
>  Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt| 0
>  Documentation/devicetree/bindings/arm/{exynos => samsung}/smp-sysram.txt  | 0
>  3 files changed, 0 insertions(+), 0 deletions(-)
>  rename Documentation/devicetree/bindings/arm/{exynos => 
> samsung}/power_domain.txt (100%)

I'd rather see this with other power domain bindings. So
bindings/power/pd-samsung.txt I guess.

>  rename Documentation/devicetree/bindings/arm/{ => 
> samsung}/samsung-boards.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{exynos => 
> samsung}/smp-sysram.txt (100%)

Probably need to move misc/sram.txt to bindings/sram/ and put both there.

Rob

>
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
> b/Documentation/devicetree/bindings/arm/samsung/power_domain.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> rename to Documentation/devicetree/bindings/arm/samsung/power_domain.txt
> diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt 
> b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/arm/samsung-boards.txt
> rename to Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt 
> b/Documentation/devicetree/bindings/arm/samsung/smp-sysram.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> rename to Documentation/devicetree/bindings/arm/samsung/smp-sysram.txt
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

[Rob Herring]

On Tue, Sep 1, 2015 at 3:46 PM, Heiko Stuebner  wrote:
> Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
>> Split the dp core driver from exynos directory to bridge
>> directory, and rename the core driver to analogix_dp_*,
>> leave the platform code to analogix_dp-exynos.
>>
>> Signed-off-by: Yakir Yang 
>
> [...]
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c similarity index 50%
>> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
>> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index bed0252..7d62f22 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>
> [...]
>
>>   connector->polled = DRM_CONNECTOR_POLL_HPD;
>>
>>   ret = drm_connector_init(dp->drm_dev, connector,
>> -  _dp_connector_funcs,
>> +  _dp_connector_funcs,
>>DRM_MODE_CONNECTOR_eDP);
>>   if (ret) {
>>   DRM_ERROR("Failed to initialize connector with drm\n");
>>   return ret;
>>   }
>>
>> - drm_connector_helper_add(connector, _dp_connector_helper_funcs);
>> + drm_connector_helper_add(connector,
>> +  _dp_connector_helper_funcs);
>>   drm_connector_register(connector);
>
> this should only run on exynos, as we're doing all our connector registration
> in the core driver after all components are bound, so I guess something like
> the following is needed:
>
>if (dp->plat_data && dp->plat_data->dev_type == EXYNOS_DP)
>drm_connector_register(connector);

Yuck!

Surely there is a better way. From what I've seen of DRM, I have no
doubt this is needed, but really a better solution is needed. Surely
there can be a more generic way for the driver to determine if it
should handle the connector or not. This seems like a common problem
including one I have seen. What I'm working on has onchip DSI encoder
-> ADV7533 -> HDMI. The DSI encoder can also have a direct attached
panel. So I have to check for a bridge in the encoder driver and only
register the connector for the panel if a bridge is not attached.

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

Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Rob Herring]

On Wed, Sep 2, 2015 at 11:27 PM, Yakir Yang <y...@rock-chips.com> wrote:
> Hi Rob,
>
> 在 09/03/2015 04:17 AM, Rob Herring 写道:
>>
>> On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang <y...@rock-chips.com> wrote:
>>>
>>> Some edp screen do not have hpd signal, so we can't just return
>>> failed when hpd plug in detect failed.
>>
>> This is a property of the panel (or connector perhaps), so this
>> property should be located there. At least, it is a common issue and
>> not specific to this chip. We could have an HDMI connector and failed
>> to hook up HPD for example. A connector node is also where hpd-gpios
>> should be located instead (and are already defined by
>> ../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector
>> binding, too.
>
>
> Yep, I agree with your front point, it is a property of panel, not specific
> to eDP controller, so this code should handle in connector logic.
>
> But another question, if we just leave this property to connector,
> then we would need to parse this property in analogix_dp-rockchip.c,
> and then make an hook in analogix_dp_core.c driver. This is not nice,
> and if there are some coming platform which alse want to use analogix_dp
> code and meet this "no-hpd" situation,  then they would need duplicate
> to parse this property and fill the hook in analogix_dp_core.c driver.
> So it's little bit conflict  :-)

Ideally, you would be able to just retrieve this quirk from the
connector or panel. Getting this property from your node vs. the port
you are attached to should not be much harder. Either the connector
struct can have this info or there can be a DT function that can walk
the graph and get it. Just don't open code the graph traversal in your
driver.

> Beside I can not understand your example very well. Do you mean
> that there are some HDMI monitor which also do not have HPD
> signal (just like some eDP panel do not have hpd too), and then
> the "hpd-gpios" ? Hmm... I don't know how the "hpd-gpios" want
> to help in this case, would you mind show some sample code  :-D

I don't know that there is h/w, but it is always possible HPD is not
hooked up or hooked up incorrectly some how.

If there is no HPD support, then hpd-gpios is not going to help you.

I think there are 3 cases to handle:
- HPD handled by bridge chip - The bridge driver knows it has this
capability. No DT properties are needed and no HPD properties on the
connector node imply the bridge chip should handle HPD functions.
- HPD handled by GPIO line (or some other block) - Indicated by
hpd-gpios present
- No or broken HPD - Indicated by "hpd-force" property.

>
>> Are there any eDP panels which don't have EDID and need panel details in
>> DT?
>
>
> Oh, I think you want to collect some info that belong to panel
> property but no indicate in panel EDID message, so those can
> be collect in eDP connector binding, is it right ?

Yes, and as Thierry pointed out we may need to know the exact panel even.

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

Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Rob Herring]

On Thu, Sep 3, 2015 at 3:47 AM, Thierry Reding <tred...@nvidia.com> wrote:
> On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote:
> [...]
>> Are there any eDP panels which don't have EDID and need panel details in DT?
>
> Most panels need information other than EDID. They typically have some
> requirements regarding the power up sequence that aren't to be found
> anywhere in EDID or detectable by some other mechanism. A decision was
> therefore made a long time ago to require panels to be listed in DT with
> a specific compatible string. That way all of these details can be
> stashed away in drivers that know how to deal with these kinds of
> details.

I guess I was being hopeful that eDP was improving that situation.

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

Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Rob Herring]

On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang  wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.

This is a property of the panel (or connector perhaps), so this
property should be located there. At least, it is a common issue and
not specific to this chip. We could have an HDMI connector and failed
to hook up HPD for example. A connector node is also where hpd-gpios
should be located instead (and are already defined by
../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector
binding, too.

Are there any eDP panels which don't have EDID and need panel details in DT?

Rob

> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4: None
> Changes in v3:
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>   hpd when hpd detect failed.
>
> Changes in v2: None
>
>  .../devicetree/bindings/drm/bridge/analogix_dp.txt |  4 ++-
>  .../bindings/video/analogix_dp-rockchip.txt|  1 +
>  .../devicetree/bindings/video/exynos_dp.txt|  1 +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 
> +++---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
>  6 files changed, 47 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
> b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> index f54dc3e..c310367 100644
> --- a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> @@ -22,6 +22,9 @@ Required properties for dp-controller:
> from general PHY binding: Should be "dp".
>
>  Optional properties for dp-controller:
> +   -analogix,need-force-hpd:
> +   Indicate driver need force hpd when hpd detect failed, this
> +   is used for some eDP screen which don't have hpd signal.
> -hpd-gpios:
> Hotplug detect GPIO.
> Indicates which GPIO should be used for hotplug detection
> @@ -31,7 +34,6 @@ Optional properties for dp-controller:
> * Documentation/devicetree/bindings/video/exynos_dp.txt
> * 
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>
> -
>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> ---
>
> diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt 
> b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> index 502483e..8b9ed7d 100644
> --- a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> +++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> @@ -28,6 +28,7 @@ For the below properties, please refer to Analogix DP 
> binding document:
>  - phys (required)
>  - phy-names (required)
>  - hpd-gpios (optional)
> +- analogix,need-force-hpd (optional)
>  
> ---
>
>  Example:
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt 
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> index ea03b3a..4f06e80 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP 
> binding document:
> -phys (required)
> -phy-names (required)
> -hpd-gpios (optional)
> +   -analogix,need-force-hpd (optional)
> -video interfaces (optional)
>
>  Deprecated properties for DisplayPort:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index f7227ec..e6b328a 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -63,15 +63,38 @@ static int analogix_dp_detect_hpd(struct 
> analogix_dp_device *dp)
>  {
> int timeout_loop = 0;
>
> -   while (analogix_dp_get_plug_in_status(dp) != 0) {
> +   while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
> +   if (analogix_dp_get_plug_in_status(dp) == 0)
> +   return 0;
> +
> timeout_loop++;
> -   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> -   dev_err(dp->dev, "failed to get hpd plug status\n");
> -   return -ETIMEDOUT;
> -   }
> usleep_range(10, 11);
> }
>
> +   /*
> +* Some edp screen do not have hpd signal, so we can't just
> +* return failed when hpd plug in detect failed, DT property
> +* "need-force-hpd" 

Re: [PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY

[Rob Herring]

On Tue, Sep 1, 2015 at 1:04 AM, Yakir Yang  wrote:
> This phy driver would control the Rockchip DisplayPort module
> phy clock and phy power, it is relate to analogix_dp-rockchip
> dp driver. If you want DP works rightly on rockchip platform,
> then you should select both of them.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4:
> - Take Kishon suggest, add commit message, and remove the redundant
>   rockchip_dp_phy_init() function, move those code to probe() method.
>   And remove driver .owner number.
>
> Changes in v3:
> - Take Heiko suggest, add rockchip dp phy driver,
>   collect the phy clocks and power control.
>
> Changes in v2: None
>
>  .../devicetree/bindings/phy/rockchip-dp-phy.txt|  26 

It is preferred that you split binding doc's from driver changes.

>  drivers/phy/Kconfig|   7 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-rockchip-dp.c  | 166 
> +
>  4 files changed, 200 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>  create mode 100644 drivers/phy/phy-rockchip-dp.c
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..5de1088
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,26 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> +- "rockchip.rk3288-dp-phy"
> +
> +- reg : a list of registers used by phy driver

Please state the size of the list and order of what each entry if more than one.

> +- clocks: from common clock binding: handle to dp clock.
> +   of memory mapped region.
> +- clock-names: from common clock binding:
> +   Required elements: "sclk_dp" "sclk_dp_24m"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.

I have no idea what GRF means.

> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: phy@ff770274 {
> +   compatilble = "rockchip,rk3288-dp-phy";
> +   reg = <0xff770274 4>;
> +   rockchip,grf = <>;
> +   clocks = < SCLK_EDP_24M>;
> +   clock-names = "24m";
> +   #phy-cells = <0>;
> +}
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573..8f2bc4f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
> help
>   Enable this to support the Rockchip USB 2.0 PHY.
>
> +config PHY_ROCKCHIP_DP
> +   tristate "Rockchip Display Port PHY Driver"
> +   depends on ARCH_ROCKCHIP && OF
> +   select GENERIC_PHY
> +   help
> + Enable this to support the Rockchip Display Port PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
> tristate "ST SPEAR1310-MIPHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c1..e281f35 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..e9a726e
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,166 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang 
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_SOC_CON12   0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
> +
> +#define DP_PHY_SIDDQ_WRITE_EN   BIT(21)
> +#define DP_PHY_SIDDQ_ON 0
> +#define DP_PHY_SIDDQ_OFFBIT(5)
> +
> +struct rockchip_dp_phy {
> +   struct device  *dev;
> +   struct regmap  *grf;
> +   void __iomem   *regs;
> +   struct clk *phy_24m;
> +};
> +
> +static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
> +{
> +   int 

Re: [PATCH v3] irqchip: kill off set_irq_flags usage

[Rob Herring]

On Mon, Jul 27, 2015 at 3:55 PM, Rob Herring r...@kernel.org wrote:
 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also modify IRQ_NOPROBE and this has been maintained although it
 is not clear that is really needed. There appears to be a great deal of
 blind copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: Jason Cooper ja...@lakedaemon.net
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Lee Jones l...@kernel.org
 Cc: Alexander Shiyan shc_w...@mail.ru
 Cc: Maxime Ripard maxime.rip...@free-electrons.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-samsung-soc@vger.kernel.org
 Cc: linux-rpi-ker...@lists.infradead.org
 ---
 Thomas asked that this be merged thru subsystem trees instead of arm-soc,
 so please apply this to your tree.

Thomas, Jason,

Everything except this patch, sh, gpu, and final removal of
set_irq_flags in arm/arm64 are in -next. There don't appear to be any
new users either.

Can you apply this patch and these 2 now so they have some time in -next:

http://lkml.kernel.org/r/1438030523-15853-11-git-send-email-r...@kernel.org
http://lkml.kernel.org/r/1438030523-15853-5-git-send-email-r...@kernel.org

And these 2 toward the end of the merge window once there is no more
set_irq_flags:

http://lkml.kernel.org/r/1436711211-18223-13-git-send-email-r...@kernel.org
http://lkml.kernel.org/r/1436711211-18223-14-git-send-email-r...@kernel.org

Rob

  drivers/irqchip/exynos-combiner.c |  2 +-
  drivers/irqchip/irq-armada-370-xp.c   |  3 +--
  drivers/irqchip/irq-bcm2835.c |  2 +-
  drivers/irqchip/irq-clps711x.c|  6 +++---
  drivers/irqchip/irq-gic-v3.c  |  5 ++---
  drivers/irqchip/irq-gic.c |  4 ++--
  drivers/irqchip/irq-hip04.c   |  4 ++--
  drivers/irqchip/irq-keystone.c|  2 +-
  drivers/irqchip/irq-mmp.c |  3 ---
  drivers/irqchip/irq-mxs.c |  1 -
  drivers/irqchip/irq-renesas-intc-irqpin.c |  1 -
  drivers/irqchip/irq-renesas-irqc.c|  1 -
  drivers/irqchip/irq-s3c24xx.c | 14 ++
  drivers/irqchip/irq-sun4i.c   |  2 +-
  drivers/irqchip/irq-versatile-fpga.c  |  2 +-
  drivers/irqchip/irq-vic.c |  2 +-
  drivers/irqchip/irq-vt8500.c  |  1 -
  drivers/irqchip/spear-shirq.c |  1 -
  18 files changed, 18 insertions(+), 38 deletions(-)

 diff --git a/drivers/irqchip/exynos-combiner.c 
 b/drivers/irqchip/exynos-combiner.c
 index 5c82e3b..a62cfd3 100644
 --- a/drivers/irqchip/exynos-combiner.c
 +++ b/drivers/irqchip/exynos-combiner.c
 @@ -165,7 +165,7 @@ static int combiner_irq_domain_map(struct irq_domain *d, 
 unsigned int irq,

 irq_set_chip_and_handler(irq, combiner_chip, handle_level_irq);
 irq_set_chip_data(irq, combiner_data[hw  3]);
 -   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
 +   irq_set_probe(irq);

 return 0;
  }
 diff --git a/drivers/irqchip/irq-armada-370-xp.c 
 b/drivers/irqchip/irq-armada-370-xp.c
 index 0d3b0fe..017f881 100644
 --- a/drivers/irqchip/irq-armada-370-xp.c
 +++ b/drivers/irqchip/irq-armada-370-xp.c
 @@ -201,7 +201,6 @@ static int armada_370_xp_msi_map(struct irq_domain 
 *domain, unsigned int virq,
  {
 irq_set_chip_and_handler(virq, armada_370_xp_msi_irq_chip,
  handle_simple_irq);
 -   set_irq_flags(virq, IRQF_VALID);

 return 0;
  }
 @@ -318,7 +317,7 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain 
 *h,
 irq_set_chip_and_handler(virq, armada_370_xp_irq_chip,
 handle_level_irq);
 }
 -   set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
 +   irq_set_probe(virq);

 return 0;
  }
 diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
 index e68c3b6..9c4ba16 100644
 --- a/drivers/irqchip/irq-bcm2835.c
 +++ b/drivers/irqchip/irq-bcm2835.c
 @@ -165,7 +165,7 @@ static int __init armctrl_of_init(struct device_node 
 *node,
 BUG_ON(irq = 0);
 irq_set_chip_and_handler(irq, armctrl_chip,
 handle_level_irq);
 -   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
 +   irq_set_probe(irq);
 }
 }

 diff --git a/drivers/irqchip/irq

Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

[Rob Herring]

On Tue, Aug 25, 2015 at 4:15 AM, Thierry Reding tred...@nvidia.com wrote:
 On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
 On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com wrote:
 [...]
  +   -analogix,link-rate:
  +   max link rate supported by the eDP controller.
  +   LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 
  0x0A,
  +   LINK_RATE_5_40GBPS = 0x14

 Same here. I'd rather see something like link-rate-mbps and use the
 actual rate.

 There is no need whatsoever to hard-code this in DT. (e)DP provides the
 means to detect what rate the link supports and the specification
 provides guidance on how to select an appropriate one.

Good, even better.

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

Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

[Rob Herring]

On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
 On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com wrote:
  +   -analogix,color-depth:
  +   number of bits per colour component.
  +   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 
  3

 This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
 drop the vendor prefix.

 Please think about this some more.  What does color-depth mean?  Does it
 mean the number of bits per colour _component_, or does it mean the total
 number of bits to represent a particular colour.  It's confusing as it
 stands.

Then component-color-bpp perhaps?


  +Optional properties for dp-controller:
  +   -analogix,hpd-gpio:
  +   Hotplug detect GPIO.
  +   Indicates which GPIO should be used for hotplug
  +   detection

 We should align with hpd-gpios used by HDMI connector binding. Or do
 we need a DP connector binding that this should be defined in?
 Probably so.

 The DRM related bindings are such a cluster f*ck with everyone picking
 their own way to do things. Just grep hpd in bindings for starters.
 That is just the tip.

 I'm not surprised one iota that DRM bindings are a mess.  There's no one
 overlooking the adoption of DRM bindings, so surprise surprise, everyone
 does their own thing.  This is exactly what happens every time in that
 scenario.  It's not a new problem.

True.

 When we adopted the graph bindings for iMX DRM, I thought exactly at that
 time it would be nice if this could become the standard for binding DRM
 components together but I don't have the authority from either the DT
 perspective or the DRM perspective to mandate that.  Neither does anyone
 else.  That's the _real_ problem here.

 I've seen several DRM bindings go by which don't use the of-graph stuff,
 which means that they'll never be compatible with generic components
 which do use the of-graph stuff.

It goes beyond bindings IMO. The use of the component framework or not
has been at the whim of driver writers as well. It is either used or
private APIs are created. I'm using components and my need for it
boils down to passing the struct drm_device pointer to the encoder.
Other components like panels and bridges have different ways to attach
to the DRM driver.

 Like you say, it's a mess, but it's a mess of our own making, because no
 one has the authority to regulate this.

Certainly, and I will take some blame here. We deferred a lot of
binding review to subsystem maintainers with the directive to ask for
help when needed. The latter has not happened. We need to improve the
situation here before we end up with a bigger mess. The momentum to
use DRM on Android is growing, so the problem is only going to get
worse if we do nothing.

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

Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

[Rob Herring]

On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com wrote:
 Analogix dp driver is split from exynos dp driver, so we just
 make an copy of exynos_dp.txt, and then simplify exynos_dp.txt

 Beside update some exynos dtsi file with the latest change
 according to the devicetree binding documents.

You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?


 Signed-off-by: Yakir Yang y...@rock-chips.com
 ---
 Changes in v3:
 - Take Heiko suggest, add devicetree binding documents.
 - Take Thierry Reding suggest, remove sync pol  colorimetry properies
   from the new analogix dp driver devicetree binding.
 - Update the exist exynos dtsi file with the latest DP DT properies.

 Changes in v2: None

  .../devicetree/bindings/drm/bridge/analogix_dp.txt | 70 
 ++
  .../devicetree/bindings/video/exynos_dp.txt| 50 ++--
  arch/arm/boot/dts/exynos5250-arndale.dts   | 10 ++--
  arch/arm/boot/dts/exynos5250-smdk5250.dts  | 10 ++--
  arch/arm/boot/dts/exynos5250-snow.dts  | 12 ++--
  arch/arm/boot/dts/exynos5250-spring.dts| 12 ++--
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++--
  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 10 ++--
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 12 ++--
  9 files changed, 119 insertions(+), 79 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt

 diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
 b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
 new file mode 100644
 index 000..6127018
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
 @@ -0,0 +1,70 @@
 +Analogix Display Port bridge bindings
 +
 +Required properties for dp-controller:
 +   -compatible:
 +   platform specific such as:
 +* samsung,exynos5-dp
 +* rockchip,rk3288-dp
 +   -reg:
 +   physical base address of the controller and length
 +   of memory mapped region.
 +   -interrupts:
 +   interrupt combiner values.
 +   -clocks:
 +   from common clock binding: handle to dp clock.
 +   -clock-names:
 +   from common clock binding: Shall be dp.
 +   -interrupt-parent:
 +   phandle to Interrupt combiner node.
 +   -phys:
 +   from general PHY binding: the phandle for the PHY device.
 +   -phy-names:
 +   from general PHY binding: Should be dp.
 +   -analogix,color-space:
 +   input video data format.
 +   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
 +   -analogix,color-depth:
 +   number of bits per colour component.
 +   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3

This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
drop the vendor prefix.

 +   -analogix,link-rate:
 +   max link rate supported by the eDP controller.
 +   LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
 +   LINK_RATE_5_40GBPS = 0x14

Same here. I'd rather see something like link-rate-mbps and use the
actual rate.

 +   -analogix,lane-count:
 +   max number of lanes supported by the eDP contoller.
 +   LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4

And drop the vendor prefix here.

 +   -port@[X]: SoC specific port nodes with endpoint definitions as 
 defined
 +   in 
 Documentation/devicetree/bindings/media/video-interfaces.txt,
 +   please refer to the SoC specific binding document:
 +   * Documentation/devicetree/bindings/video/exynos_dp.txt
 +   * 
 Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
 +
 +Optional properties for dp-controller:
 +   -analogix,hpd-gpio:
 +   Hotplug detect GPIO.
 +   Indicates which GPIO should be used for hotplug
 +   detection

We should align with hpd-gpios used by HDMI connector binding. Or do
we need a DP connector binding that this should be defined in?
Probably so.

The DRM related bindings are such a cluster f*ck with everyone picking
their own way to do things. Just grep hpd in bindings for starters.
That is just the tip.

 +   -video interfaces: Device node can contain video interface port
 +   nodes according to [1].

Isn't this the same as ports above? How are they optional? 0 ports
would be pretty useless.

 +
 +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
 +---
 +
 +Example:
 +
 +   dp-controller {
 +   compatible = samsung,exynos5-dp;
 +   reg = 0x145b 0x1;
 + 

Re: [PATCH v2 06/13] irqchip: kill off set_irq_flags usage

[Rob Herring]

On Sat, Jul 25, 2015 at 8:34 AM, Gregory CLEMENT
gregory.clem...@free-electrons.com wrote:
 Hi Rob,

 On 12/07/2015 16:26, Rob Herring wrote:
 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: Jason Cooper ja...@lakedaemon.net
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Lee Jones l...@kernel.org
 Cc: Alexander Shiyan shc_w...@mail.ru
 Cc: Maxime Ripard maxime.rip...@free-electrons.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-samsung-soc@vger.kernel.org
 Cc: linux-rpi-ker...@lists.infradead.org
 ---
 v2:
 - Fix build error on clps711x

 [...]

 diff --git a/drivers/irqchip/irq-armada-370-xp.c 
 b/drivers/irqchip/irq-armada-370-xp.c
 index 0d3b0fe..b8bf8b0 100644
 --- a/drivers/irqchip/irq-armada-370-xp.c
 +++ b/drivers/irqchip/irq-armada-370-xp.c
 @@ -201,7 +201,6 @@ static int armada_370_xp_msi_map(struct irq_domain 
 *domain, unsigned int virq,
  {
   irq_set_chip_and_handler(virq, armada_370_xp_msi_irq_chip,
handle_simple_irq);
 - set_irq_flags(virq, IRQF_VALID);

 OK


   return 0;
  }
 @@ -318,7 +317,7 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain 
 *h,
   irq_set_chip_and_handler(virq, armada_370_xp_irq_chip,
   handle_level_irq);
   }
 - set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
 + irq_set_noprobe(virq);

 I think it should be irq_set_probe(virq), I don't see why you inverted the 
 probe flag.

Yes, this translation and similar ones are messed up. I've gone back
thru and fixed these.

However, it is questionable whether you really want to enable probing
on these lines or care either way.

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

[PATCH v3] ARM: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Gregory Clement gregory.clem...@free-electrons.com
Acked-by: Hans Ulli Kroll ulli.kr...@googlemail.com
Acked-by: Shawn Guo shawn...@kernel.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Imre Kaloz ka...@openwrt.org
Acked-by: Krzysztof Halasa khal...@piap.pl
Cc: Greg Ungerer g...@uclinux.org
Cc: Roland Stigge sti...@antcom.de
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Mack dan...@zonque.org
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Robert Jarzmik robert.jarz...@free.fr
Cc: Simtec Linux Team li...@simtec.co.uk
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-by: Wan ZongShun mcuos@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply just this patch to your tree.

Rob

 arch/arm/common/it8152.c |  2 +-
 arch/arm/common/locomo.c |  2 +-
 arch/arm/common/sa.c |  4 ++--
 arch/arm/mach-davinci/cp_intc.c  |  2 +-
 arch/arm/mach-dove/irq.c |  2 +-
 arch/arm/mach-ebsa110/core.c |  2 +-
 arch/arm/mach-footbridge/common.c|  2 +-
 arch/arm/mach-footbridge/isa-irq.c   |  8 
 arch/arm/mach-gemini/gpio.c  |  2 +-
 arch/arm/mach-gemini/irq.c   |  2 +-
 arch/arm/mach-imx/3ds_debugboard.c   |  2 +-
 arch/arm/mach-imx/mach-mx31ads.c |  2 +-
 arch/arm/mach-iop13xx/irq.c  |  2 +-
 arch/arm/mach-iop32x/irq.c   |  2 +-
 arch/arm/mach-iop33x/irq.c   |  2 +-
 arch/arm/mach-ixp4xx/common.c|  2 +-
 arch/arm/mach-ks8695/irq.c   |  2 +-
 arch/arm/mach-lpc32xx/irq.c  |  2 +-
 arch/arm/mach-netx/generic.c |  2 +-
 arch/arm/mach-omap1/fpga.c   |  2 +-
 arch/arm/mach-omap1/irq.c|  2 +-
 arch/arm/mach-pxa/balloon3.c |  2 +-
 arch/arm/mach-pxa/irq.c  |  1 -
 arch/arm/mach-pxa/lpd270.c   |  2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c |  2 +-
 arch/arm/mach-pxa/pxa3xx.c   |  2 +-
 arch/arm/mach-pxa/viper.c|  2 +-
 arch/arm/mach-pxa/zeus.c |  2 +-
 arch/arm/mach-rpc/ecard.c|  2 +-
 arch/arm/mach-rpc/irq.c  | 16 
 arch/arm/mach-s3c24xx/bast-irq.c |  2 +-
 arch/arm/mach-s3c64xx/common.c   |  2 +-
 arch/arm/mach-sa1100/neponset.c  |  4 ++--
 arch/arm/mach-w90x900/irq.c  |  2 +-
 drivers/irqchip/irq-sa11x0.c |  1 -
 35 files changed, 45 insertions(+), 47 deletions(-)

diff --git a/arch/arm/common/it8152.c b/arch/arm/common/it8152.c
index 5114b68..96dabcb 100644
--- a/arch/arm/common/it8152.c
+++ b/arch/arm/common/it8152.c
@@ -91,7 +91,7 @@ void it8152_init_irq(void)
for (irq = IT8152_IRQ(0); irq = IT8152_LAST_IRQ; irq++) {
irq_set_chip_and_handler(irq, it8152_irq_chip,
 handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..339fc41 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -205,7 +205,7 @@ static void locomo_setup_irq(struct locomo *lchip)
for ( ; irq = lchip-irq_base + 3; irq++) {
irq_set_chip_and_handler(irq, locomo_chip, handle_level_irq);
irq_set_chip_data(irq, lchip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }

diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 93ee70d..680374d 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -486,7 +486,7 @@ static int sa_setup_irq(struct sa *sachip, unsigned 
irq_base)
irq_set_chip_and_handler(irq, sa_low_chip

[PATCH v3] irqchip: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Lee Jones l...@kernel.org
Cc: Alexander Shiyan shc_w...@mail.ru
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.

Rob

 drivers/irqchip/exynos-combiner.c |  2 +-
 drivers/irqchip/irq-armada-370-xp.c   |  3 +--
 drivers/irqchip/irq-bcm2835.c |  2 +-
 drivers/irqchip/irq-clps711x.c|  6 +++---
 drivers/irqchip/irq-gic-v3.c  |  5 ++---
 drivers/irqchip/irq-gic.c |  4 ++--
 drivers/irqchip/irq-hip04.c   |  4 ++--
 drivers/irqchip/irq-keystone.c|  2 +-
 drivers/irqchip/irq-mmp.c |  3 ---
 drivers/irqchip/irq-mxs.c |  1 -
 drivers/irqchip/irq-renesas-intc-irqpin.c |  1 -
 drivers/irqchip/irq-renesas-irqc.c|  1 -
 drivers/irqchip/irq-s3c24xx.c | 14 ++
 drivers/irqchip/irq-sun4i.c   |  2 +-
 drivers/irqchip/irq-versatile-fpga.c  |  2 +-
 drivers/irqchip/irq-vic.c |  2 +-
 drivers/irqchip/irq-vt8500.c  |  1 -
 drivers/irqchip/spear-shirq.c |  1 -
 18 files changed, 18 insertions(+), 38 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c 
b/drivers/irqchip/exynos-combiner.c
index 5c82e3b..a62cfd3 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -165,7 +165,7 @@ static int combiner_irq_domain_map(struct irq_domain *d, 
unsigned int irq,

irq_set_chip_and_handler(irq, combiner_chip, handle_level_irq);
irq_set_chip_data(irq, combiner_data[hw  3]);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_set_probe(irq);

return 0;
 }
diff --git a/drivers/irqchip/irq-armada-370-xp.c 
b/drivers/irqchip/irq-armada-370-xp.c
index 0d3b0fe..017f881 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -201,7 +201,6 @@ static int armada_370_xp_msi_map(struct irq_domain *domain, 
unsigned int virq,
 {
irq_set_chip_and_handler(virq, armada_370_xp_msi_irq_chip,
 handle_simple_irq);
-   set_irq_flags(virq, IRQF_VALID);

return 0;
 }
@@ -318,7 +317,7 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
irq_set_chip_and_handler(virq, armada_370_xp_irq_chip,
handle_level_irq);
}
-   set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+   irq_set_probe(virq);

return 0;
 }
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index e68c3b6..9c4ba16 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -165,7 +165,7 @@ static int __init armctrl_of_init(struct device_node *node,
BUG_ON(irq = 0);
irq_set_chip_and_handler(irq, armctrl_chip,
handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_set_probe(irq);
}
}

diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
index 33127f1..2e74e81 100644
--- a/drivers/irqchip/irq-clps711x.c
+++ b/drivers/irqchip/irq-clps711x.c
@@ -133,14 +133,14 @@ static int __init clps711x_intc_irq_map(struct irq_domain 
*h, unsigned int virq,
irq_hw_number_t hw)
 {
irq_flow_handler_t handler = handle_level_irq;
-   unsigned int flags = IRQF_VALID | IRQF_PROBE;
+   unsigned int flags = 0;

if (!clps711x_irqs[hw].flags)
return 0;

if (clps711x_irqs[hw].flags  CLPS711X_FLAG_FIQ) {
handler = handle_bad_irq;
-   flags |= IRQF_NOAUTOEN;
+   flags |= IRQ_NOAUTOEN;
} else if (clps711x_irqs[hw].eoi) {
handler = handle_fasteoi_irq

[PATCH v3] pinctrl: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Acked-by: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Lee Jones l...@kernel.org
Cc: Matthias Brugger matthias@gmail.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: linux-g...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.

Rob

 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 1 -
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 --
 drivers/pinctrl/pinctrl-single.c  | 5 -
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 1 -
 drivers/pinctrl/samsung/pinctrl-exynos5440.c  | 1 -
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 2 --
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 2 --
 7 files changed, 14 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 6177315..29e2203 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -989,7 +989,6 @@ static int bcm2835_pinctrl_probe(struct platform_device 
*pdev)
irq_set_chip_and_handler(irq, bcm2835_gpio_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, pc);
-   set_irq_flags(irq, IRQF_VALID);
}

for (i = 0; i  BCM2835_NUM_BANKS; i++) {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ad1ea16..661677c 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1348,11 +1348,9 @@ int mtk_pctrl_init(struct platform_device *pdev,
irq_set_chip_and_handler(virq, mtk_pinctrl_irq_chip,
handle_level_irq);
irq_set_chip_data(virq, pctl);
-   set_irq_flags(virq, IRQF_VALID);
};

irq_set_chained_handler_and_data(irq, mtk_eint_irq_handler, pctl);
-   set_irq_flags(irq, IRQF_VALID);
return 0;

 chip_error:
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 0b8d480..123a9ff 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1716,12 +1716,7 @@ static int pcs_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
irq_set_chip_data(irq, pcs_soc);
irq_set_chip_and_handler(irq, pcs-chip,
 handle_level_irq);
-
-#ifdef CONFIG_ARM
-   set_irq_flags(irq, IRQF_VALID);
-#else
irq_set_noprobe(irq);
-#endif

return 0;
 }
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index b18dabb..0e8add9 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -256,7 +256,6 @@ static int exynos_eint_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_chip_data(virq, b);
irq_set_chip_and_handler(virq, b-irq_chip-chip,
handle_level_irq);
-   set_irq_flags(virq, IRQF_VALID);
return 0;
 }

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c 
b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
index f5619fb..e7d1c9e 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
@@ -929,7 +929,6 @@ static int exynos5440_gpio_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_chip_data(virq, d);
irq_set_chip_and_handler(virq, exynos5440_gpio_irq_chip,
handle_level_irq);
-   set_irq_flags(virq, IRQF_VALID);
return 0;
 }

diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index 01b43db..f218be7 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -437,7 +437,6 @@ static int s3c24xx_gpf_irq_map(struct irq_domain *h, 
unsigned int virq

Re: [PATCH v2 06/13] irqchip: kill off set_irq_flags usage

[Rob Herring]

On Sun, Jul 12, 2015 at 11:43 AM, Thomas Gleixner t...@linutronix.de wrote:
 On Sun, 12 Jul 2015, Rob Herring wrote:

 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not

 clear IRQ_NOPROBE, right?

Both set and clear really. The state of IRQ_NOPROBE is a don't care in
most cases as you have outlined below. Are the cases of setting
IRQ_NOPROBE really needed or simply a bunch of copy and paste?

I've noticed I have a few places wrong with probe setting though, so
I'll be sending a v3.

 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

 Looking at the irq probe users:

 drivers/input/touchscreen/ucb1400_ts.c
 drivers/mfd/ucb1x00-core.c

 The probe function was added in the initial implementation of the
 driver (2006), so it predates device tree.

We still have lots of platforms which are not (and probably never will
be) DT. Certainly, DT only irqchips should be easy to make consistent.
The older stuff is harder and not frequently tested.

 drivers/net/appletalk/ltpc.c
 drivers/net/arcnet/com20020-isa.c
 drivers/net/arcnet/com90io.c
 drivers/net/arcnet/com90xx.c

 Surely not stuff you find on todays ARM systems

 drivers/net/ethernet/8390/ne.c
 drivers/net/ethernet/8390/wd.c
 drivers/net/ethernet/amd/lance.c
 drivers/net/ethernet/amd/ni65.c
 drivers/net/ethernet/amd/pcnet32.c

 Ditto

 drivers/net/ethernet/smsc/smc911x.c
 drivers/net/ethernet/smsc/smc9194.c
 drivers/net/ethernet/smsc/smc91x.c

 Those might still be, but on the DT based boards the probing should be
 completely irrelevant

Yes, these are quite common on ARM boards, and probably few if any
rely on irq probing regardless of DT.

 drivers/net/hamradio/dmascc.c
 drivers/net/wan/cosa.c
 drivers/net/wan/sbni.c
 drivers/parport/parport_pc.c

 Surely not stuff you find on todays ARM systems

 drivers/pcmcia/yenta_socket.c

 Russell might still use that.

 drivers/scsi/NCR53c406a.c
 drivers/scsi/sym53c416.c
 drivers/tty/cyclades.c

 Surely not stuff you find on todays ARM systems

 drivers/tty/serial/8250/8250_core.c

 The irq probing is used by

 mach-imx/mach-mx31ads.c
 mach-iop32x/n2100.c

 and X86

 So in most of the irqchip drivers, this is irrelevant.

Agreed, but that's a separate series I think. I'm trying not to change
behavior with this series. Are you proposing I do something different
with this patch?

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

[PATCH v2 10/13] pinctrl: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Acked-by: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Lee Jones l...@kernel.org
Cc: Matthias Brugger matthias@gmail.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: linux-g...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 1 -
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 --
 drivers/pinctrl/pinctrl-single.c  | 5 -
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 1 -
 drivers/pinctrl/samsung/pinctrl-exynos5440.c  | 1 -
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 2 --
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 2 --
 7 files changed, 14 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index efcf2a2..0cfdbb5 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -987,7 +987,6 @@ static int bcm2835_pinctrl_probe(struct platform_device 
*pdev)
irq_set_chip_and_handler(irq, bcm2835_gpio_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, pc);
-   set_irq_flags(irq, IRQF_VALID);
}
 
for (i = 0; i  BCM2835_NUM_BANKS; i++) {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ad1ea16..661677c 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1348,11 +1348,9 @@ int mtk_pctrl_init(struct platform_device *pdev,
irq_set_chip_and_handler(virq, mtk_pinctrl_irq_chip,
handle_level_irq);
irq_set_chip_data(virq, pctl);
-   set_irq_flags(virq, IRQF_VALID);
};
 
irq_set_chained_handler_and_data(irq, mtk_eint_irq_handler, pctl);
-   set_irq_flags(irq, IRQF_VALID);
return 0;
 
 chip_error:
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index b2de09d..d00a990 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1716,12 +1716,7 @@ static int pcs_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
irq_set_chip_data(irq, pcs_soc);
irq_set_chip_and_handler(irq, pcs-chip,
 handle_level_irq);
-
-#ifdef CONFIG_ARM
-   set_irq_flags(irq, IRQF_VALID);
-#else
irq_set_noprobe(irq);
-#endif
 
return 0;
 }
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index b18dabb..0e8add9 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -256,7 +256,6 @@ static int exynos_eint_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_chip_data(virq, b);
irq_set_chip_and_handler(virq, b-irq_chip-chip,
handle_level_irq);
-   set_irq_flags(virq, IRQF_VALID);
return 0;
 }
 
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c 
b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
index f5619fb..e7d1c9e 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
@@ -929,7 +929,6 @@ static int exynos5440_gpio_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_chip_data(virq, d);
irq_set_chip_and_handler(virq, exynos5440_gpio_irq_chip,
handle_level_irq);
-   set_irq_flags(virq, IRQF_VALID);
return 0;
 }
 
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index 01b43db..f218be7 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -437,7 +437,6 @@ static int s3c24xx_gpf_irq_map(struct irq_domain *h, 
unsigned int virq,
 handle_edge_irq);
}
irq_set_chip_data(virq, bank

[PATCH v2 01/13] ARM: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Gregory Clement gregory.clem...@free-electrons.com
Acked-by: Hans Ulli Kroll ulli.kr...@googlemail.com
Cc: Shawn Guo shawn@linaro.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Imre Kaloz ka...@openwrt.org
Acked-by: Krzysztof Halasa khal...@piap.pl
Cc: Greg Ungerer g...@uclinux.org
Cc: Roland Stigge sti...@antcom.de
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Mack dan...@zonque.org
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Robert Jarzmik robert.jarz...@free.fr
Cc: Simtec Linux Team li...@simtec.co.uk
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-by: Wan ZongShun mcuos@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
---
 arch/arm/common/it8152.c |  2 +-
 arch/arm/common/locomo.c |  2 +-
 arch/arm/common/sa.c |  4 ++--
 arch/arm/mach-davinci/cp_intc.c  |  2 +-
 arch/arm/mach-dove/irq.c |  2 +-
 arch/arm/mach-ebsa110/core.c |  2 +-
 arch/arm/mach-footbridge/common.c|  2 +-
 arch/arm/mach-footbridge/isa-irq.c   |  8 
 arch/arm/mach-gemini/gpio.c  |  2 +-
 arch/arm/mach-gemini/irq.c   |  2 +-
 arch/arm/mach-imx/3ds_debugboard.c   |  2 +-
 arch/arm/mach-imx/mach-mx31ads.c |  2 +-
 arch/arm/mach-iop13xx/irq.c  |  2 +-
 arch/arm/mach-iop32x/irq.c   |  2 +-
 arch/arm/mach-iop33x/irq.c   |  2 +-
 arch/arm/mach-ixp4xx/common.c|  2 +-
 arch/arm/mach-ks8695/irq.c   |  2 +-
 arch/arm/mach-lpc32xx/irq.c  |  2 +-
 arch/arm/mach-netx/generic.c |  2 +-
 arch/arm/mach-omap1/fpga.c   |  2 +-
 arch/arm/mach-omap1/irq.c|  2 +-
 arch/arm/mach-pxa/balloon3.c |  2 +-
 arch/arm/mach-pxa/irq.c  |  1 -
 arch/arm/mach-pxa/lpd270.c   |  2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c |  2 +-
 arch/arm/mach-pxa/pxa3xx.c   |  2 +-
 arch/arm/mach-pxa/viper.c|  2 +-
 arch/arm/mach-pxa/zeus.c |  2 +-
 arch/arm/mach-rpc/ecard.c|  2 +-
 arch/arm/mach-rpc/irq.c  | 16 
 arch/arm/mach-s3c24xx/bast-irq.c |  2 +-
 arch/arm/mach-s3c64xx/common.c   |  2 +-
 arch/arm/mach-sa1100/neponset.c  |  4 ++--
 arch/arm/mach-w90x900/irq.c  |  2 +-
 drivers/irqchip/irq-sa11x0.c |  1 -
 35 files changed, 45 insertions(+), 47 deletions(-)

diff --git a/arch/arm/common/it8152.c b/arch/arm/common/it8152.c
index 5114b68..96dabcb 100644
--- a/arch/arm/common/it8152.c
+++ b/arch/arm/common/it8152.c
@@ -91,7 +91,7 @@ void it8152_init_irq(void)
for (irq = IT8152_IRQ(0); irq = IT8152_LAST_IRQ; irq++) {
irq_set_chip_and_handler(irq, it8152_irq_chip,
 handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }
 
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..339fc41 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -205,7 +205,7 @@ static void locomo_setup_irq(struct locomo *lchip)
for ( ; irq = lchip-irq_base + 3; irq++) {
irq_set_chip_and_handler(irq, locomo_chip, handle_level_irq);
irq_set_chip_data(irq, lchip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }
 
diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 93ee70d..680374d 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -486,7 +486,7 @@ static int sa_setup_irq(struct sa *sachip, unsigned 
irq_base)
irq_set_chip_and_handler(irq, sa_low_chip,
 handle_edge_irq);
irq_set_chip_data(irq, sachip

Re: [PATCH 00/21] On-demand device registration

[Rob Herring]

On Mon, Jun 22, 2015 at 10:23 AM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:
 On 28 May 2015 at 06:33, Rob Herring robherri...@gmail.com wrote:
 On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:
 Hello,

 I have a problem with the panel on my Tegra Chromebook taking longer than
 expected to be ready during boot (Stéphane Marchesin reported what is
 basically the same issue in [0]), and have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing 
 with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series 
 to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 I like the concept and novel approach.

 This basically reuses the information that is already implicit in the 
 probe()
 implementations, saving us from refactoring existing drivers or adding
 information to DTBs.

 Something I'm not completely happy with is that I have had to move the call 
 to
 of_platform_populate after all platform drivers have been registered.
 Otherwise I don't see how I could register drivers on demand as we don't 
 have
 yet each driver's compatible strings.

 Yeah, this is the opposite of what we'd really like.

 Can you elaborate on the reasons why we would like to have devices
 registered before built-in drivers finish registering, even if we
 don't probe them yet?

My main thought was for modules we will almost always have devices
appearing first. More generally, we can have devices and drivers
coming or going at any point in time and should not put restrictions
on ordering.

Also, I think all the probe ordering and dependency tracking should be
done within the driver core (i.e. dependencies are a list of struct
devices). At some level it has to become firmware specific, but we
want to minimize that part. I could be convinced otherwise and you
have put more thought into this problem than I have.

 Ideally, we would
 have a solution that works for modules too. However, we're no worse
 off. We pretty much build-in dependencies to avoid module ordering
 problems.

 Nod, I haven't looked yet at requesting modules on-demand, but I guess
 it should be doable. Modules that have dependencies described in the
 firmware should get them probed automatically already though.

 Perhaps we need to make the probing on-demand rather than simply on
 device-driver match occurring.

 I'm afraid that too much old code depends on that. For example, Rafael
 pointed out to the PNP subsystem, which registers a driver that will
 probe devices with the EISA ID PNP0c02 to reserve memory regions for
 devices that will be probed later.

 http://lxr.free-electrons.com/source/drivers/pnp/system.c

 My understanding is that probing of PNP0c02 devices must happen before
 the actual devices that depend on those regions are probed, so if we
 decoupled the probing from the driver/device registration, we would be
 breaking that assumption.

That shouldn't matter as PNP matching is PNP specific. We already have
different ways of matching with device/driver name or of_match_table
for example. Changing how and when OF matching occurs would not affect
PNP matching. We do matching on device and driver add currently. For
the when part, we would need to add what I'll call async matching or
deferred matching which in addition to matching on the of_match_table
also matches on the dependency list having probed. Your last series
essentially does this, but the difference is yours is not OF specific
and I think it needs to be. I mean it is OF specific only in the
aspect that matching already is. From a driver and subsystem
standpoint, it should not be OF specific much like deferred probe is
not OF specific, but in reality only occurs (currently) on OF probed
drivers.

 For machs that don't move of_platform_populate() to a later point, these
 patches shouldn't cause any problems but it's not guaranteed that we'll 
 avoid
 all the deferred probes as some drivers may not be registered yet.

 Ideally, of_platform_populate is not explicitly called by each
 platform. So I think we need to make this work for the default case.

 The problem is that some platforms will need fixing because some
 initcalls assume that some devices will have been registered already,
 or even probed. I think removing those assumptions shouldn't be
 problematic because I haven't had much trouble with this on the four
 platforms I have tested with, but I cannot test every board that is
 supported upstream.

 I can ask though the KernelCI folks to boot my branch in all their
 boards and make sure that those work when of_platform_populate is
 called in late_initcall.

I'd imagine Kevin would be happy to. That is still a subset of h/w, so
we'd need a way to disable any solution.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in

Re: [PATCH 07/15] irqchip: kill off set_irq_flags usage

[Rob Herring]

On Tue, Jun 9, 2015 at 1:26 PM, Rob Herring r...@kernel.org wrote:
 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

[...]

 diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
 index 33127f1..e3609ae 100644
 --- a/drivers/irqchip/irq-clps711x.c
 +++ b/drivers/irqchip/irq-clps711x.c
 @@ -133,14 +133,14 @@ static int __init clps711x_intc_irq_map(struct 
 irq_domain *h, unsigned int virq,
 irq_hw_number_t hw)
  {
 irq_flow_handler_t handler = handle_level_irq;
 -   unsigned int flags = IRQF_VALID | IRQF_PROBE;
 +   unsigned int flags = 0;

 if (!clps711x_irqs[hw].flags)
 return 0;

 if (clps711x_irqs[hw].flags  CLPS711X_FLAG_FIQ) {
 handler = handle_bad_irq;
 -   flags |= IRQF_NOAUTOEN;
 +   flags |= IRQ_NOAUTOEN;
 } else if (clps711x_irqs[hw].eoi) {
 handler = handle_fasteoi_irq;
 }
 @@ -150,7 +150,7 @@ static int __init clps711x_intc_irq_map(struct irq_domain 
 *h, unsigned int virq,
 writel_relaxed(0, clps711x_intc-base + 
 clps711x_irqs[hw].eoi);

 irq_set_chip_and_handler(virq, clps711x_intc_chip, handler);
 -   set_irq_flags(virq, flags);
 +   irq_modify_status_flags(irq, IRQ_NOPROBE, flags);

One fix needed here:

diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
index e3609ae..2e74e81 100644
--- a/drivers/irqchip/irq-clps711x.c
+++ b/drivers/irqchip/irq-clps711x.c
@@ -150,7 +150,7 @@ static int __init clps711x_intc_irq_map(struct
irq_domain *h, unsigned int virq,
writel_relaxed(0, clps711x_intc-base + clps711x_irqs[hw].eoi);

irq_set_chip_and_handler(virq, clps711x_intc_chip, handler);
-   irq_modify_status_flags(irq, IRQ_NOPROBE, flags);
+   irq_modify_status(virq, IRQ_NOPROBE, flags);

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

[PATCH 11/15] pinctrl: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Lee Jones l...@kernel.org
Cc: Matthias Brugger matthias@gmail.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: linux-g...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 1 -
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 --
 drivers/pinctrl/pinctrl-single.c  | 5 -
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 1 -
 drivers/pinctrl/samsung/pinctrl-exynos5440.c  | 1 -
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 2 --
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 2 --
 7 files changed, 14 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 8d908e3..de34017 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -987,7 +987,6 @@ static int bcm2835_pinctrl_probe(struct platform_device 
*pdev)
irq_set_chip_and_handler(irq, bcm2835_gpio_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, pc);
-   set_irq_flags(irq, IRQF_VALID);
}
 
for (i = 0; i  BCM2835_NUM_BANKS; i++) {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 474812e..e80cd1a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1239,12 +1239,10 @@ int mtk_pctrl_init(struct platform_device *pdev,
irq_set_chip_and_handler(virq, mtk_pinctrl_irq_chip,
handle_level_irq);
irq_set_chip_data(virq, pctl);
-   set_irq_flags(virq, IRQF_VALID);
};
 
irq_set_chained_handler(irq, mtk_eint_irq_handler);
irq_set_handler_data(irq, pctl);
-   set_irq_flags(irq, IRQF_VALID);
return 0;
 
 chip_error:
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 13b45f2..6f0da84 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1716,12 +1716,7 @@ static int pcs_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
irq_set_chip_data(irq, pcs_soc);
irq_set_chip_and_handler(irq, pcs-chip,
 handle_level_irq);
-
-#ifdef CONFIG_ARM
-   set_irq_flags(irq, IRQF_VALID);
-#else
irq_set_noprobe(irq);
-#endif
 
return 0;
 }
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 0b7afa5..9996183 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -256,7 +256,6 @@ static int exynos_eint_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_chip_data(virq, b);
irq_set_chip_and_handler(virq, b-irq_chip-chip,
handle_level_irq);
-   set_irq_flags(virq, IRQF_VALID);
return 0;
 }
 
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c 
b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
index 86192be..3eb7b11 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
@@ -929,7 +929,6 @@ static int exynos5440_gpio_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_chip_data(virq, d);
irq_set_chip_and_handler(virq, exynos5440_gpio_irq_chip,
handle_level_irq);
-   set_irq_flags(virq, IRQF_VALID);
return 0;
 }
 
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index f1993f42..189f15b 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -437,7 +437,6 @@ static int s3c24xx_gpf_irq_map(struct irq_domain *h, 
unsigned int virq,
 handle_edge_irq);
}
irq_set_chip_data(virq

[PATCH 01/15] ARM: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Gregory Clement gregory.clem...@free-electrons.com
Cc: Hans Ulli Kroll ulli.kr...@googlemail.com
Cc: Shawn Guo shawn@linaro.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Imre Kaloz ka...@openwrt.org
Cc: Krzysztof Halasa khal...@piap.pl
Cc: Greg Ungerer g...@uclinux.org
Cc: Roland Stigge sti...@antcom.de
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Mack dan...@zonque.org
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Robert Jarzmik robert.jarz...@free.fr
Cc: Simtec Linux Team li...@simtec.co.uk
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Wan ZongShun mcuos@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
---
 arch/arm/common/it8152.c |  2 +-
 arch/arm/common/locomo.c |  2 +-
 arch/arm/common/sa.c |  4 ++--
 arch/arm/mach-davinci/cp_intc.c  |  2 +-
 arch/arm/mach-dove/irq.c |  2 +-
 arch/arm/mach-ebsa110/core.c |  2 +-
 arch/arm/mach-footbridge/common.c|  2 +-
 arch/arm/mach-footbridge/isa-irq.c   |  8 
 arch/arm/mach-gemini/gpio.c  |  2 +-
 arch/arm/mach-gemini/irq.c   |  2 +-
 arch/arm/mach-imx/3ds_debugboard.c   |  2 +-
 arch/arm/mach-imx/mach-mx31ads.c |  2 +-
 arch/arm/mach-iop13xx/irq.c  |  2 +-
 arch/arm/mach-iop32x/irq.c   |  2 +-
 arch/arm/mach-iop33x/irq.c   |  2 +-
 arch/arm/mach-ixp4xx/common.c|  2 +-
 arch/arm/mach-ks8695/irq.c   |  2 +-
 arch/arm/mach-lpc32xx/irq.c  |  2 +-
 arch/arm/mach-netx/generic.c |  2 +-
 arch/arm/mach-omap1/fpga.c   |  2 +-
 arch/arm/mach-omap1/irq.c|  2 +-
 arch/arm/mach-pxa/balloon3.c |  2 +-
 arch/arm/mach-pxa/irq.c  |  1 -
 arch/arm/mach-pxa/lpd270.c   |  2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c |  2 +-
 arch/arm/mach-pxa/pxa3xx.c   |  2 +-
 arch/arm/mach-pxa/viper.c|  2 +-
 arch/arm/mach-pxa/zeus.c |  2 +-
 arch/arm/mach-rpc/ecard.c|  2 +-
 arch/arm/mach-rpc/irq.c  | 16 
 arch/arm/mach-s3c24xx/bast-irq.c |  2 +-
 arch/arm/mach-s3c64xx/common.c   |  2 +-
 arch/arm/mach-sa1100/irq.c   |  1 -
 arch/arm/mach-sa1100/neponset.c  |  4 ++--
 arch/arm/mach-w90x900/irq.c  |  2 +-
 35 files changed, 45 insertions(+), 47 deletions(-)

diff --git a/arch/arm/common/it8152.c b/arch/arm/common/it8152.c
index 5114b68..96dabcb 100644
--- a/arch/arm/common/it8152.c
+++ b/arch/arm/common/it8152.c
@@ -91,7 +91,7 @@ void it8152_init_irq(void)
for (irq = IT8152_IRQ(0); irq = IT8152_LAST_IRQ; irq++) {
irq_set_chip_and_handler(irq, it8152_irq_chip,
 handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }
 
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..339fc41 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -205,7 +205,7 @@ static void locomo_setup_irq(struct locomo *lchip)
for ( ; irq = lchip-irq_base + 3; irq++) {
irq_set_chip_and_handler(irq, locomo_chip, handle_level_irq);
irq_set_chip_data(irq, lchip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }
 
diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 5cc779c..139aa3c 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -486,7 +486,7 @@ static int sa_setup_irq(struct sa *sachip, unsigned 
irq_base)
irq_set_chip_and_handler(irq, sa_low_chip,
 handle_edge_irq);
irq_set_chip_data(irq, sachip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE

[PATCH 07/15] irqchip: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Lee Jones l...@kernel.org
Cc: Alexander Shiyan shc_w...@mail.ru
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
---
 drivers/irqchip/exynos-combiner.c |  2 +-
 drivers/irqchip/irq-armada-370-xp.c   |  3 +--
 drivers/irqchip/irq-bcm2835.c |  2 +-
 drivers/irqchip/irq-clps711x.c|  6 +++---
 drivers/irqchip/irq-gic-v3.c  |  5 ++---
 drivers/irqchip/irq-gic.c |  4 ++--
 drivers/irqchip/irq-hip04.c   |  4 ++--
 drivers/irqchip/irq-keystone.c|  2 +-
 drivers/irqchip/irq-mmp.c |  3 ---
 drivers/irqchip/irq-mxs.c |  1 -
 drivers/irqchip/irq-renesas-intc-irqpin.c |  1 -
 drivers/irqchip/irq-renesas-irqc.c|  1 -
 drivers/irqchip/irq-s3c24xx.c | 14 ++
 drivers/irqchip/irq-sun4i.c   |  2 +-
 drivers/irqchip/irq-versatile-fpga.c  |  2 +-
 drivers/irqchip/irq-vic.c |  2 +-
 drivers/irqchip/irq-vt8500.c  |  1 -
 drivers/irqchip/spear-shirq.c |  1 -
 18 files changed, 18 insertions(+), 38 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c 
b/drivers/irqchip/exynos-combiner.c
index 5945223..46ecb4d 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -159,7 +159,7 @@ static int combiner_irq_domain_map(struct irq_domain *d, 
unsigned int irq,
 
irq_set_chip_and_handler(irq, combiner_chip, handle_level_irq);
irq_set_chip_data(irq, combiner_data[hw  3]);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_set_noprobe(irq);
 
return 0;
 }
diff --git a/drivers/irqchip/irq-armada-370-xp.c 
b/drivers/irqchip/irq-armada-370-xp.c
index daccc8b..af1d600 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -201,7 +201,6 @@ static int armada_370_xp_msi_map(struct irq_domain *domain, 
unsigned int virq,
 {
irq_set_chip_and_handler(virq, armada_370_xp_msi_irq_chip,
 handle_simple_irq);
-   set_irq_flags(virq, IRQF_VALID);
 
return 0;
 }
@@ -318,7 +317,7 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
irq_set_chip_and_handler(virq, armada_370_xp_irq_chip,
handle_level_irq);
}
-   set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+   irq_set_noprobe(virq);
 
return 0;
 }
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index 5916d6c..66c30c6 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -165,7 +165,7 @@ static int __init armctrl_of_init(struct device_node *node,
BUG_ON(irq = 0);
irq_set_chip_and_handler(irq, armctrl_chip,
handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_set_noprobe(irq);
}
}
 
diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
index 33127f1..e3609ae 100644
--- a/drivers/irqchip/irq-clps711x.c
+++ b/drivers/irqchip/irq-clps711x.c
@@ -133,14 +133,14 @@ static int __init clps711x_intc_irq_map(struct irq_domain 
*h, unsigned int virq,
irq_hw_number_t hw)
 {
irq_flow_handler_t handler = handle_level_irq;
-   unsigned int flags = IRQF_VALID | IRQF_PROBE;
+   unsigned int flags = 0;
 
if (!clps711x_irqs[hw].flags)
return 0;
 
if (clps711x_irqs[hw].flags  CLPS711X_FLAG_FIQ) {
handler = handle_bad_irq;
-   flags |= IRQF_NOAUTOEN;
+   flags |= IRQ_NOAUTOEN;
} else if (clps711x_irqs[hw].eoi) {
handler = handle_fasteoi_irq;
}
@@ -150,7 +150,7 @@ static int __init clps711x_intc_irq_map(struct irq_domain 
*h, unsigned int

Re: [PATCH 00/21] On-demand device registration

[Rob Herring]

On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:
 Hello,

 I have a problem with the panel on my Tegra Chromebook taking longer than
 expected to be ready during boot (Stéphane Marchesin reported what is
 basically the same issue in [0]), and have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be possible
 to achieve the same by registering devices as they are referenced by other
 devices.

I like the concept and novel approach.

 This basically reuses the information that is already implicit in the probe()
 implementations, saving us from refactoring existing drivers or adding
 information to DTBs.

 Something I'm not completely happy with is that I have had to move the call to
 of_platform_populate after all platform drivers have been registered.
 Otherwise I don't see how I could register drivers on demand as we don't have
 yet each driver's compatible strings.

Yeah, this is the opposite of what we'd really like. Ideally, we would
have a solution that works for modules too. However, we're no worse
off. We pretty much build-in dependencies to avoid module ordering
problems.

Perhaps we need to make the probing on-demand rather than simply on
device-driver match occurring.

 For machs that don't move of_platform_populate() to a later point, these
 patches shouldn't cause any problems but it's not guaranteed that we'll avoid
 all the deferred probes as some drivers may not be registered yet.

Ideally, of_platform_populate is not explicitly called by each
platform. So I think we need to make this work for the default case.

 I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
 patches were enough to eliminate all the deferred probes.

 With this series I get the kernel to output to the panel in 0.5s, instead of 
 2.8s.

That's certainly compelling.

Rob


 Regards,

 Tomeu

 [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

 [1] https://lkml.org/lkml/2014/5/12/452

 Tomeu Vizoso (21):
   regulator: core: Reduce critical area in _regulator_get
   ARM: tegra: Add gpio-ranges property
   ARM: tegra: Register drivers before devices
   ARM: EXYNOS: Register drivers before devices
   ARM i.MX6q: Register drivers before devices
   of/platform: Add of_platform_device_ensure()
   of/platform: Ensure device registration on lookup
   gpio: Probe GPIO drivers on demand
   gpio: Probe pinctrl devices on demand
   regulator: core: Probe regulators on demand
   drm: Probe panels on demand
   drm/tegra: Probe dpaux devices on demand
   i2c: core: Probe i2c master devices on demand
   pwm: Probe PWM chip devices on demand
   backlight: Probe backlight devices on demand
   usb: phy: Probe phy devices on demand
   clk: Probe clk providers on demand
   pinctrl: Probe pinctrl devices on demand
   phy: core: Probe phy providers on demand
   dma: of: Probe DMA controllers on demand
   power-supply: Probe power supplies on demand

  arch/arm/boot/dts/tegra124.dtsi |  1 +
  arch/arm/mach-exynos/exynos.c   |  4 +--
  arch/arm/mach-imx/mach-imx6q.c  | 12 -
  arch/arm/mach-tegra/tegra.c | 21 ++-
  drivers/clk/clk.c   |  3 +++
  drivers/dma/of-dma.c|  3 +++
  drivers/gpio/gpiolib-of.c   |  5 
  drivers/gpu/drm/drm_panel.c |  3 +++
  drivers/gpu/drm/tegra/dpaux.c   |  3 +++
  drivers/i2c/i2c-core.c  |  3 +++
  drivers/of/platform.c   | 53 
 +
  drivers/phy/phy-core.c  |  3 +++
  drivers/pinctrl/devicetree.c|  2 ++
  drivers/power/power_supply_core.c   |  3 +++
  drivers/pwm/core.c  |  3 +++
  drivers/regulator/core.c| 45 +++
  drivers/usb/phy/phy.c   |  3 +++
  drivers/video/backlight/backlight.c |  3 +++
  include/linux/of_platform.h |  2 ++
  19 files changed, 130 insertions(+), 45 deletions(-)

 --
 2.4.1

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

Re: [PATCH V5 1/2] mmc: dw_mmc: exynos: Support eMMC's HS400 mode

[Rob Herring]

On Wed, Jan 28, 2015 at 8:41 PM, Alim Akhtar alim.akh...@samsung.com wrote:
 From: Seungwon Jeon tgih@samsung.com

 Implements HS400 mode support for exynos host driver.
 This also include some updates as new mode is added.

 Signed-off-by: Seungwon Jeon tgih@samsung.com
 Signed-off-by: Alim Akhtar alim.akh...@samsung.com
 [Alim: addressed review comments]
 ---
  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 +
  drivers/mmc/host/dw_mmc-exynos.c   |  185 
 
  drivers/mmc/host/dw_mmc-exynos.h   |   19 +-
  drivers/mmc/host/dw_mmc.c  |   16 +-
  drivers/mmc/host/dw_mmc.h  |2 +
  5 files changed, 195 insertions(+), 34 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
 b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 index ee4fc05..aad9844 100644
 --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 @@ -36,6 +36,8 @@ Required Properties:
in transmit mode and CIU clock phase shift value in receive mode for double
data rate mode operation. Refer notes below for the order of the cells and 
 the
valid values.
 +* samsung,dw-mshc-hs400-timing: Specifies the value of CIU TX and RX clock 
 phase
 +  shift value for hs400 mode operation.

What are the units?

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

Re: [PATCH V9 10/14] Documentation: devicetree: Add vendor prefix for parade

[Rob Herring]

On Tue, Jan 20, 2015 at 10:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
 ps8622 eDP-LVDS converter bridge chip is from parade technologies

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 Acked-by: Inki Dae inki@samsung.com
 Tested-by: Rahul Sharma rahul.sha...@samsung.com
 Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
 Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk

Acked-by: Rob Herring r...@kernel.org

 ---
  .../devicetree/bindings/vendor-prefixes.txt|1 +
  1 file changed, 1 insertion(+)

 diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
 b/Documentation/devicetree/bindings/vendor-prefixes.txt
 index 4df1d78..eca48be 100644
 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
 +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
 @@ -125,6 +125,7 @@ nxp NXP Semiconductors
  onnn   ON Semiconductor Corp.
  opencores  OpenCores.org
  panasonic  Panasonic Corporation
 +parade Parade Technologies Inc.
  pericomPericom Technology Inc.
  phytec PHYTEC Messtechnik GmbH
  picochip   Picochip Ltd
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/21] irqchip: gic: killing gic_arch_extn and co, slowly

[Rob Herring]

On Wed, Jan 7, 2015 at 11:42 AM, Marc Zyngier marc.zyng...@arm.com wrote:
 The gic_arch_extn hack that a number of platform use has been nagging
 me for too long. It is only there for the benefit of a few platform,
 and yet it impacts all GIC users. Moreover, it gives people the wrong
 idea (let's use it to put some new custom hack in there...).

 But now that stacked irq domains have landed in -next, the time has
 come for gic_arch_extn to meet the Big Bit Bucket.

[...]

 - This actively *breaks* existing setups. Once you boot a new kernel
   with an old DT, suspend/resume *will* be broken. Old kernels on a
   new DT won't even boot! You've been warned. This really outline the
   necessity of actually describing the HW in device trees...

Just to be clear, you need some agreement from the maintainers of
those platforms before doing this. It doesn't appear there is
disagreement, but I don't see any explicit agreement either.

This seems to model the interrupts as chained, but at least for some
cases aren't these auxiliary controllers in parallel to the GIC? In
other words, do the they require configuration for interrupts to work
for the normal non-wakeup use? I'm not sure that the h/w is being
modeled any more accurately if that is the case. However, we don't
really have a way to describe an interrupt line is connected to 2
interrupt parents in DT, so I'm not sure what else you could do here.

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

Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver

[Rob Herring]

Adding Viresh.

On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patch adds the documentation for generic exynos memory bus frequency
 driver.

 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Kukjin Kim kg...@kernel.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  .../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 
 +
  1 file changed, 184 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt

 diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt 
 b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
 new file mode 100644
 index 000..c601e88
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
 @@ -0,0 +1,184 @@
 +
 +* Generic Exynos Memory Bus device
 +
 +The Samsung Exynos SoCs have many memory buses for data transfer between DRAM
 +memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common architecture
 +for memory buses. Generally, Exynos SoC express the memory bus by using 
 memory
 +bus group and block. The memory bus group has one more memory bus blocks and
 +OPP table (including frequency and voltage for DVFS), regulator, 
 devfreq-event
 +devices. Each memory bus block has a clock for own memory bus speen and
 +frequency table for DVFS. There are a little different among Exynos SoCs
 +because each Exynos SoC has the different sub-IP and differnt memory bus.
 +So, this difference should be specified in devicetree file.
 +
 +Required properties for memory bus group:
 +- compatible: Should be samsung,exynos-memory-bus.
 +- operating-points: the OPP table including frequency/voltage information to
 +  support DVFS (Dynamic Voltage/Frequency Scaling) feature.
 +- devfreq-events: the devfreq-event device to monitor the curret state of
 +  memory bus group.

I don't understand what goes in here.

 +- vdd-mem-supply: the regulator to provide memory bus group with the voltage.
 +
 +Required properties for memory bus block:
 +- clock-names : the name of clock used by the memory bus, memory-bus.
 +- clocks : phandles for clock specified in clock-names property.
 +- #clock-cells: should be 1.
 +- frequency: the frequency table to support DVFS feature.

So you have just defined a new OPP table format. We already have one
and Viresh is working to create a more extendable one. He asked about
what's needed in devfreq, so Viresh here you go. :)

 +
 +Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
 +   Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
 +   group includes one memory bus block between DRAM and eMMC. Also, INT
 +   memory bus group includes eight memory bus blocks which support each
 +   sub-IPs between DRAM and sub-IPs.
 +
 +   memory_bus_mif: memory_bus@0 {
 +   compatible = samsung,exynos-memory-bus;
 +
 +   operating-points = 
 +   40 875000
 +   20 80
 +   133000 80
 +   10 80
 +   5  80;
 +   status = disabled;

Why is this not part of the DDR controller or /memory node?

 +   blocks {
 +   dmc_block: memory_bus_block1 {
 +   clocks = cmu_dmc CLK_DIV_DMC;
 +   clock-names = memory-bus;
 +   frequency = 
 +   40
 +   20
 +   133000
 +   10
 +   5;

This is just duplicated from the operating-points table.

 +   };
 +   };
 +   };
 +
 +   memory_bus_int: memory_bus@1 {
 +   compatible = samsung,exynos-memory-bus;
 +
 +   operating-points = 
 +   40 95
 +   20 95
 +   133000 925000
 +   10 85
 +   8  85
 +   5  85;
 +
 +   status = disabled;
 +
 +   blocks {
 +   peri_block: memory_bus_block1 {

Why is this and the following nodes not part of the respective
peripheral nodes or buses. If you need more hierarchy in your bus add
that to DT first. I'm sure just a flat simple-bus was done which
doesn't reflect the actual bus and now you need it to.

 +   clocks = cmu CLK_DIV_ACLK_100;
 +   clock-names = memory-bus;
 +   frequency = 
 +   10
 +   10
 +   

Re: [PATCH v5 1/2] soc: samsung: add exynos chipid driver support

[Rob Herring]

On Fri, Dec 12, 2014 at 1:45 AM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 Hi Rob,

 On Thursday 11 December 2014 11:00 PM, Rob Herring wrote:

 On Thu, Dec 11, 2014 at 2:07 AM, Pankaj Dubey pankaj.du...@samsung.com
 wrote:

 Exynos SoCs have Chipid, for identification of product IDs
 and SoC revisions. This patch intendes to provide initialization
 code for all these functionalites.

[...]

 +static void __iomem *exynos_chipid_base;
 +
 +struct exynos_chipid_info exynos_soc_info;
 +EXPORT_SYMBOL(exynos_soc_info);


 The soc_device already has similar data.Why is this needed? Is it
 temporary for compatibility?


 struct soc_device_attribute can hold these two (product_id, and revision)
 but they are defined as char * in soc_device_atttribute, and I feel it's
 more specific for exposing via sysfs.

But what is exposed generically for sysfs should also be exposed
internally in the kernel generically.

 Also existing code in mach-exynos compares them via product_id/revision
 macros, so I can say to keep compatibility.

Perhaps you will have to change the users. Otherwise, I don't see the
point in moving this code as is. If there are a lot of users, then
having both old and new interface and moving them over one by one
would be okay. However, if this is widely used that is a problem in
itself.

 For early use?


 Yes, partially correct. These parameters will be required in during early
 boot, from mach-exynos/platsmp.c, by that time probe of chipid would not
 have happened. But usage of this is not limited to early users, even
 mach-exynos/pm.c will use this later any point of time.
 Since there are early users I added exynos_chipid_early_init which will be
 called via mach-exynos.c at very early stage [1].

 [1]: https://lkml.org/lkml/2014/12/11/47


 If for early use, then it
 should not be exported.


 Other reason to make and expose this structure was we can see that other
 fields of chipid bank (other than product_id and revision, which is not part
 of this patch as of now) can be used by other driver such as ASV (which is
 not yet part of mainline but is there for every exynos SoC).

 I do not exported this in my PATCH v4 [2] of this, and instead provided
 exposed functions to directly access product_id and revision, but sometime
 in future when we will need other fields of chipid bank, we will end-up
 adding new exported function for each new field, so decided to expose this
 structure itself.

More on this below.


 +void __init exynos_chipid_early_init(struct device *dev)
 +{
 +   struct device_node *np;
 +   const struct of_device_id *match;
 +
 +   if (exynos_chipid_base)
 +   return;
 +
 +   if (!dev)
 +   np = of_find_matching_node_and_match(NULL,
 +   of_exynos_chipid_ids, match);
 +   else
 +   np = dev-of_node;
 +
 +   if (!np)
 +   panic(%s, failed to find chipid node\n, __func__);


 Do you really want to halt booting here?


 Since some critical configuration are done in platsmp.c based on product_id
 and revision, I don't see any point moving ahead without it.
 Even if we allow to continue here it will crash or lead to system
 malfunction later during system boot for existing SoC support.

 Your console may not be up to

 see the panic anyway.


 I feel this we can still see via earlyprintk.

You can, yes. So when you don't boot getting no messages, you then
have to recompile to enable earlyprintk for exynos, load a new kernel,
and change your command line. That's not very good from a support
point of view. It would be better to boot while failing to boot
secondary cpus than not boot printing nothing. It is much better to
provide the warnings rather than have to debug why you are not
booting.

 +struct exynos_chipid_info {
 +   u32 product_id;
 +   u32 revision;
 +};


 Exposing this struct kernel wide in an SOC specific way concerns me. I
 would not like to see this done on every SOC family. That would become
 a mess.


 As of today chip-id can live up by exposing two APIs for getting product_id
 and revision, but in future when we need to access other fields we may end
 up adding new exported functions/extern functions. We had a discussion about
 it in Patch V4 [3].

Yes, but every SOC has an id and revision, so we should expose them in
a common way. For other fields, the mechanism to retrieve them should
probably be common, but the data could be custom.

Rob


 [3]: https://lkml.org/lkml/2014/12/10/748
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] soc: samsung: add exynos chipid driver support

[Rob Herring]

On Thu, Dec 11, 2014 at 2:07 AM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 Exynos SoCs have Chipid, for identification of product IDs
 and SoC revisions. This patch intendes to provide initialization
 code for all these functionalites.

 This driver usese existing binding for exnos-chipid.

s/usese/uses/
s/exnos/exynos/


 CC: Grant Likely grant.lik...@linaro.org
 CC: Rob Herring robh...@kernel.org
 CC: Linus Walleij linus.wall...@linaro.org
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 ---
  drivers/soc/Kconfig|   1 +
  drivers/soc/Makefile   |   1 +
  drivers/soc/samsung/Kconfig|  14 +++
  drivers/soc/samsung/Makefile   |   1 +
  drivers/soc/samsung/exynos-chipid.c| 168 
 +
  include/linux/soc/samsung/exynos-soc.h |  51 ++
  6 files changed, 236 insertions(+)
  create mode 100644 drivers/soc/samsung/Kconfig
  create mode 100644 drivers/soc/samsung/Makefile
  create mode 100644 drivers/soc/samsung/exynos-chipid.c
  create mode 100644 include/linux/soc/samsung/exynos-soc.h

 diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
 index 76d6bd4..c3abfbe 100644
 --- a/drivers/soc/Kconfig
 +++ b/drivers/soc/Kconfig
 @@ -1,6 +1,7 @@
  menu SOC (System On Chip) specific Drivers

  source drivers/soc/qcom/Kconfig
 +source drivers/soc/samsung/Kconfig
  source drivers/soc/ti/Kconfig
  source drivers/soc/versatile/Kconfig

 diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
 index 063113d..620366f 100644
 --- a/drivers/soc/Makefile
 +++ b/drivers/soc/Makefile
 @@ -3,6 +3,7 @@
  #

  obj-$(CONFIG_ARCH_QCOM)+= qcom/
 +obj-$(CONFIG_SOC_SAMSUNG)  += samsung/
  obj-$(CONFIG_ARCH_TEGRA)   += tegra/
  obj-$(CONFIG_SOC_TI)   += ti/
  obj-$(CONFIG_PLAT_VERSATILE)   += versatile/
 diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
 new file mode 100644
 index 000..2d83652
 --- /dev/null
 +++ b/drivers/soc/samsung/Kconfig
 @@ -0,0 +1,14 @@
 +#
 +# SAMSUNG SoC drivers
 +#
 +menu Samsung SOC driver support
 +
 +config SOC_SAMSUNG
 +   bool
 +
 +config EXYNOS_CHIPID
 +   bool
 +   depends on ARCH_EXYNOS
 +   select SOC_BUS

This is going to show an empty menu when ARCH_EXYNOS is not enabled.
The whole menu should probably have if ARCH_EXYNOS instead.

 +
 +endmenu
 diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
 new file mode 100644
 index 000..855ca05
 --- /dev/null
 +++ b/drivers/soc/samsung/Makefile
 @@ -0,0 +1 @@
 +obj-$(CONFIG_EXYNOS_CHIPID)+= exynos-chipid.o
 diff --git a/drivers/soc/samsung/exynos-chipid.c 
 b/drivers/soc/samsung/exynos-chipid.c
 new file mode 100644
 index 000..8968f83
 --- /dev/null
 +++ b/drivers/soc/samsung/exynos-chipid.c
 @@ -0,0 +1,168 @@
 +/*
 + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
 + *   http://www.samsung.com/
 + *
 + * EXYNOS - CHIP ID support
 + * Author: Pankaj Dubey pankaj.du...@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/io.h
 +#include linux/of.h
 +#include linux/of_address.h
 +#include linux/of_platform.h
 +#include linux/platform_device.h
 +#include linux/slab.h
 +#include linux/sys_soc.h
 +#include linux/soc/samsung/exynos-soc.h
 +
 +#define EXYNOS_SUBREV_MASK (0xF  4)
 +#define EXYNOS_MAINREV_MASK(0xF  0)
 +#define EXYNOS_REV_MASK(EXYNOS_SUBREV_MASK | 
 EXYNOS_MAINREV_MASK)
 +
 +static void __iomem *exynos_chipid_base;
 +
 +struct exynos_chipid_info exynos_soc_info;
 +EXPORT_SYMBOL(exynos_soc_info);

The soc_device already has similar data. Why is this needed? Is it
temporary for compatibility? For early use? If for early use, then it
should not be exported.


 +
 +static const char * __init product_id_to_name(unsigned int product_id)
 +{
 +   const char *soc_name;
 +   unsigned int soc_id = product_id  EXYNOS_SOC_MASK;
 +
 +   switch (soc_id) {
 +   case EXYNOS3250_SOC_ID:
 +   soc_name = EXYNOS3250;
 +   break;
 +   case EXYNOS4210_SOC_ID:
 +   soc_name = EXYNOS4210;
 +   break;
 +   case EXYNOS4212_SOC_ID:
 +   soc_name = EXYNOS4212;
 +   break;
 +   case EXYNOS4412_SOC_ID:
 +   soc_name = EXYNOS4412;
 +   break;
 +   case EXYNOS4415_SOC_ID:
 +   soc_name = EXYNOS4415;
 +   break;
 +   case EXYNOS5250_SOC_ID:
 +   soc_name = EXYNOS5250;
 +   break;
 +   case EXYNOS5260_SOC_ID:
 +   soc_name = EXYNOS5260;
 +   break;
 +   case EXYNOS5420_SOC_ID:
 +   soc_name = EXYNOS5420;
 +   break;
 +   case EXYNOS5440_SOC_ID:
 +   soc_name = EXYNOS5440;
 +   break;
 +   case

Re: [PATCH] tty/serial: samsung: Add earlycon support

[Rob Herring]

On 09/20/2014 08:39 AM, Tomasz Figa wrote:
 Hi Alim,
 
 Please see my comments inline.
 
 On 16.09.2014 13:32, Alim Akhtar wrote:
 Add earlycon support for the samsung serial port. This allows enabling
 the samsung serial port for console when early_params are parse and 
 processed.

 Signed-off-by: Alim Akhtar alim.akh...@samsung.com
 ---
  Documentation/kernel-parameters.txt |6 ++
  drivers/tty/serial/Kconfig  |1 +
  drivers/tty/serial/samsung.c|   17 +
  3 files changed, 24 insertions(+)

 diff --git a/Documentation/kernel-parameters.txt 
 b/Documentation/kernel-parameters.txt
 index 5ae8608..e01c0e5 100644
 --- a/Documentation/kernel-parameters.txt
 +++ b/Documentation/kernel-parameters.txt
 @@ -936,6 +936,12 @@ bytes respectively. Such letter suffixes can also be 
 entirely omitted.
  must already be setup and configured. Options are not
  yet supported.
  
 +samsung,addr

There will only ever be 1 samsung uart? This is an ABI to some extent,
so you will be stuck with it.

 +Start an early, polled-mode console on a samsung serial
 +port at the specified address. The samsung serial port
 +must already be setup and configured. Options are not
 +yet supported.
 +
 
 Couldn't you simply parse this from DT? I believe there is already code
 parsing stdout property in chosen node for earlycon purposes present in
 the kernel.

You should support both and it is just a OF_EARLYCON_DECLARE line to add.

 Anyway, we already had a patch for this in our internal tree, but it
 wasn't submitted because there was no support for early ioremap on ARM
 at that time. I haven't been following it since then (and I'm no longer
 at Samsung; Marek might be able to take this topic), is it already
 available?

No, but should be soonish. fixmap parts are being worked on by Kees.

Rob

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

Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7

[Rob Herring]

On Thu, Aug 28, 2014 at 12:27 PM, Marc Zyngier marc.zyng...@arm.com wrote:
 On 28/08/14 18:03, Mark Rutland wrote:

 From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001
 From: Mark Rutland mark.rutl...@arm.com
 Date: Thu, 28 Aug 2014 17:41:03 +0100
 Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use

 The ARM Generic Timer (AKA the architected timer, arm_arch_timer)
 features a CPU register (CNTFRQ) which firmware is intended to
 initialize, and non-secure software can read to determine the frequency
 of the timer. On CPUs with secure state, this register cannot be written
 from non-secure states.

 The firmware of early SoCs featuring the timer did not correctly
 initialize CNTFRQ correctly on all CPUs, requiring the frequency to be
 described in DT as a workaround. This workaround is not complete however
 as CNTFRQ is exposed to all software in a privileged non-secure mode,
 including KVM guests. The firmware and DTs for recent SoCs have followed

 I believe Xen is also affected by this.

 the example set by these early SoCs.

 This patch updates the arch timer binding documentation to make it
 clearer that the use of the clock-frequency property is a poor
 work-around. The MMIO generic timer binding is similarly updated, though
 this is less of a concern as there is generally no need to expose the
 MMIO timers to guest OSs.

 Signed-off-by: Mark Rutland mark.rutl...@arm.com
 Cc: Marc Zyngier marc.zyng...@arm.com

 Short of more explicit threats:

Why not also add WARNs (and mark for stable). People tend to notice
and fix those. If not the vendors, those pesky customers always
complain (the same ones that get concerned about BogoMIPS values being
too low).

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

Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7

[Rob Herring]

On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson o...@lixom.net wrote:
 On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland mark.rutl...@arm.com wrote:
 On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote:
 On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland mark.rutl...@arm.com wrote:
  Hi,
 
   +   cpus {
   +   #address-cells = 2;
   +   #size-cells = 0;
 
  Why size-cells=2? Can you not fit a cpuid in 32 bits?
 
  As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing
  CPU reg property) Linux can handle single-cell cpu node reg entries
  where /cpus/#address-cells = 1.
 
  I can't make any guarantees about other code (e.g. bootloaders) which
  might try to do things with cpu nodes, YMMV.

 Ok. If address-cells is kept at 2 the unit address needs to be changed
 to 0,0. So one or the other has to be changed.

 I'm happy either way.

 I'm not sure the rest of the tree had 0, prefixes on all of the
 unit-addresses for 64-bit addresses that were under 4GB, and I'm not
 sure that existing dts consistently do that either.

 Do we want to enforce that for all 64-bit unit-addresses?

 Yeah, I believe that's the only valid format for a 2-address-cell unit 
 address.

But we don't do leading 0's anywhere else like single cell unit
addresses. Buses expressed with ranges and offsets are one example.
Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we
don't do leading zero's there.

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

Re: [RESEND][PATCHv2 0/3] Fix for buggy u-boot memory banks

[Rob Herring]

On Tue, Jul 15, 2014 at 12:03 PM, Laura Abbott lau...@codeaurora.org wrote:
 Hi,

 This is a resend of the series to fix the uboot bug exposed by the removal
 of meminfo. I haven't gotten any acks though.

Is the bug with ATAGs that get converted to DT in the decompressor or
u-boot puts the wrong info in DT directly?

Rob


 Please help with review/acks. Grant/Rob, I'd still like this to go through
 the devicetree tree if possible.

 Thanks,
 Laura

 --
 The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
 hosted by The Linux Foundation

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

Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size

[Rob Herring]

On Wed, Jun 25, 2014 at 5:37 AM, Marc Zyngier marc.zyng...@arm.com wrote:
 All the Cortex-{A7,A15} implementations are using a GICv2. Same for
 the current arm64 platforms.

 Turns out that most of these platforms have described their GIC CPU
 interface size as being 4kB. while it is actually 8kB (the GICC_DIR
 register lives at offset 0x1000).

 This was found when converting the GIC driver to use EOImode==1 on
 GICv2-based systems. It uses the GICC_DIR register, and the result
 is a very early firework...

What's your plan for making the kernel change? Updating the dts files
is good, but that doesn't immediately help you if you have old dtbs.

 Signed-off-by: Marc Zyngier marc.zyng...@arm.com
 ---
  arch/arm/boot/dts/axm55xx.dtsi  | 2 +-
  arch/arm/boot/dts/dra7.dtsi | 2 +-
  arch/arm/boot/dts/ecx-2000.dts  | 2 +-

Acked-by: Rob Herring r...@kernel.org

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

Re: [PATCH 3/4] Documentation: devicetree: Fix tps65090 typos

[Rob Herring]

On Wed, Jun 25, 2014 at 6:43 AM, Andreas Färber afaer...@suse.de wrote:
 Am 25.06.2014 12:47, schrieb Mark Rutland:
 On Mon, Jun 23, 2014 at 06:27:04PM +0100, Doug Anderson wrote:
 Andreas,

 On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
 It's vsys-l{1,2}-supply, not vsys_l{1,2}-supply.

 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt 
 b/Documentation/devicetree/bindings/regulator/tps65090.txt
 index 34098023..ca69f5e 100644
 --- a/Documentation/devicetree/bindings/regulator/tps65090.txt
 +++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
 @@ -45,8 +45,8 @@ Example:
 infet5-supply = some_reg;
 infet6-supply = some_reg;
 infet7-supply = some_reg;
 -   vsys_l1-supply = some_reg;
 -   vsys_l2-supply = some_reg;
 +   vsys-l1-supply = some_reg;
 +   vsys-l2-supply = some_reg;

 Your change matches the code and all existing device trees in the
 Linux kernel.

 Could this fact please be mentioned in the commit message?

 Yes, I admit the commit message could've been clearer in stating that
 only the example is modified, not the actual specification. What about:

 Specification and existing device trees use vsys-l{1,2}-supply, not
 vsys_l{1,2}-supply. Fix the example to match the specification.

 Maybe also ... typos in example in the subject.

 Let me know whether I should send a v2 or let maintainers fix it up.

Please send v2.

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

[PATCH 1/2] ARM: exynos: cleanup kconfig option display

[Rob Herring]

From: Rob Herring r...@kernel.org

The addition of Exynos to multi-platform configs creates a mess of config
options with options appearing before the Exynos config option. This is
due to arch/arm/plat-samsung/Kconfig being included out of order with the
other Samsung platform kconfig files. Reorder the kconfig files and move
all the options into a sub-menu. Some of the options are dead, so remove
those as well.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
---
 arch/arm/Kconfig  |  3 +--
 arch/arm/plat-samsung/Kconfig | 17 +++--
 2 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 87b63fd..cbf0c37 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1009,8 +1009,6 @@ source arch/arm/mach-rockchip/Kconfig
 
 source arch/arm/mach-sa1100/Kconfig
 
-source arch/arm/plat-samsung/Kconfig
-
 source arch/arm/mach-socfpga/Kconfig
 
 source arch/arm/mach-spear/Kconfig
@@ -1028,6 +1026,7 @@ source arch/arm/mach-s5pc100/Kconfig
 source arch/arm/mach-s5pv210/Kconfig
 
 source arch/arm/mach-exynos/Kconfig
+source arch/arm/plat-samsung/Kconfig
 
 source arch/arm/mach-shmobile/Kconfig
 
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 243dfcb..ac032cd 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -35,27 +35,15 @@ config SAMSUNG_PM
  Base platform power management code for samsung code
 
 if PLAT_SAMSUNG
+menu Samsung Common options
 
 # boot configurations
 
 comment Boot options
 
-config S3C_BOOT_ERROR_RESET
-   bool S3C Reboot on decompression error
-   help
- Say y here to use the watchdog to reset the system if the
- kernel decompressor detects an error during decompression.
-
-config S3C_BOOT_UART_FORCE_FIFO
-   bool Force UART FIFO on during boot process
-   default y
-   help
- Say Y here to force the UART FIFOs on during the kernel
-uncompressor
-
-
 config S3C_LOWLEVEL_UART_PORT
int S3C UART to use for low-level messages
+   depends on ARCH_S3C64XX
default 0
help
  Choice of which UART port to use for the low-level messages,
@@ -503,4 +491,5 @@ config DEBUG_S3C_UART
default 2 if DEBUG_S3C_UART2
default 3 if DEBUG_S3C_UART3
 
+endmenu
 endif
-- 
1.9.1

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

Re: [PATCH 1/2 v2] spi: s3c64xx: use cs-gpios from spi node instead of cs-gpio

[Rob Herring]

On Tue, Jun 10, 2014 at 1:09 PM, Doug Anderson diand...@chromium.org wrote:
 Naveen / Sylwester,

 On Tue, Jun 10, 2014 at 4:00 AM, Naveen Krishna Ch
 naveenkrishna...@gmail.com wrote:
 Can we support both cs-gpio and cs-gpios for backward compatibility ?
 After your change all DTBs using the original pattern will not work with
 new kernels any more. At least I would expect such backward compatibility
 maintained for few kernel releases.

 The reason behind removing the cs-gpio or not providing backward
 compatibility was

 1. Since spi-core started using cs-gpios string from spi device node
 several months ago.
   The spi-s3c64xx.c driver is partially broken for more than 6 months.

 2. Supporting cs-gpio would add extra bit of code.

 I've corrected the dts files that were using cs-gpio under
 controller-data(child node)
 to use cs-gpio from spi device node (parent node).

 I will make another version if you insist.

 Yup, as near as I can tell this has been broken since (3146bee spi:
 s3c64xx: Added provision for dedicated cs pin).  That landed June 25th
 of 2013 into the SPI tree.

 ...so clearly nobody was really testing Samsung's SPI driver on ToT
 Linux.  1 year of unnoticed brokenness seems like enough time that we
 could do away with the old code.  If someone comes out of the woodwork
 and claims a dire need to support the old binding then it can be added
 then.

 In-tree users of this appear to be:

 arch/arm/boot/dts/exynos4210-smdkv310.dts:
  cs-gpio = gpc1 2 0;
 arch/arm/boot/dts/exynos4412-trats2.dts:
  cs-gpio = gpb 5 0;
 arch/arm/boot/dts/exynos5250-smdk5250.dts:
  cs-gpio = gpa2 5 0;

 ...and I guess nobody has bothered using the SPI flash on those boards
 for the last year?

I always try to warn people if they are breaking compatibility, but in
this case I agree it is okay. Presumably no one expects BSD or vxworks
support for this platform either?

For the binding change:

Acked-by: Rob Herring r...@kernel.org

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

Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP

[Rob Herring]

On Fri, Jun 6, 2014 at 5:36 AM, Mark Brown broo...@kernel.org wrote:
 From: Mark Brown broo...@linaro.org

 Since the OPP layer is a kernel library which has been converted to be
 directly selectable by its callers rather than user selectable and
 requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
 has become redundant and can be removed. Do so.

 Signed-off-by: Mark Brown broo...@linaro.org

Acked-by: Rob Herring r...@kernel.org

 ---
  Documentation/power/opp.txt| 3 ---
  arch/arm/mach-exynos/Kconfig   | 1 -
  arch/arm/mach-highbank/Kconfig | 1 -
  arch/arm/mach-imx/Kconfig  | 1 -
  arch/arm/mach-omap2/Kconfig| 1 -
  arch/arm/mach-shmobile/Kconfig | 2 --
  arch/arm/mach-vexpress/Kconfig | 1 -
  arch/arm/mach-zynq/Kconfig | 1 -
  drivers/devfreq/Kconfig| 1 -
  kernel/power/Kconfig   | 3 ---
  10 files changed, 15 deletions(-)

 diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
 index a9adad8..c6279c2 100644
 --- a/Documentation/power/opp.txt
 +++ b/Documentation/power/opp.txt
 @@ -51,9 +51,6 @@ Typical usage of the OPP library is as follows:
  SoC framework  - modifies on required cases certain OPPs  - OPP layer
 - queries to search/retrieve information   -

 -Architectures that provide a SoC framework for OPP should select ARCH_HAS_OPP
 -to make the OPP layer available.
 -
  OPP layer expects each domain to be represented by a unique device pointer. 
 SoC
  framework registers a set of initial OPPs per device with the OPP layer. This
  list is expected to be an optimally small number typically around 5 per 
 device.
 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index d58995c9..3f78c45 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -103,7 +103,6 @@ config SOC_EXYNOS5440
 default y
 depends on ARCH_EXYNOS5
 select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
 -   select ARCH_HAS_OPP
 select HAVE_ARM_ARCH_TIMER
 select AUTO_ZRELADDR
 select MIGHT_HAVE_PCI
 diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
 index 830b76e..bef970f 100644
 --- a/arch/arm/mach-highbank/Kconfig
 +++ b/arch/arm/mach-highbank/Kconfig
 @@ -3,7 +3,6 @@ config ARCH_HIGHBANK
 select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
 select ARCH_HAS_CPUFREQ
 select ARCH_HAS_HOLES_MEMORYMODEL
 -   select ARCH_HAS_OPP
 select ARCH_SUPPORTS_BIG_ENDIAN
 select ARM_AMBA
 select ARM_ERRATA_764369 if SMP
 diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
 index 4cce93d..95690e4 100644
 --- a/arch/arm/mach-imx/Kconfig
 +++ b/arch/arm/mach-imx/Kconfig
 @@ -1,7 +1,6 @@
  config ARCH_MXC
 bool Freescale i.MX family if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP
 select ARCH_REQUIRE_GPIOLIB
 select ARM_CPU_SUSPEND if PM
 select CLKSRC_MMIO
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index 0ba4826..524b027 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -12,7 +12,6 @@ config ARCH_OMAP3
 bool TI OMAP3
 depends on ARCH_MULTI_V7
 select ARCH_OMAP2PLUS
 -   select ARCH_HAS_OPP
 select ARM_CPU_SUSPEND if PM
 select OMAP_INTERCONNECT
 select PM_OPP if PM
 diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
 index dbd954e..b51d142 100644
 --- a/arch/arm/mach-shmobile/Kconfig
 +++ b/arch/arm/mach-shmobile/Kconfig
 @@ -86,7 +86,6 @@ config ARCH_R8A73A4
 select SH_CLK_CPG
 select RENESAS_IRQC
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP
 select SYS_SUPPORTS_SH_CMT
 select SYS_SUPPORTS_SH_TMU

 @@ -265,7 +264,6 @@ config MACH_KZM9G
 bool KZM-A9-GT board
 depends on ARCH_SH73A0
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP
 select ARCH_REQUIRE_GPIOLIB
 select REGULATOR_FIXED_VOLTAGE if REGULATOR
 select SND_SOC_AK4642 if SND_SIMPLE_CARD
 diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
 index 90249cf..71629fe 100644
 --- a/arch/arm/mach-vexpress/Kconfig
 +++ b/arch/arm/mach-vexpress/Kconfig
 @@ -66,7 +66,6 @@ config ARCH_VEXPRESS_DCSCB
  config ARCH_VEXPRESS_SPC
 bool Versatile Express Serial Power Controller (SPC)
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP
 select PM_OPP
 help
   The TC2 (A15x2 A7x3) versatile express core tile integrates a logic
 diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
 index 573e0db..bc485f2 100644
 --- a/arch/arm/mach-zynq/Kconfig
 +++ b/arch/arm/mach-zynq/Kconfig
 @@ -1,7 +1,6 @@
  config ARCH_ZYNQ
 bool Xilinx Zynq ARM Cortex A9 Platform if ARCH_MULTI_V7
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Rob Herring]

On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
thierry.red...@gmail.com wrote:
 From: Thierry Reding tred...@nvidia.com

 This commit introduces a generic device tree binding for IOMMU devices.
 Only a very minimal subset is described here, but it is enough to cover
 the requirements of both the Exynos System MMU and Tegra SMMU as
 discussed here:

 https://lkml.org/lkml/2014/4/27/346

 Signed-off-by: Thierry Reding tred...@nvidia.com
 ---
 Changes in v2:
 - add notes about dma-ranges property (drop note from commit message)
 - document priorities of iommus property vs. dma-ranges property
 - drop #iommu-cells in favour of #address-cells and #size-cells
 - remove multiple-master device example

  Documentation/devicetree/bindings/iommu/iommu.txt | 167 
 ++
  1 file changed, 167 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt

 diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt 
 b/Documentation/devicetree/bindings/iommu/iommu.txt
 new file mode 100644
 index ..6ce759afcc94
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
 @@ -0,0 +1,167 @@
 +This document describes the generic device tree binding for IOMMUs and their
 +master(s).
 +
 +
 +IOMMU device node:
 +==
 +
 +An IOMMU can provide the following services:
 +
 +* Remap address space to allow devices to access physical memory ranges that
 +  they otherwise wouldn't be capable of accessing.
 +
 +  Example: 32-bit DMA to 64-bit physical addresses
 +
 +* Implement scatter-gather at page level granularity so that the device does
 +  not have to.
 +
 +* Provide system protection against rogue DMA by forcing all accesses to go
 +  through the IOMMU and faulting when encountering accesses to unmapped
 +  address regions.
 +
 +* Provide address space isolation between multiple contexts.
 +
 +  Example: Virtualization
 +
 +Device nodes compatible with this binding represent hardware with some of the
 +above capabilities.
 +
 +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
 +typically have a fixed association to the master device, whereas multiple-
 +master IOMMU devices can translate accesses from more than one master.
 +
 +The device tree node of the IOMMU device's parent bus must contain a valid
 +dma-ranges property that describes how the physical address space of the
 +IOMMU maps to memory. An empty dma-ranges property means that there is a
 +1:1 mapping from IOMMU to memory.
 +
 +Required properties:
 +
 +- #address-cells: The number of cells in an IOMMU specifier needed to encode
 +  an address.
 +- #size-cells: The number of cells in an IOMMU specifier needed to represent
 +  the length of an address range.
 +
 +Typical values for the above include:
 +- #address-cells = 0, size-cells = 0: Single master IOMMU devices are not
 +  configurable and therefore no additional information needs to be encoded in
 +  the specifier. This may also apply to multiple master IOMMU devices that do
 +  not allow the association of masters to be configured.
 +- #address-cells = 1, size-cells = 0: Multiple master IOMMU devices may
 +  need to be configured in order to enable translation for a given master. In
 +  such cases the single address cell corresponds to the master device's ID.
 +- #address-cells = 2, size-cells = 2: Some IOMMU devices allow the DMA
 +  window for masters to be configured. The first cell of the address in this
 +  may contain the master device's ID for example, while the second cell could
 +  contain the start of the DMA window for the given device. The length of the
 +  DMA window is specified by two additional cells.
 +
 +
 +IOMMU master node:
 +==
 +
 +Devices that access memory through an IOMMU are called masters. A device can
 +have multiple master interfaces (to one or more IOMMU devices).
 +
 +Required properties:
 +
 +- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU
 +  master interfaces of the device. One entry in the list describes one master
 +  interface of the device.
 +
 +When an iommus property is specified in a device tree node, the IOMMU will
 +be used for address translation. If a dma-ranges property exists in the
 +device's parent node it will be ignored. An exception to this rule is if the
 +referenced IOMMU is disabled, in which case the dma-ranges property of the
 +parent shall take effect.

Just thinking out loud, could you have dma-ranges in the iommu node
for the case when the iommu is enabled rather than putting the DMA
window information into the iommus property?

This would probably mean that you need both #iommu-cells and #address-cells.

 +
 +Optional properties:
 +
 +- iommu-names: A list of names identifying each entry in the iommus
 +  property.

Do we really need a name here? I would not expect that you have
clearly documented names here from the datasheet like 

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Rob Herring]

On Fri, May 30, 2014 at 2:06 PM, Arnd Bergmann a...@arndb.de wrote:
 On Friday 30 May 2014 08:16:05 Rob Herring wrote:
 On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
 thierry.red...@gmail.com wrote:
  From: Thierry Reding tred...@nvidia.com
  +IOMMU master node:
  +==
  +
  +Devices that access memory through an IOMMU are called masters. A device 
  can
  +have multiple master interfaces (to one or more IOMMU devices).
  +
  +Required properties:
  +
  +- iommus: A list of phandle and IOMMU specifier pairs that describe the 
  IOMMU
  +  master interfaces of the device. One entry in the list describes one 
  master
  +  interface of the device.
  +
  +When an iommus property is specified in a device tree node, the IOMMU 
  will
  +be used for address translation. If a dma-ranges property exists in the
  +device's parent node it will be ignored. An exception to this rule is if 
  the
  +referenced IOMMU is disabled, in which case the dma-ranges property of 
  the
  +parent shall take effect.

 Just thinking out loud, could you have dma-ranges in the iommu node
 for the case when the iommu is enabled rather than putting the DMA
 window information into the iommus property?

 This would probably mean that you need both #iommu-cells and #address-cells.

 The reason for doing like this was that you may need a different window
 for each device, while there can only be one dma-ranges property in
 an iommu node.

My suggestion was that you also put the IDs in the dma-ranges as the
first cell much as ranges for PCI encodes other information in the
first cell. Then you can have an entry for each ID. The downside is
another special case like PCI.

The argument for using #address-cells and #size-cells seems to be to
align with how ranges work. If that's the route we want to go, then I
say we should not stop there and actually use dma-ranges as well.
Otherwise, I don't see the advantage over #iommu-cells.

  +
  +Optional properties:
  +
  +- iommu-names: A list of names identifying each entry in the iommus
  +  property.

 Do we really need a name here? I would not expect that you have
 clearly documented names here from the datasheet like you would for
 interrupts or clocks, so you'd just be making up names. Sorry, but I'm
 not a fan of names properties in general.

 Good point, this was really overdesign by modeling it after other
 subsystems that can have a use for names.

  +Multiple-master IOMMU:
  +--
  +
  +   iommu {
  +   /* the specifier represents the ID of the master */
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   };
  +
  +   master {
  +   /* device has master ID 42 in the IOMMU */
  +   iommus = /iommu 42;
  +   };

 Presumably the ID would be the streamID on ARM's SMMU. How would a
 master with 8 streamIDs be described? This is what Calxeda midway has
 for SATA and I would expect that to be somewhat common. Either you
 need some ID masking or you'll have lots of duplication when you have
 windows.

 I don't understand the problem. If you have stream IDs 0 through 7,
 you would have

 master@a {
 ...
 iommus = smmu 0;
 };

 master@b {
 ...
 iommus = smmu 1;
 };

 ...

 master@12 {
 ...
 iommus = smmu 7;
 };

 and you don't need a window at all. Why would you need a mask of
 some sort?

1 master with 7 IDs like this:

 master@a {
 ...
 iommus = smmu 0 smmu 1 smmu 2 smmu 3
smmu 4 smmu 5 smmu 6 smmu 7;
 };

If there was any sort of window, then it is almost certainly the same
window for each ID.

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

Re: [PATCH v6 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Rob Herring]

On Fri, May 30, 2014 at 3:33 PM, Nishanth Menon n...@ti.com wrote:
 On 05/30/2014 03:19 PM, Tomasz Figa wrote:
 On 30.05.2014 22:13, Nishanth Menon wrote:
 On 05/30/2014 03:02 PM, Tomasz Figa wrote:
 On 30.05.2014 21:50, Nishanth Menon wrote:
 On 05/30/2014 01:55 PM, Mark Rutland wrote:
 On Fri, May 30, 2014 at 07:05:43PM +0100, Thomas Abraham wrote:
 Hi Mark,

 On Fri, May 30, 2014 at 6:38 PM, Mark Rutland mark.rutl...@arm.com 
 wrote:
 Hi,

 Apologies for being somewhat late w.r.t. review on this.

 On Fri, May 30, 2014 at 10:01:17AM +0100, Thomas Abraham wrote:
 From: Thomas Abraham thomas...@samsung.com

 Add a new optional boost-frequency binding for specifying the 
 frequencies
 usable in boost mode.

 Cc: Rob Herring robh...@kernel.org
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Ian Campbell ijc+devicet...@hellion.org.uk
 Cc: Kumar Gala ga...@codeaurora.org
 Signed-off-by: Thomas Abraham thomas...@samsung.com
 Acked-by: Viresh Kumar viresh.ku...@linaro.org
 Acked-by: Nishanth Menon n...@ti.com
 Acked-by: Lukasz Majewski l.majew...@samsung.com
 ---
  .../devicetree/bindings/cpufreq/cpufreq-boost.txt  |   38 
 
  1 file changed, 38 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt

 diff --git 
 a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt 
 b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
 new file mode 100644
 index 000..63ed0fc
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
 @@ -0,0 +1,38 @@
 +* Device tree binding for CPU boost frequency (aka over-clocking)
 +
 +Certain CPU's can be operated in optional 'boost' mode (or sometimes 
 referred as

 Nit: CPUs (we're not greengrocers [1])

 +overclocking) in which the CPU can operate at frequencies which are 
 not
 +specified by the manufacturer as CPU's operating frequency.
 +
 +Optional Properties:
 +- boost-frequencies: list of frequencies in KHz to be used only in 
 boost mode.
 +  This list should be a subset of frequencies listed in 
 operating-points
 +  property. Refer to Documentation/devicetree/bindings/power/opp.txt 
 for
 +  details about operating-points property.

 What is 'boost-mode'?

 boost-mode activates additional one or more cpu clock speeds (which
 are not specified as operating frequency of the cpu by the
 manufacturer). The cpu is allowed to operate in these boost mode
 speeds when the boost mode is active. The boost mode speeds are
 usually undocumented. Some of the chip samples could be clocked in
 boost mode speeds and only such samples can be safely operated in
 boost mode.

 The mechanism of entry into and exit out of boost mode is outside the
 scope of this documentation.


 What are the limitations on boost frequencies? When is a CPU expected 
 to
 go to these frequencies and for now long? When should I as a dt author
 place elements in boost-frequencies?

 I will add these details in the next revision of this patch.

 Cheers.


 Why are these in both operating-points and boost-frequencies? It'll be
 really easy to accidentally forget to mark something as a
 boost-frequency this way. Why not have a boost-points instead?

 Does boost-points mean a set of clock speeds which are not listed as
 part of operating-points property? If yes, that also is a possible
 implementation (it was implemented in one of the earlier version of
 this series). Could you confirm that you want the boost mode speeds to
 be exclusive of the speeds listed in operating-points?

 If these boost mode operating points are not generally advisable for use
 as the other operating-points are, then they should IMO been in an
 entirely separate property exclusive of (but in the same format as) the
 operating-points property, e.g.

 operating points = A B, C D;
 boost-points = E F;

 you are asking boost frequencies to remain for ever tied down to OPP
 style description.

 What we are trying to describe? What are my SoC's overclocked
 frequencies? That description can be used even in a system that does
 not use OPP style table (say ACPI based OPP tables or whatever
 acronymned table).

 Tying it down to operating points just because we have it today as a
 convenient description, is limiting.

 Further, if we decide to educate boost-frequencies to also indicate
 how long is it safe? That does indeed belong to boost-frequency
 description and not OPP description. Or if we decide to change
 operating-points description[1] in the future has an impact on
 boost-points description, when it should not have.


 Otherwise, without boost-mode support we have to parse the boost mode
 table to figure out which points to avoid. Or if someone typos a value
 That is OS usage of h/w description - yeah - in anycase, if OS has no
 ability to deal with boost-frequencies, it should skip it for sure.

 in either table we might go into a boost mode when we didn't want to!

 There are other ways to screw up

Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver

[Rob Herring]

On Wed, May 14, 2014 at 8:18 AM, Arnd Bergmann a...@arndb.de wrote:
 On Wednesday 14 May 2014 18:44:46 Viresh Kumar wrote:
 On 14 May 2014 18:41, Heiko Stübner he...@sntech.de wrote:
  Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar:
  On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote:
   Could we please come up with a way to probe this from DT in the
   cpufreq-cpu0 driver itself, so we don't have to add a device in every
   platform using it?

  Its followed that way because DT Maintainers had strong objections
  to creating virtual device nodes and haven't allowed creation of nodes
  for cpufreq drivers.. For which there is no physical device, as CPU 
  already
  has a separate node..
 
  as we already have the enable-method property for enabling/disabling 
  cpus,
  would something like a scaling-method be feasible?

 Good idea to put it as a property into the CPU node.

We already have properties which indicate this driver can be used by a
platform: opp table and a clock for the cpu. If this information is
not sufficient to determine whether you can use this driver or not,
then you simply need to match against the platform. Perhaps the match
list should be a blacklist rather than a whitelist, so new platforms
work without a kernel change.

Alternatively, create a new OPP binding that addresses this and all
the other limitations in the current OPP binding.

 Lets see what DT maintainers have to say on this, I would rather go for a
 more straight forward name: scaling-driver  ..

 Both sound fine to me.

The fact that linux needs a way to create a platform device to enable
a certain driver is not a DT problem. I proposed a solution for how to
get this out of the platform code [1], but evidently we want people to
open code the exceptions and adding boilerplate helpers will just
encourage the exceptions.

Rob

[1] https://lkml.org/lkml/2013/10/30/30
--
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/4] irqchip: gic: Add support for per CPU bank offset specification in DT

[Rob Herring]

On Fri, Apr 18, 2014 at 9:43 AM, Tomasz Figa t.f...@samsung.com wrote:
 On most platforms GIC registers are banked, so each CPU can access its
 registers at the same address. However there is a small number of SoCs
 on which the banking is not implemented and each CPU has its GIC
 register set at different offset from GIC base address.

 Originally the driver used simple maths to calculate the address, i.e.
 multiplying constant percpu_offset by cpu_logical_map(cpu). However this
 assumed the namespace of cpu_logical_map() to be from 0 to num_cpus-1,
 but if CPU topology is specified via DT, this changes to full ID in
 the same format as MPIDR register and thus breaks the assumption.

 This patch adds support for per CPU GIC bank offset specification
 through device tree to separate SoC-internal core wiring from CPU
 multi-processor IDs.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 ---
  Documentation/devicetree/bindings/arm/cpus.txt |  7 ++
  Documentation/devicetree/bindings/arm/gic.txt  | 34 +-
  drivers/irqchip/irq-gic.c  | 94 
 ++
  3 files changed, 105 insertions(+), 30 deletions(-)

 diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
 b/Documentation/devicetree/bindings/arm/cpus.txt
 index 333f4ae..47654e6 100644
 --- a/Documentation/devicetree/bindings/arm/cpus.txt
 +++ b/Documentation/devicetree/bindings/arm/cpus.txt
 @@ -209,6 +209,13 @@ nodes to be present and contain the properties described 
 below.
 Value type: phandle
 Definition: Specifies the ACC[2] node associated with this 
 CPU.

 +   - gic-offset
 +   Usage: required for systems that have non-banked GIC
 +  implementation that requires each CPU to use different
 +  offset to access its set of GIC registers
 +   Value type: u32
 +   Definition: Specifies the offset of GIC registers specific to
 +   this CPU.

What if you have 1 distributor address and a per cpu address which is
allowed in the gicv2 spec IIRC.

I think I would rather see this stay contained within the gic node and
use reg property.

Rob


  Example 1 (dual-cluster big.LITTLE system 32-bit):

 diff --git a/Documentation/devicetree/bindings/arm/gic.txt 
 b/Documentation/devicetree/bindings/arm/gic.txt
 index 5573c08..2bd03406 100644
 --- a/Documentation/devicetree/bindings/arm/gic.txt
 +++ b/Documentation/devicetree/bindings/arm/gic.txt
 @@ -48,7 +48,7 @@ Optional

  - cpu-offset   : per-cpu offset within the distributor and cpu interface
regions, used when the GIC doesn't have banked registers. The offset is
 -  cpu-offset * cpu-nr.
 +  cpu-offset * cpu-nr. (DEPRECATED, see per-CPU 'gic-offset' property.)

  - arm,routable-irqs : Total number of gic irq inputs which are not directly
   connected from the peripherals, but are routed dynamically
 @@ -67,6 +67,38 @@ Example:
   0xfff10100 0x100;
 };

 +* Per-CPU register offset specification for non-banked GIC
 +
 +On most platforms GIC registers are banked, so each CPU can access its
 +registers at the same address. However there is a small number of SoCs
 +on which the banking is not implemented and each CPU has its GIC
 +register set at different offset from GIC base address. These offsets
 +need to be be provided from device tree, as described below.
 +
 +Optional properties in node of each CPU in the system:
 +
 + - gic-offset : A single u32 value that needs to be added to GIC base
 +   address to calculate address of GIC registers for that CPU.
 +
 +See [1] for more details about ARM CPU bindings.
 +
 +Example:
 +
 +   cpus {
 +   /* ... */
 +
 +   cpu@a00 {
 +   /* ... */
 +   gic-offset = 0x;
 +   };
 +
 +   cpu@a01 {
 +   /* ... */
 +   gic-offset = 0x8000;
 +   };
 +   };
 +
 +[1] Documentation/devicetree/bindings/arm/cpus.txt

  * GIC virtualization extensions (VGIC)

 diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
 index 4300b66..ad6f4fe 100644
 --- a/drivers/irqchip/irq-gic.c
 +++ b/drivers/irqchip/irq-gic.c
 @@ -924,6 +924,69 @@ const struct irq_domain_ops 
 gic_default_routable_irq_domain_ops = {
  const struct irq_domain_ops *gic_routable_irq_domain_ops =
 gic_default_routable_irq_domain_ops;

 +static int gic_setup_bases(struct gic_chip_data *gic, void __iomem 
 *dist_base,
 +  void __iomem *cpu_base, u32 percpu_offset)
 +{
 +   bool use_cpu_nodes = true;
 +   u32 offset;
 +   unsigned int cpu;
 +
 +   for_each_possible_cpu(cpu) {
 +   struct device_node *cpu_node = of_get_cpu_node(cpu, NULL);
 +
 +   if (!cpu_node
 +   || of_property_read_u32(cpu_node, gic-offset, offset)) 
 

Re: [PATCH 3/4] irqchip: gic: Add support for per CPU bank offset specification in DT

[Rob Herring]

On Thu, May 8, 2014 at 12:09 PM, Tomasz Figa t.f...@samsung.com wrote:
 On 08.05.2014 19:04, Rob Herring wrote:
 On Fri, Apr 18, 2014 at 9:43 AM, Tomasz Figa t.f...@samsung.com wrote:
 On most platforms GIC registers are banked, so each CPU can access its
 registers at the same address. However there is a small number of SoCs
 on which the banking is not implemented and each CPU has its GIC
 register set at different offset from GIC base address.

 Originally the driver used simple maths to calculate the address, i.e.
 multiplying constant percpu_offset by cpu_logical_map(cpu). However this
 assumed the namespace of cpu_logical_map() to be from 0 to num_cpus-1,
 but if CPU topology is specified via DT, this changes to full ID in
 the same format as MPIDR register and thus breaks the assumption.

 This patch adds support for per CPU GIC bank offset specification
 through device tree to separate SoC-internal core wiring from CPU
 multi-processor IDs.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 ---
  Documentation/devicetree/bindings/arm/cpus.txt |  7 ++
  Documentation/devicetree/bindings/arm/gic.txt  | 34 +-
  drivers/irqchip/irq-gic.c  | 94 
 ++
  3 files changed, 105 insertions(+), 30 deletions(-)

 diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
 b/Documentation/devicetree/bindings/arm/cpus.txt
 index 333f4ae..47654e6 100644
 --- a/Documentation/devicetree/bindings/arm/cpus.txt
 +++ b/Documentation/devicetree/bindings/arm/cpus.txt
 @@ -209,6 +209,13 @@ nodes to be present and contain the properties 
 described below.
 Value type: phandle
 Definition: Specifies the ACC[2] node associated with this 
 CPU.

 +   - gic-offset
 +   Usage: required for systems that have non-banked GIC
 +  implementation that requires each CPU to use 
 different
 +  offset to access its set of GIC registers
 +   Value type: u32
 +   Definition: Specifies the offset of GIC registers specific 
 to
 +   this CPU.

 What if you have 1 distributor address and a per cpu address which is
 allowed in the gicv2 spec IIRC.

 Hmm, I need to take a look at GIC v2 spec... but I think my proposed
 binding would still cover this, as the implementation (if modified to
 support this) would simply ignore the offset for distributor in this case.

How does the implementation know whether to ignore the offset for the
distributor or not?

 I think I would rather see this stay contained within the gic node and
 use reg property.

 How do we match reg entries with CPUs then? The first idea that comes to
 my mind would be adding arm,cpu-map property that would list MPIDR
 values of CPUs in the same order as register banks are listed in reg
 property but I'm not sure this is a good idea.

How do you do it currently?

The issue with putting properties in the cpu node is it does not
scale. What if you had 10 per cpu properties on 10 different blocks.

Using the MPIDR directly is a bit specific. I would perhaps just do
something like this:

gic-cpu-map = CPU0 CPU1;

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

Re: [PATCH 0/4] Introducing Exynos ChipId driver

[Rob Herring]

On Sat, May 3, 2014 at 10:02 AM, Arnd Bergmann a...@arndb.de wrote:
 On Saturday 03 May 2014 15:11:36 Pankaj Dubey wrote:
 This patch series attempts to get rid of soc_is_exynos macros
 and eventually with the help of this series we can probably get
 rid of CONFIG_SOC_EXYNOS in near future.
 Each Exynos SoC has ChipID block which can give information about
 SoC's product Id and revision number. Currently we have single
 DT binding information for this as samsung,exynos4210-chipid.
 But Exynos4 and Exynos5 SoC series have one small difference in
 chip Id, with resepect to product id bit-masks. So it means we
 should have separate compatible string for these different series
 of SoCs. So I have created new binding information for handling
 this difference. Also currently I can think of putting this driver
 code under drivers/misc/ but suggestions are welcome.
 Also current form of driver is missing platfrom driver and needs
 init function to be called from machine file (either exynos.c or
 platsmp.c). I hope lot of suggestions and comments to improve this
 further.

 This patch series is based on Kukjin Kim's for-next (3.14_rc1 tag)
 and prepared on top of following patch series and it's dependent
 patch series.

 I think putting it into drivers/soc would be most appropriate.
 We already have a few drivers lined up that we want in there,
 although the directory currently doesn't exist.

 However, I would ask that you use the infrastructure provided by
 drivers/base/soc.c when you add this driver, to also make the
 information available to user space using a standard API.

Agreed.

 Ideally this should be done by slightly restructuring the DT
 source to make all on-chip devices appear below the soc node.
 We'd have to think a bit about how to best do this while
 preserving compatibility with existing dts files.

I don't agree. How is a block with chip ID info the parent of all the
other devices?

In doing some work to move default of_platform_populate out of
platforms, I noticed that most platforms using the soc device are
making it the parent of platform devices. I think this is either wrong
or all platforms should have a default soc device. It makes little
sense for some platforms to have a devices under a soc sysfs directory
while others do not. Or the location changes when a platform latter
adds the soc device.

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

Re: [PATCH Resend] ARM: EXYNOS: Map SYSRAM address through DT

[Rob Herring]

On Wed, Apr 16, 2014 at 6:50 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Instead of hardcoding the SYSRAM details for each SoC,
 pass this information through device tree (DT) and make
 the code SoC agnostic.

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
 Rebased on latest linux-next.
 ---
  .../devicetree/bindings/arm/samsung-boards.txt |   11 +++
  arch/arm/boot/dts/exynos4210-universal_c210.dts|9 ++
  arch/arm/boot/dts/exynos4210.dtsi  |   10 ++
  arch/arm/boot/dts/exynos4x12.dtsi  |   10 ++
  arch/arm/boot/dts/exynos5.dtsi |5 +
  arch/arm/boot/dts/exynos5250.dtsi  |5 +
  arch/arm/boot/dts/exynos5420.dtsi  |5 +
  arch/arm/mach-exynos/exynos.c  |  104 
 
  arch/arm/mach-exynos/include/mach/map.h|7 --
  9 files changed, 95 insertions(+), 71 deletions(-)

 diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt 
 b/Documentation/devicetree/bindings/arm/samsung-boards.txt
 index 2168ed31e1b0..f79710eb7e79 100644
 --- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
 +++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
 @@ -7,6 +7,17 @@ Required root node properties:
  (a) samsung,smdkv310 - for Samsung's SMDKV310 eval board.
  (b) samsung,exynos4210  - for boards based on Exynos4210 SoC.

 +- sysram node, specifying the type (secure or non-secure) of SYSRAM
 +   - compatible: following types are supported
 +   samsung,exynos4210-sysram : Secure SYSRAM
 +   samsung,exynos4210-sysram-ns : Non-secure SYSRAM

Base this on mmio-sram binding please.

 +   - reg: address of SYSRAM bank
 +
 +   sysram@0202 {
 +   compatible = samsung,exynos4210-sysram;
 +   reg = 0x0202 0x1000;
 +   };
 +
  Optional:
  - firmware node, specifying presence and type of secure firmware:
  - compatible: only samsung,secure-firmware is currently supported
 diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
 b/arch/arm/boot/dts/exynos4210-universal_c210.dts
 index 63e34b24b04f..cf4158728108 100644
 --- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
 +++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
 @@ -28,6 +28,15 @@
 bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw 
 rootwait earlyprintk panic=5 maxcpus=1;
 };

 +   sysram@0202 {
 +   status = disabled;
 +   };
 +
 +   sysram@02025000 {
 +   compatible = samsung,exynos4210-sysram;
 +   reg = 0x02025000 0x1000;
 +   };
 +
 mct@1005 {
 compatible = none;
 };
 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index cacf6140dd2f..a3f4bba099e6 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -31,6 +31,16 @@
 pinctrl2 = pinctrl_2;
 };

 +   sysram@0202 {
 +   compatible = samsung,exynos4210-sysram;
 +   reg = 0x0202 0x1000;
 +   };
 +
 +   sysram-ns@0203F000 {
 +   compatible = samsung,exynos4210-sysram-ns;
 +   reg = 0x0203F000 0x1000;

hex should be lower case.


[...]

 @@ -268,6 +218,44 @@ static int __init exynos_fdt_map_chipid(unsigned long 
 node, const char *uname,
 return 1;
  }

 +struct __sysram_desc {
 +   char name[32];
 +   unsigned long addr;
 +};
 +
 +static struct __sysram_desc sysram_desc[] __initdata = {
 +   {
 +   .name = samsung,exynos4210-sysram,
 +   .addr = (unsigned long)S5P_VA_SYSRAM,
 +   }, {
 +   .name = samsung,exynos4210-sysram-ns,
 +   .addr = (unsigned long)S5P_VA_SYSRAM_NS,
 +   },
 +};
 +
 +static int __init exynos_fdt_map_sysram(unsigned long node, const char 
 *uname,
 +   int depth, void *data)
 +{
 +   struct map_desc iodesc;
 +   __be32 *reg;
 +   unsigned long len;
 +   int i;
 +
 +   for (i = 0; i  ARRAY_SIZE(sysram_desc); i++) {
 +   if (of_flat_dt_is_compatible(node, sysram_desc[i].name)) {
 +   reg = of_get_flat_dt_prop(node, reg, len);
 +   if (!reg || len != (sizeof(unsigned long) * 2))
 +   return -ENODEV;
 +   iodesc.virtual = sysram_desc[i].addr;
 +   iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
 +   iodesc.length = be32_to_cpu(reg[1]);
 +   iodesc.type = MT_DEVICE;
 +   iotable_init(iodesc, 1);

I don't think this needs to be a static mapping at all. Fix your SMP
code. Move the code setting the boot address in prepare_cpus to
boot_secondary.

Also, the pen code is all unnecessary if you can properly reset 

Re: [PATCH 4/5] exynos4-is: Remove requirement for simple-bus compatible

[Rob Herring]

On Tue, Apr 15, 2014 at 12:34 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
 This patch makes the driver instantiating its child devices itself,
 rather than relying on an OS to instantiate devices as children
 of simple-bus. This removes an incorrect usage of simple-bus
 compatible.

Good, but why can't you use of_platform_populate with the root being
the samsung,fimc node? The code to instantiate the devices belongs
in the core OF code.

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

Re: [PATCH 2/2] Documentation: devicetree: Add boost-opp binding to list boost mode OPPs

[Rob Herring]

On Tue, Feb 4, 2014 at 3:41 AM, Thomas Abraham ta.oma...@gmail.com wrote:
 From: Thomas Abraham thomas...@samsung.com

 Certain CPUs or devices can support optional boost operating modes. Add a new
 binding to list OPPs to be additionally made available in boost operating 
 modes.

 Cc: Nishanth Menon n...@ti.com
 Cc: Lukasz Majewski l.majew...@samsung.com
 Cc: Rob Herring robh...@kernel.org
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Ian Campbell ijc+devicet...@hellion.org.uk
 Cc: Kumar Gala ga...@codeaurora.org
 Signed-off-by: Thomas Abraham thomas...@samsung.com
 ---
  Documentation/devicetree/bindings/power/opp.txt |9 +
  1 file changed, 9 insertions(+)

 diff --git a/Documentation/devicetree/bindings/power/opp.txt 
 b/Documentation/devicetree/bindings/power/opp.txt
 index 74499e5..4df5cca 100644
 --- a/Documentation/devicetree/bindings/power/opp.txt
 +++ b/Documentation/devicetree/bindings/power/opp.txt
 @@ -10,6 +10,10 @@ Properties:
 freq: clock frequency in kHz
 vol: voltage in microvolt

 +Optional Properties:
 +- boost-opp: Similar to operating-points property but usable only in
 +  optional boost operating modes.
 +
  Examples:

  cpu@0 {
 @@ -22,4 +26,9 @@ cpu@0 {
 396000  95
 198000  85
 ;
 +   boost-opp = 
 +   /* kHz uV */
 +   150 135
 +   140 1285000
 +   ;

This looks like an example of needing to add more properties to the
OPP table. There are ongoing discussions on how to extend OPP table
and map to C states. This should be part of that discussion.

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

Re: [PATCH v2 3/7] devicetree: bindings: add cpu clock configuration data binding for Exynos4/5

[Rob Herring]

On Sat, Jan 18, 2014 at 6:10 AM, Thomas Abraham ta.oma...@gmail.com wrote:
 From: Thomas Abraham thomas...@samsung.com

 The clk ops of the new Samsung cpu clock provider type requires configuration
 data that will be programmed in the multiple clock blocks encapsulated within
 the cpu clock provider type. This configuration data is held in the clock
 controller node. Update clock binding documentation about this configuration
 data format for Samsung Exynos4 and Exynos5 platforms.

 Cc: Rob Herring robh...@kernel.org

Please copy all maintainers.

 Cc: Tomasz Figa t.f...@samsung.com
 Cc: devicet...@vger.kernel.org
 Signed-off-by: Thomas Abraham thomas...@samsung.com
 ---
  .../devicetree/bindings/clock/exynos4-clock.txt|   30 
 
  .../devicetree/bindings/clock/exynos5250-clock.txt |   21 ++
  2 files changed, 51 insertions(+), 0 deletions(-)

 diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt 
 b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
 index a2ac2d9..c28aabd 100644
 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
 +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
 @@ -15,6 +15,29 @@ Required Properties:

  - #clock-cells: should be 1.

 +- arm-frequency-table: defines the list of arm clock speeds supported and

Seems like a Samsung specific property and nothing to do with ARM, so
it should be named accordingly.

 +  the associated configuration values required to setup the clock controller
 +  for generating those speeds. The format of each entry included in the
 +  arm-frequency-table should be as defined below (#cells per entry = 13)
 +
 +  - for Exynos4210 and Exynos4212 based platforms:
 +  cell #1: arm clock frequency
 +  cell #2: expected arm clock parent frequency
 +  cell #3 ~ cell 12#: value of clock divider in the following order
 +  core_ratio, corem0_ratio, corem1_ratio, periph_ratio,
 +  atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio,
 +  copy_ratio, hpm_ratio.
 +  cell #13: reserved (should be zero).
 +
 +  - for Exynos4412 based platforms:
 +  cell #1: arm clock frequency
 +  cell #2: expected arm clock parent frequency
 +  cell #3 ~ cell #13: value of clock divider in the following order
 +  core_ratio, corem0_ratio, corem1_ratio, periph_ratio,
 +  atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio,
 +  copy_ratio, hpm_ratio, cores_ratio

You don't need voltages? Are the h/w limitations really ratios or each
clock has a max frequency that must be maintained? I would expect the
latter and think it would be better to specify maximum frequencies of
each clock. Then you can calculate the dividers to keep frequencies in
range.

How will this scale to multi-cluster chips with different frequency ranges?

Rob

 +
 +
  The following is the list of clocks generated by the controller. Each clock 
 is
  assigned an identifier and client nodes use this identifier to specify the
  clock which they consume. Some of the clocks are available only on a 
 particular
 @@ -275,6 +298,13 @@ Example 1: An example of a clock controller node is 
 listed below.
 compatible = samsung,exynos4210-clock;
 reg = 0x1003 0x2;
 #clock-cells = 1;
 +
 +   arm-frequency-table = 120 120 0 3 7 3 4 1 7 0 5 0,
 + 100 100 0 3 7 3 4 1 7 0 4 0,
 +  80  80 0 3 7 3 3 1 7 0 3 0,
 +  50  50 0 3 7 3 3 1 7 0 3 0,
 +  40  40 0 3 7 3 3 1 7 0 3 0,
 +  20  20 0 1 3 1 1 1 0 0 3 0;
 };

  Example 2: UART controller node that consumes the clock generated by the 
 clock
 diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
 b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
 index 72ce617..99eae9c 100644
 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
 +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
 @@ -13,6 +13,20 @@ Required Properties:

  - #clock-cells: should be 1.

 +- arm-frequency-table: defines the list of arm clock speeds supported and
 +  the associated configuration values required to setup the clock controller
 +  for generating those speeds. The format of each entry included in the
 +  arm-frequency-table should be as defined below (#cells per entry = 13)
 +
 +  cell #1: arm clock frequency
 +  cell #2: expected arm clock parent frequency
 +  cell #3 ~ cell #12: value of clock divider in the following order
 +  arm_ratio, cpud_ratio, acp_ratio, periph_ratio,
 +  atb_ratio, pclk_dbg_ratio, apll_ratio, arm2_ratio,
 +  copy_ratio, hpm_ratio
 +  cell #13: reserved (should be zero)
 +
 +
  The following

Re: [PATCH] hwmon: ntc_thermistor: Fix typo (pullup-uV - pullup-uv)

[Rob Herring]

On Tue, Oct 22, 2013 at 8:44 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patch fix typo of property name from 'pullup-uV' to 'pullup-uv'.
 The ntc_thermistor.c use 'pullup-uv' when parsing dt data.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Applied for 3.13.

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

Re: ARM: dts: add board dts file for EXYNOS4412 based TINY4412 board

[Rob Herring]

On 11/12/2013 09:02 AM, Alex Ling wrote:
 Add a minimal board dts file for EXYNOS4412 based FriendlyARM's
 TINY4412 board. This patch including adds the node to support
 peripherals like UART, SD card on SDMMC2 port, and this patch
 adds GPIO connected LEDS and configure its properties like
 following:
 LED1: use 'heartbeat' trigger, blinking while the board is running.
 LED4: use 'mmc0' trigger, on when mmc0 is accessing.
 LED2 and LED3 can be controlled from userspace.

Please send patches with [PATCH] prefix.

 Signed-off-by: Alex Ling kasiml...@gmail.com
 ---
  arch/arm/boot/dts/Makefile|1 +
  arch/arm/boot/dts/exynos4412-tiny4412.dts |   89 
 +
  2 files changed, 90 insertions(+)
  create mode 100644 arch/arm/boot/dts/exynos4412-tiny4412.dts
 
 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 802720e..91671a2 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -59,6 +59,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
   exynos4412-odroidx.dtb \
   exynos4412-origen.dtb \
   exynos4412-smdk4412.dtb \
 + exynos4412-tiny4412.dtb \
   exynos4412-trats2.dtb \
   exynos5250-arndale.dtb \
   exynos5250-smdk5250.dtb \
 diff --git a/arch/arm/boot/dts/exynos4412-tiny4412.dts 
 b/arch/arm/boot/dts/exynos4412-tiny4412.dts
 new file mode 100644
 index 000..78ace14
 --- /dev/null
 +++ b/arch/arm/boot/dts/exynos4412-tiny4412.dts
 @@ -0,0 +1,89 @@
 +/*
 + * FriendlyARM's Exynos4412 based TINY4412 board device tree source
 + *
 + * Copyright (c) 2013 Alex Ling kasiml...@gmail.com
 + *
 + * Device tree source file for FriendlyARM's TINY4412 board which is based on
 + * Samsung's Exynos4412 SoC.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 +*/
 +
 +/dts-v1/;
 +#include exynos4412.dtsi
 +
 +/ {
 + model = FriendlyARM TINY4412 board based on Exynos4412;
 + compatible = friendlyarm,tiny4412, samsung,exynos4412;

The compatible string needs to be documented.

Rob

 +
 + memory {
 + reg = 0x4000 0x4000;
 + };
 +
 + leds {
 + compatible = gpio-leds;
 + led1 {
 + label = led1:heart;
 + gpios = gpm4 0 1;
 + default-state = off;
 + linux,default-trigger = heartbeat;
 + };
 + led2 {
 + label = led2;
 + gpios = gpm4 1 1;
 + default-state = off;
 + };
 + led3 {
 + label = led3;
 + gpios = gpm4 2 1;
 + default-state = off;
 + };
 + led4 {
 + label = led4:mmc0;
 + gpios = gpm4 3 1;
 + default-state = off;
 + linux,default-trigger = mmc0;
 + };
 + };
 +
 + rtc@1007 {
 + status = okay;
 + };
 +
 + sdhci@1253 {
 + bus-width = 4;
 + pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
 + pinctrl-names = default;
 + status = okay;
 + };
 +
 + serial@1380 {
 + status = okay;
 + };
 +
 + serial@1381 {
 + status = okay;
 + };
 +
 + serial@1382 {
 + status = okay;
 + };
 +
 + serial@1383 {
 + status = okay;
 + };
 +
 + fixed-rate-clocks {
 + xxti {
 + compatible = samsung,clock-xxti;
 + clock-frequency = 0;
 + };
 +
 + xusbxti {
 + compatible = samsung,clock-xusbxti;
 + clock-frequency = 2400;
 + };
 + };
 +};
 

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

Re: [PATCH v2 1/4] ARM: EXYNOS: Add support for EXYNOS5410 SoC

[Rob Herring]

On 10/14/2013 10:08 AM, Vyacheslav Tyrtov wrote:
 From: Tarek Dakhran t.dakh...@samsung.com
 
 EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
 Add initial support for this SoC.

I think this entire patch is mostly unnecessary and this information
should all be coming from DT. I'll leave it to arm-soc maintainers
whether they want to accept this addition rather than see some clean-up
here.

samsung,exynos5410 does need to be documented though.

Rob

 Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
 Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig | 12 
  arch/arm/mach-exynos/common.c| 18 ++
  arch/arm/mach-exynos/include/mach/map.h  |  1 +
  arch/arm/mach-exynos/mach-exynos5-dt.c   |  1 +
  arch/arm/plat-samsung/include/plat/cpu.h |  8 
  5 files changed, 40 insertions(+)
 
 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index 56fe819..9ea1799 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -84,6 +84,18 @@ config SOC_EXYNOS5250
   help
 Enable EXYNOS5250 SoC support
  
 +config SOC_EXYNOS5410
 + bool SAMSUNG EXYNOS5410
 + default y
 + depends on ARCH_EXYNOS5
 + select MCPM
 + select ARM_CCI
 + select PM_GENERIC_DOMAINS if PM
 + select S5P_PM if PM
 + select S5P_SLEEP if PM
 + help
 +   Enable EXYNOS5410 SoC support
 +
  config SOC_EXYNOS5420
   bool SAMSUNG EXYNOS5420
   default y
 diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
 index ba95e5d..187c0a4 100644
 --- a/arch/arm/mach-exynos/common.c
 +++ b/arch/arm/mach-exynos/common.c
 @@ -53,6 +53,7 @@ static const char name_exynos4210[] = EXYNOS4210;
  static const char name_exynos4212[] = EXYNOS4212;
  static const char name_exynos4412[] = EXYNOS4412;
  static const char name_exynos5250[] = EXYNOS5250;
 +static const char name_exynos5410[] = EXYNOS5410;
  static const char name_exynos5420[] = EXYNOS5420;
  static const char name_exynos5440[] = EXYNOS5440;
  
 @@ -86,6 +87,12 @@ static struct cpu_table cpu_ids[] __initdata = {
   .init   = exynos_init,
   .name   = name_exynos5250,
   }, {
 + .idcode = EXYNOS5410_SOC_ID,
 + .idmask = EXYNOS5_SOC_MASK,
 + .map_io = exynos5_map_io,
 + .init   = exynos_init,
 + .name   = name_exynos5410,
 + }, {
   .idcode = EXYNOS5420_SOC_ID,
   .idmask = EXYNOS5_SOC_MASK,
   .map_io = exynos5_map_io,
 @@ -216,6 +223,15 @@ static struct map_desc exynos4x12_iodesc[] __initdata = {
   },
  };
  
 +static struct map_desc exynos5410_iodesc[] __initdata = {
 + {
 + .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
 + .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
 + .length = SZ_4K,
 + .type   = MT_DEVICE,
 + },
 +};
 +
  static struct map_desc exynos5250_iodesc[] __initdata = {
   {
   .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
 @@ -365,6 +381,8 @@ static void __init exynos5_map_io(void)
  
   if (soc_is_exynos5250())
   iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
 + if (soc_is_exynos5410())
 + iotable_init(exynos5410_iodesc, ARRAY_SIZE(exynos5410_iodesc));
  }
  
  void __init exynos_init_time(void)
 diff --git a/arch/arm/mach-exynos/include/mach/map.h 
 b/arch/arm/mach-exynos/include/mach/map.h
 index 7b046b5..894f431 100644
 --- a/arch/arm/mach-exynos/include/mach/map.h
 +++ b/arch/arm/mach-exynos/include/mach/map.h
 @@ -29,6 +29,7 @@
  #define EXYNOS4210_PA_SYSRAM_NS  0x0203F000
  #define EXYNOS4x12_PA_SYSRAM_NS  0x0204F000
  #define EXYNOS5250_PA_SYSRAM_NS  0x0204F000
 +#define EXYNOS5410_PA_SYSRAM_NS  0x02073000
  
  #define EXYNOS_PA_CHIPID 0x1000
  
 diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c 
 b/arch/arm/mach-exynos/mach-exynos5-dt.c
 index f874b77..9515186 100644
 --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
 +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
 @@ -52,6 +52,7 @@ static void __init exynos5_dt_machine_init(void)
  
  static char const *exynos5_dt_compat[] __initdata = {
   samsung,exynos5250,
 + samsung,exynos5410,
   samsung,exynos5420,
   samsung,exynos5440,
   NULL
 diff --git a/arch/arm/plat-samsung/include/plat/cpu.h 
 b/arch/arm/plat-samsung/include/plat/cpu.h
 index 4fb1f03..aad7c40 100644
 --- a/arch/arm/plat-samsung/include/plat/cpu.h
 +++ b/arch/arm/plat-samsung/include/plat/cpu.h
 @@ -46,6 +46,7 @@ extern unsigned long samsung_cpu_id;
  #define EXYNOS4_CPU_MASK 0xFFFE
  
  #define EXYNOS5250_SOC_ID0x4352
 +#define EXYNOS5410_SOC_ID0xE5410023
  #define EXYNOS5420_SOC_ID

Re: [PATCH] ARM: dts: Update arch timer node with clock frequency

[Rob Herring]

On Tue, Oct 8, 2013 at 5:15 PM, Olof Johansson o...@lixom.net wrote:
 [Adding Tony, who reported a mainline booting issue, and Sean who
 helped me track this down]

 On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland mark.rutl...@arm.com wrote:
 On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote:
 Hi Yuvaraj,

 On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote:
  Without the clock-frequency property in arch timer node, could able
  to see the below crash dump.
 [snip]
  diff --git a/arch/arm/boot/dts/exynos5250.dtsi
  b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644
  --- a/arch/arm/boot/dts/exynos5250.dtsi
  +++ b/arch/arm/boot/dts/exynos5250.dtsi
  @@ -96,6 +96,7 @@
   1 14 0xf08,
   1 11 0xf08,
   1 10 0xf08;
  +   clock-frequency = 2400;

 Shouldn't it rather come from some clock provided by some clock controller
 instead?

 The frequency would be then retrieved using clk_get_rate() on a clock
 received by clk_get(), specified in device tree using generic clock
 bindings.

 If the bootloader has initialised the generic timer correctly, the
 CNTFRQ register should contain the clock frequency, independent of any
 external clock.

 So, we just sat here to bisect a problem on the Samsung Chromebook
 where we hit exactly this problem. The read-only firmware on the
 device does not set CNTFRQ at boot, so this fails.

 Apparantly the u-boot that comes with Arndale sets it, so I haven't
 seen this error on that platform.

 Having the bootloader set CNTFRQ is by far the preferable solution, it
 is architected for this purpose.

 Unfortunately there is now real hardware out there that needs this due
 to firmware bugs / missing features, so there's little other choice.
 :(

 I'll pick this patch up in the fixes branch for 3.12, unless someone
 complains loudly.

Perhaps the subject should say something about this only applying to exynos.

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

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

[Rob Herring]

On Fri, Jul 26, 2013 at 6:28 AM, Cho KyongHo pullip@samsung.com wrote:
 Signed-off-by: Cho KyongHo pullip@samsung.com
 ---
  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
  arch/arm/boot/dts/exynos4.dtsi |  122 
  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
  arch/arm/boot/dts/exynos4x12.dtsi  |   76 +
  arch/arm/boot/dts/exynos5250.dtsi  |  291 
 
  5 files changed, 617 insertions(+), 0 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt

 diff --git 
 a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
 b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
 new file mode 100644
 index 000..92f0a33
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
 @@ -0,0 +1,103 @@
 +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
 +
 +Samsung's Exynos architecture contains System MMU that enables scattered
 +physical memory chunks visible as a contiguous region to DMA-capable 
 peripheral
 +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
 +
 +System MMU is a sort of IOMMU and support identical translation table format 
 to
 +ARMv7 translation tables with minimum set of page properties including access
 +permissions, shareability and security protection. In addition, System MMU 
 has
 +another capabilities like L2 TLB or block-fetch buffers to minimize 
 translation
 +latency.
 +
 +A System MMU is dedicated to a single master peripheral device.  Thus, it is
 +important to specify the correct System MMU in the device node of its master
 +device. Whereas a System MMU is dedicated to a master device, the master 
 device
 +may have more than one System MMU.
 +
 +Required properties:
 +- compatible: Should be samsung,exynos4210-sysmmu
 +- reg: A tuple of base address and size of System MMU registers.
 +- interrupt-parent: The phandle of the interrupt controller of System MMU
 +- interrupts: A tuple of numbers that indicates the interrupt source.
 +- clock-names: Should be sysmmu if the System MMU is needed to gate its 
 clock.
 +   Please refer to the following documents:
 +  Documentation/devicetree/bindings/clock/clock-bindings.txt
 +  Documentation/devicetree/bindings/clock/exynos4-clock.txt
 +  Documentation/devicetree/bindings/clock/exynos5250-clock.txt
 +  Optional master if the clock to the System MMU is gated by
 +  another gate clock other than sysmmu. The System MMU driver
 +  sets master the parent of sysmmu.
 +  Exynos4 SoCs, there needs no master clocks.
 +  Exynos5 SoCs, some System MMUs must have master clocks.
 +- clocks: Required if the System MMU is needed to gate its clock.
 + Please refer to the documents listed above.
 +- samsung,power-domain: Required if the System MMU is needed to gate its 
 power.
 + Please refer to the following document:
 + Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 +
 +Required properties for the master peripheral devices:
 +- iommu: phandles to the System MMUs of the device

You have not addressed my comments from the last version. We do not
need 2 (or more) different ways to describe the connection between
masters and iommu's. Use mmu-masters property here to describe the
connection.

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

Re: [PATCH v8 1/7] irqchip: vic: Parse interrupt and resume masks from device tree

[Rob Herring]

On Fri, Aug 23, 2013 at 6:04 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 On Friday 23 of August 2013 16:11:18 Stephen Warren wrote:
 On 08/22/2013 05:22 PM, Tomasz Figa wrote:
  This patch extends vic_of_init to parse valid interrupt sources
  and resume sources masks from device tree.
 
  If mask values are not specified in device tree, all sources
  are assumed to be valid, as before this patch.

 Can you explain further why the VIC needs this information up-front?
 Presumably it can accumulate it as devices request interrupts.

 It does not need this information just for operation, but this makes the
 hardware description more detailed and allows better sanity checking of
 interrupts being requested.

 To clarify, this is a mask of valid interrupt sources of the VIC, where
 set bit indicates that given signal is wired and clear bit that it is not.

I agree with Stephen here. The valid interrupts are the ones in the
DT. The reserved ones are the ones not present. If it is not needed
for the operation of the VIC, then remove it. The argument of sanity
checking could apply to all interrupt controllers.

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

Re: [PATCH v8 1/7] irqchip: vic: Parse interrupt and resume masks from device tree

[Rob Herring]

On 08/24/2013 10:31 AM, Tomasz Figa wrote:
 On Saturday 24 of August 2013 10:25:26 Rob Herring wrote:
 On Fri, Aug 23, 2013 at 6:04 PM, Tomasz Figa tomasz.f...@gmail.com 
 wrote:
 On Friday 23 of August 2013 16:11:18 Stephen Warren wrote:
 On 08/22/2013 05:22 PM, Tomasz Figa wrote:
 This patch extends vic_of_init to parse valid interrupt sources
 and resume sources masks from device tree.

 If mask values are not specified in device tree, all sources
 are assumed to be valid, as before this patch.

 Can you explain further why the VIC needs this information up-front?
 Presumably it can accumulate it as devices request interrupts.

 It does not need this information just for operation, but this makes
 the hardware description more detailed and allows better sanity
 checking of interrupts being requested.

 To clarify, this is a mask of valid interrupt sources of the VIC,
 where
 set bit indicates that given signal is wired and clear bit that it is
 not.
 I agree with Stephen here. The valid interrupts are the ones in the
 DT. The reserved ones are the ones not present. If it is not needed
 for the operation of the VIC, then remove it. The argument of sanity
 checking could apply to all interrupt controllers.
 
 Sorry, but I don't get what's wrong in having a more detailed description 
 than required just for operation of the hardware.
 
 The feature of sanity checks based on interrupt_mask (here now called 
 valid-mask) has been present in the VIC driver since a long time already 
 (if not from the beginning of existence of this driver) and before we 
 started using DT, the mask was being passed from platform code as VIC init 
 function argument.

So we should base the binding on the Linux software design?

 I'd prefer this feature to be available when using DT as well, unless we 
 really want to move things backwards, just because we want to use DT...

As I mentioned all these arguments apply to ALL interrupt controllers
except ones which a mask does not work. So IF this makes sense, then
this should be a generic property and generic code to support.

You simply have the same information twice. One is distributed and one
is centralized. While it adds a way to validate things it also adds a
way to introduce errors. Suppose someone writes a dts such that
valid-mask matches the irq lines present in that dts (simply because
they were lazy or don't have documentation of all interrupt lines). Then
you go add a node with a new interrupt (because the initial dts was not
complete). Updating the valid-mask could very easily be forgotten. Yes,
this should all be found by testing, but people don't always have access
to all the h/w. This issue would also not likely be obvious in a review.

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

Re: [PATCH RESEND] i2c: move of helpers into the core

[Rob Herring]

On 08/19/2013 12:59 PM, Wolfram Sang wrote:
 I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
 that it is much cleaner to have this in the core. This also removes a
 circular dependency between the helpers and the core, and so we can
 finally register child nodes in the core instead of doing this manually
 in each driver. So, fix the drivers and documentation, too.
 
 Signed-off-by: Wolfram Sang w...@the-dreams.de
 ---

Glad to see this.

Acked-by: Rob Herring rob.herr...@calxeda.com

 
 Sigh, hitting the CC threshold on vger again. So resending to the lists only.
 BTW this patch is based on -rc4 and was tested on an AT91 board. More tests
 very welcome. Thanks!
 
 
  Documentation/acpi/enumeration.txt  |1 -
  drivers/i2c/busses/i2c-at91.c   |3 -
  drivers/i2c/busses/i2c-cpm.c|6 --
  drivers/i2c/busses/i2c-davinci.c|2 -
  drivers/i2c/busses/i2c-designware-platdrv.c |2 -
  drivers/i2c/busses/i2c-gpio.c   |3 -
  drivers/i2c/busses/i2c-i801.c   |2 -
  drivers/i2c/busses/i2c-ibm_iic.c|4 -
  drivers/i2c/busses/i2c-imx.c|3 -
  drivers/i2c/busses/i2c-mpc.c|2 -
  drivers/i2c/busses/i2c-mv64xxx.c|3 -
  drivers/i2c/busses/i2c-mxs.c|3 -
  drivers/i2c/busses/i2c-nomadik.c|3 -
  drivers/i2c/busses/i2c-ocores.c |3 -
  drivers/i2c/busses/i2c-octeon.c |3 -
  drivers/i2c/busses/i2c-omap.c   |3 -
  drivers/i2c/busses/i2c-pnx.c|3 -
  drivers/i2c/busses/i2c-powermac.c   |9 +-
  drivers/i2c/busses/i2c-pxa.c|2 -
  drivers/i2c/busses/i2c-s3c2410.c|2 -
  drivers/i2c/busses/i2c-sh_mobile.c  |2 -
  drivers/i2c/busses/i2c-sirf.c   |3 -
  drivers/i2c/busses/i2c-stu300.c |2 -
  drivers/i2c/busses/i2c-tegra.c  |3 -
  drivers/i2c/busses/i2c-versatile.c  |2 -
  drivers/i2c/busses/i2c-wmt.c|3 -
  drivers/i2c/busses/i2c-xiic.c   |3 -
  drivers/i2c/i2c-core.c  |  107 -
  drivers/i2c/i2c-mux.c   |3 -
  drivers/i2c/muxes/i2c-arb-gpio-challenge.c  |1 -
  drivers/i2c/muxes/i2c-mux-gpio.c|1 -
  drivers/i2c/muxes/i2c-mux-pinctrl.c |1 -
  drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 -
  drivers/of/Kconfig  |6 --
  drivers/of/Makefile |1 -
  drivers/of/of_i2c.c |  114 
 ---
  include/linux/i2c.h |   20 
  include/linux/of_i2c.h  |   46 -
  38 files changed, 130 insertions(+), 253 deletions(-)
  delete mode 100644 drivers/of/of_i2c.c
  delete mode 100644 include/linux/of_i2c.h
 
 diff --git a/Documentation/acpi/enumeration.txt 
 b/Documentation/acpi/enumeration.txt
 index d9be7a9..958266e 100644
 --- a/Documentation/acpi/enumeration.txt
 +++ b/Documentation/acpi/enumeration.txt
 @@ -238,7 +238,6 @@ An I2C bus (controller) driver does:
   if (ret)
   /* handle error */
  
 - of_i2c_register_devices(adapter);
   /* Enumerate the slave devices behind this bus via ACPI */
   acpi_i2c_register_devices(adapter);
  
 diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
 index 6bb839b..fd05930 100644
 --- a/drivers/i2c/busses/i2c-at91.c
 +++ b/drivers/i2c/busses/i2c-at91.c
 @@ -28,7 +28,6 @@
  #include linux/module.h
  #include linux/of.h
  #include linux/of_device.h
 -#include linux/of_i2c.h
  #include linux/platform_device.h
  #include linux/slab.h
  #include linux/platform_data/dma-atmel.h
 @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev)
   return rc;
   }
  
 - of_i2c_register_devices(dev-adapter);
 -
   dev_info(dev-dev, AT91 i2c bus driver.\n);
   return 0;
  }
 diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
 index 2e1f7eb..b2b8aa9 100644
 --- a/drivers/i2c/busses/i2c-cpm.c
 +++ b/drivers/i2c/busses/i2c-cpm.c
 @@ -42,7 +42,6 @@
  #include linux/dma-mapping.h
  #include linux/of_device.h
  #include linux/of_platform.h
 -#include linux/of_i2c.h
  #include sysdev/fsl_soc.h
  #include asm/cpm.h
  
 @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev)
   dev_dbg(ofdev-dev, hw routines for %s registered.\n,
   cpm-adap.name);
  
 - /*
 -  * register OF I2C devices
 -  */
 - of_i2c_register_devices(cpm-adap);
 -
   return 0;
  out_shut:
   cpm_i2c_shutdown(cpm);
 diff --git a/drivers/i2c/busses/i2c-davinci.c 
 b

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

[Rob Herring]

On Thu, Aug 1, 2013 at 8:05 AM, Cho KyongHo pullip@samsung.com wrote:
 -Original Message-
 From: Rob Herring [mailto:robherri...@gmail.com]
 Sent: Saturday, July 27, 2013 10:55 PM
 On Fri, Jul 26, 2013 at 6:28 AM, Cho KyongHo pullip@samsung.com wrote:
  Signed-off-by: Cho KyongHo pullip@samsung.com
  ---
   .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
   arch/arm/boot/dts/exynos4.dtsi |  122 
   arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
   arch/arm/boot/dts/exynos4x12.dtsi  |   76 +
   arch/arm/boot/dts/exynos5250.dtsi  |  291 
  
   5 files changed, 617 insertions(+), 0 deletions(-)
   create mode 100644 
  Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
 
  diff --git 
  a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
  b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
  new file mode 100644
  index 000..92f0a33
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
  @@ -0,0 +1,103 @@
  +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
  +
  +Samsung's Exynos architecture contains System MMU that enables scattered
  +physical memory chunks visible as a contiguous region to DMA-capable 
  peripheral
  +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
  +
  +System MMU is a sort of IOMMU and support identical translation table 
  format to
  +ARMv7 translation tables with minimum set of page properties including 
  access
  +permissions, shareability and security protection. In addition, System 
  MMU has
  +another capabilities like L2 TLB or block-fetch buffers to minimize 
  translation
  +latency.
  +
  +A System MMU is dedicated to a single master peripheral device.  Thus, it 
  is
  +important to specify the correct System MMU in the device node of its 
  master
  +device. Whereas a System MMU is dedicated to a master device, the master 
  device
  +may have more than one System MMU.

 I don't follow the last sentence. Can you elaborate on the type of
 connection you are talking about.

 Grant also addressed that.
 He corrected the sentence like the following:

Can I suggest rewriting the last two sentences to:
  The master device node must correctly specify at least one
  SystemMMU. A master  device may have more than one System MMU. 

 I will change the sentence

 Also, please align with the ARM system MMU binding that Will Deacon
 has submitted particularly in terms of how master connections are
 described.

 I didn't check it.

 Should this align with ARM System MMU bindings?
 System MMU in Exynos SoC is different from ARM System MMU.
 It does not follows the specifications of ARM System MMU.

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

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

Re: [PATCH] of: provide of_platform_unpopulate()

[Rob Herring]

On 07/29/2013 04:33 AM, Benjamin Herrenschmidt wrote:
 On Mon, 2013-07-22 at 00:44 +0100, Grant Likely wrote:
 BTW, it looks like Grant has attempted this already:

 Yup, things broke badly. Unfortunately the of_platform_device and
 platform_device history doesn't treat resources in the same way. I
 would like to merge the code, but I haven't been able to figure out a
 clean way to do it. Looks like we do need the unpopulate function.
 
 What is the exact problem Grant ? Care to give me an example ?
 

See this thread:

http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg63678.html

Rob

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

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

[Rob Herring]

On Fri, Jul 26, 2013 at 6:28 AM, Cho KyongHo pullip@samsung.com wrote:
 Signed-off-by: Cho KyongHo pullip@samsung.com
 ---
  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++
  arch/arm/boot/dts/exynos4.dtsi |  122 
  arch/arm/boot/dts/exynos4210.dtsi  |   25 ++
  arch/arm/boot/dts/exynos4x12.dtsi  |   76 +
  arch/arm/boot/dts/exynos5250.dtsi  |  291 
 
  5 files changed, 617 insertions(+), 0 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt

 diff --git 
 a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
 b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
 new file mode 100644
 index 000..92f0a33
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
 @@ -0,0 +1,103 @@
 +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
 +
 +Samsung's Exynos architecture contains System MMU that enables scattered
 +physical memory chunks visible as a contiguous region to DMA-capable 
 peripheral
 +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
 +
 +System MMU is a sort of IOMMU and support identical translation table format 
 to
 +ARMv7 translation tables with minimum set of page properties including access
 +permissions, shareability and security protection. In addition, System MMU 
 has
 +another capabilities like L2 TLB or block-fetch buffers to minimize 
 translation
 +latency.
 +
 +A System MMU is dedicated to a single master peripheral device.  Thus, it is
 +important to specify the correct System MMU in the device node of its master
 +device. Whereas a System MMU is dedicated to a master device, the master 
 device
 +may have more than one System MMU.

I don't follow the last sentence. Can you elaborate on the type of
connection you are talking about.

Also, please align with the ARM system MMU binding that Will Deacon
has submitted particularly in terms of how master connections are
described.

Rob

 +
 +Required properties:
 +- compatible: Should be samsung,exynos4210-sysmmu
 +- reg: A tuple of base address and size of System MMU registers.
 +- interrupt-parent: The phandle of the interrupt controller of System MMU
 +- interrupts: A tuple of numbers that indicates the interrupt source.
 +- clock-names: Should be sysmmu if the System MMU is needed to gate its 
 clock.
 +   Please refer to the following documents:
 +  Documentation/devicetree/bindings/clock/clock-bindings.txt
 +  Documentation/devicetree/bindings/clock/exynos4-clock.txt
 +  Documentation/devicetree/bindings/clock/exynos5250-clock.txt
 +  Optional master if the clock to the System MMU is gated by
 +  another gate clock other than sysmmu. The System MMU driver
 +  sets master the parent of sysmmu.
 +  Exynos4 SoCs, there needs no master clocks.
 +  Exynos5 SoCs, some System MMUs must have master clocks.
 +- clocks: Required if the System MMU is needed to gate its clock.
 + Please refer to the documents listed above.
 +- samsung,power-domain: Required if the System MMU is needed to gate its 
 power.
 + Please refer to the following document:
 + Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 +
 +Required properties for the master peripheral devices:
 +- iommu: phandles to the System MMUs of the device
 +
 +Examples:
 +A System MMU is dedicated to a single master device.
 +   gsc_0:  gsc@0x13e0 {
 +   compatible = samsung,exynos5-gsc;
 +   reg = 0x13e0 0x1000;
 +   interrupts = 0 85 0;
 +   samsung,power-domain = pd_gsc;
 +   clocks = clock 256;
 +   clock-names = gscl;
 +   iommu = sysmmu_gsc1;
 +   };
 +
 +   sysmmu_gsc0: sysmmu@13E8 {
 +   compatible = samsung,exynos4210-sysmmu;
 +   reg = 0x13E8 0x1000;
 +   interrupt-parent = combiner;
 +   interrupt-names = sysmmu-gsc0;
 +   interrupts = 2 0;
 +   clock-names = sysmmu, master;
 +   clocks = clock 262, clock 256;
 +   samsung,power-domain = pd_gsc;
 +   status = ok;
 +   };
 +
 +MFC has 2 System MMUs for each port that MFC is attached. Thus it seems 
 natural
 +to define 2 System MMUs for each port of the MFC:
 +
 +   mfc: codec@1340 {
 +   compatible = samsung,mfc-v5;
 +   reg = 0x1340 0x1;
 +   interrupts = 0 94 0;
 +   samsung,power-domain = pd_mfc;
 +   clocks = clock 170, clock 273;
 +   clock-names = sclk_mfc, mfc;
 +   status = ok;
 +   iommu = sysmmu_mfc_l, sysmmu_mfc_r;
 +   };
 +
 +   sysmmu_mfc_l: 

Re: [PATCH] of: provide of_platform_unpopulate()

[Rob Herring]

On 07/21/2013 06:44 PM, Grant Likely wrote:
 On Sun, Jul 21, 2013 at 9:48 PM, Rob Herring robherri...@gmail.com wrote:
 On 07/21/2013 09:42 AM, Rob Herring wrote:
 On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote:
 So I called of_platform_populate() on a device to get each child device
 probed and on rmmod and I need to reverse its doing. After a quick grep
 I did what others did as well and rmmod ended in:

 | Unable to handle kernel NULL pointer dereference at virtual address 
 0018
 | PC is at release_resource+0x18/0x80
 | Process rmmod (pid: 2005, stack limit = 0xedc30238)
 | [c003add0] (release_resource+0x18/0x80) from [c0300e08] 
 (platform_device_del+0x78/0xac)
 | [c0300e08] (platform_device_del+0x78/0xac) from [c0301358] 
 (platform_device_unregister+0xc/0x18)

 The problem is that platform_device_del() releases each ressource in its
 tree. This does not work on platform_devices created by OF becuase they
 were never added via insert_resource(). As a consequence old-parent in
 __release_resource() is NULL and we explode while accessing -child.
 So I either I do something completly wrong _or_ nobody here tested the
 rmmod path of their driver.

 Wouldn't the correct fix be to call insert_resource somehow? The problem
 I have is that while of_platform_populate is all about parsing the DT
 and creating devices, the removal side has nothing to do with DT. So
 this should not be in the DT code. I think the core device code should
 be able to handle removal if the device creation side is done correctly.

 It looks to me like of_device_add either needs to call
 platform_device_add rather than device_add. I think the device name
 setting in platform_device_add should be a nop. If not, a check that the
 name is already set could be added.


 BTW, it looks like Grant has attempted this already:
 
 Yup, things broke badly. Unfortunately the of_platform_device and
 platform_device history doesn't treat resources in the same way. I
 would like to merge the code, but I haven't been able to figure out a
 clean way to do it. Looks like we do need the unpopulate function.

Was there more breakage than imx6 and amba devices? Your first version
had a fallback case for powerpc. Couldn't we do just allow that for more
than just powerpc? I'd much rather see some work-around within the core
DT code with a warning to prevent more proliferation than putting this
into drivers.

Rob

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

Re: [PATCH] of: provide of_platform_unpopulate()

[Rob Herring]

On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote:
 So I called of_platform_populate() on a device to get each child device
 probed and on rmmod and I need to reverse its doing. After a quick grep
 I did what others did as well and rmmod ended in:
 
 | Unable to handle kernel NULL pointer dereference at virtual address 0018
 | PC is at release_resource+0x18/0x80
 | Process rmmod (pid: 2005, stack limit = 0xedc30238)
 | [c003add0] (release_resource+0x18/0x80) from [c0300e08] 
 (platform_device_del+0x78/0xac)
 | [c0300e08] (platform_device_del+0x78/0xac) from [c0301358] 
 (platform_device_unregister+0xc/0x18)
 
 The problem is that platform_device_del() releases each ressource in its
 tree. This does not work on platform_devices created by OF becuase they
 were never added via insert_resource(). As a consequence old-parent in
 __release_resource() is NULL and we explode while accessing -child.
 So I either I do something completly wrong _or_ nobody here tested the
 rmmod path of their driver.

Wouldn't the correct fix be to call insert_resource somehow? The problem
I have is that while of_platform_populate is all about parsing the DT
and creating devices, the removal side has nothing to do with DT. So
this should not be in the DT code. I think the core device code should
be able to handle removal if the device creation side is done correctly.

It looks to me like of_device_add either needs to call
platform_device_add rather than device_add. I think the device name
setting in platform_device_add should be a nop. If not, a check that the
name is already set could be added.

Rob

 
 This patch provides a common function to unregister / remove devices
 which added to the system via of_platform_populate(). While this works
 now on my test case I have not tested any of the driver I modify here so
 feedback is greatly appreciated.
 
 Cc: Tony Lindgren t...@atomide.com
 Cc: Doug Anderson diand...@chromium.org
 Cc: Vivek Gautam gautam.vi...@samsung.com
 Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Cc: Kukjin Kim kgene@samsung.com
 Cc: Kishon Vijay Abraham I kis...@ti.com
 Cc: Roger Quadros rog...@ti.com
 Cc: George Cherian george.cher...@ti.com
 Cc: Felipe Balbi ba...@ti.com
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  drivers/bus/omap-ocp2scp.c | 13 ++---
  drivers/iio/adc/exynos_adc.c   | 15 ++-
  drivers/mfd/omap-usb-host.c|  9 +
  drivers/of/platform.c  | 22 ++
  drivers/usb/dwc3/dwc3-exynos.c | 11 +--
  drivers/usb/dwc3/dwc3-omap.c   | 12 +---
  include/linux/of_platform.h|  4 
  7 files changed, 33 insertions(+), 53 deletions(-)
 
 diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
 index 5511f98..510bb9e 100644
 --- a/drivers/bus/omap-ocp2scp.c
 +++ b/drivers/bus/omap-ocp2scp.c
 @@ -23,15 +23,6 @@
  #include linux/of.h
  #include linux/of_platform.h
  
 -static int ocp2scp_remove_devices(struct device *dev, void *c)
 -{
 - struct platform_device *pdev = to_platform_device(dev);
 -
 - platform_device_unregister(pdev);
 -
 - return 0;
 -}
 -
  static int omap_ocp2scp_probe(struct platform_device *pdev)
  {
   int ret;
 @@ -51,7 +42,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
   return 0;
  
  err0:
 - device_for_each_child(pdev-dev, NULL, ocp2scp_remove_devices);
 + of_platform_unpopulate(pdev-dev);
  
   return ret;
  }
 @@ -59,7 +50,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
  static int omap_ocp2scp_remove(struct platform_device *pdev)
  {
   pm_runtime_disable(pdev-dev);
 - device_for_each_child(pdev-dev, NULL, ocp2scp_remove_devices);
 + of_platform_unpopulate(pdev-dev);
  
   return 0;
  }
 diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
 index 9809fc9..10248e1 100644
 --- a/drivers/iio/adc/exynos_adc.c
 +++ b/drivers/iio/adc/exynos_adc.c
 @@ -216,15 +216,6 @@ static const struct iio_chan_spec 
 exynos_adc_iio_channels[] = {
   ADC_CHANNEL(9, adc9),
  };
  
 -static int exynos_adc_remove_devices(struct device *dev, void *c)
 -{
 - struct platform_device *pdev = to_platform_device(dev);
 -
 - platform_device_unregister(pdev);
 -
 - return 0;
 -}
 -
  static void exynos_adc_hw_init(struct exynos_adc *info)
  {
   u32 con1, con2;
 @@ -357,8 +348,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
   return 0;
  
  err_of_populate:
 - device_for_each_child(pdev-dev, NULL,
 - exynos_adc_remove_devices);
 + of_platform_unpopulate(pdev-dev);
   regulator_disable(info-vdd);
   clk_disable_unprepare(info-clk);
  err_iio_dev:
 @@ -375,8 +365,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
   struct iio_dev *indio_dev = platform_get_drvdata(pdev);
   struct exynos_adc *info = iio_priv(indio_dev);
  
 - device_for_each_child(pdev-dev, NULL,
 -  

Re: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs

[Rob Herring]

On Tue, Apr 16, 2013 at 8:19 AM, Tomasz Figa t.f...@samsung.com wrote:
 On Tuesday 16 of April 2013 08:09:10 Rob Herring wrote:
 On 04/15/2013 04:14 PM, Tomasz Figa wrote:
  This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
 
  Since all the SoCs in the series are very similar, the files are created
  hierarchically - one file for the whole series and then separate files
  for particular SoCs including the common one.
 
  Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
  ---
 
   arch/arm/boot/dts/s3c6400.dtsi |  33 ++
   arch/arm/boot/dts/s3c6410.dtsi |  33 ++
   arch/arm/boot/dts/s3c64xx-pinctrl.dtsi | 683
   + arch/arm/boot/dts/s3c64xx.dtsi
   | 136 +++
   4 files changed, 885 insertions(+)
   create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
   create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
   create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
   create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi

 [...]

  +
  +   vic0: interrupt-controller@7120 {

 These nodes should be off a simple-bus node.

 Hmm, is there any reason behind it?

 I thought simple bus was just a convenient helper to represent hierarchical
 bus structures if one has a need to do so.

No. The DT should reflect the bus structure of the chip. How
accurately it is done is up to you and the information available, but
you have to have a bus of some sort.

There's obvious examples that don't follow this, but I'd like to not have more.

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

Re: [PATCH v5 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs

[Rob Herring]

On 04/15/2013 04:14 PM, Tomasz Figa wrote:
 This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
 
 Since all the SoCs in the series are very similar, the files are created
 hierarchically - one file for the whole series and then separate files
 for particular SoCs including the common one.
 
 Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
 ---
  arch/arm/boot/dts/s3c6400.dtsi |  33 ++
  arch/arm/boot/dts/s3c6410.dtsi |  33 ++
  arch/arm/boot/dts/s3c64xx-pinctrl.dtsi | 683 
 +
  arch/arm/boot/dts/s3c64xx.dtsi | 136 +++
  4 files changed, 885 insertions(+)
  create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
  create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
  create mode 100644 arch/arm/boot/dts/s3c64xx-pinctrl.dtsi
  create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
 

[...]

 +
 + vic0: interrupt-controller@7120 {

These nodes should be off a simple-bus node.

Rob

 + compatible = arm,pl192-vic;
 + interrupt-controller;
 + reg = 0x7120 0x1000;
 + #interrupt-cells = 1;
 + };
 +
 + vic1: interrupt-controller@7130 {
 + compatible = arm,pl192-vic;
 + interrupt-controller;
 + reg = 0x7130 0x1000;
 + #interrupt-cells = 1;
 + };
 +
 + pinctrl0: pinctrl@7f008000 {
 + compatible = samsung,s3c64xx-pinctrl;
 + reg = 0x7f008000 0x1000;
 + interrupt-parent = vic1;
 + interrupts = 21;
 +
 + pctrl_int_map: pinctrl-interrupt-map {
 + interrupt-map = 0 vic0 0,
 + 1 vic0 1,
 + 2 vic1 0,
 + 3 vic1 1;
 + #address-cells = 0;
 + #size-cells = 0;
 + #interrupt-cells = 1;
 + };
 +
 + wakeup-interrupt-controller {
 + compatible = samsung,s3c64xx-wakeup-eint;
 + interrupts = 0, 1, 2, 3;
 + interrupt-parent = pctrl_int_map;
 + };
 + };
 +
 + pwm: pwm@7f006000 {
 + compatible = samsung,s3c6400-pwm;
 + reg = 0x7f006000 0x1000;
 + interrupt-parent = vic0;
 + interrupts = 23, 24, 25, 27, 28;
 + samsung,pwm-outputs = 0, 1;
 + #pwm-cells = 3;
 + status = disabled;
 + };
 +
 + uart0: serial@7f005000 {
 + compatible = samsung,s3c6400-uart;
 + reg = 0x7f005000 0x100;
 + interrupt-parent = vic1;
 + interrupts = 5;
 + status = disabled;
 + };
 +
 + uart1: serial@7f005400 {
 + compatible = samsung,s3c6400-uart;
 + reg = 0x7f005400 0x100;
 + interrupt-parent = vic1;
 + interrupts = 6;
 + status = disabled;
 + };
 +
 + uart2: serial@7f005800 {
 + compatible = samsung,s3c6400-uart;
 + reg = 0x7f005800 0x100;
 + interrupt-parent = vic1;
 + interrupts = 7;
 + status = disabled;
 + };
 +
 + uart3: serial@7f005c00 {
 + compatible = samsung,s3c6400-uart;
 + reg = 0x7f005c00 0x100;
 + interrupt-parent = vic1;
 + interrupts = 8;
 + status = disabled;
 + };
 +
 + sdhci0: sdhci@7c20 {
 + compatible = samsung,s3c6410-sdhci;
 + reg = 0x7c20 0x100;
 + interrupt-parent = vic1;
 + interrupts = 24;
 + status = disabled;
 + };
 +
 + sdhci1: sdhci@7c30 {
 + compatible = samsung,s3c6410-sdhci;
 + reg = 0x7c30 0x100;
 + interrupt-parent = vic1;
 + interrupts = 25;
 + status = disabled;
 + };
 +
 + sdhci2: sdhci@7c40 {
 + compatible = samsung,s3c6410-sdhci;
 + reg = 0x7c40 0x100;
 + interrupt-parent = vic1;
 + interrupts = 17;
 + status = disabled;
 + };
 +};
 +
 +/include/ s3c64xx-pinctrl.dtsi
 

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

Re: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC

[Rob Herring]

Adding Ben H and Michal...

On 04/10/2013 02:29 AM, Andrew Murray wrote:
 The pci_process_bridge_OF_ranges function, used to parse the ranges
 property of a PCI host device, is found in both Microblaze and PowerPC
 architectures. These implementations are nearly identical. This patch
 moves this common code to a common place.
 
 Signed-off-by: Andrew Murray andrew.mur...@arm.com
 Signed-off-by: Liviu Dudau liviu.du...@arm.com

One comment below. Otherwise,

Reviewed-by: Rob Herring rob.herr...@calxeda.com

You need also need acks from Ben and Michal.

[...]

 + /* Act based on address space type */
 + res = NULL;
 + switch ((pci_space  24)  0x3) {
 + case 1: /* PCI IO space */
 + pr_info(  IO 0x%016llx..0x%016llx - 0x%016llx\n,
 +cpu_addr, cpu_addr + size - 1, pci_addr);
 +
 + /* We support only one IO range */
 + if (hose-pci_io_size) {
 + pr_info( \\-- Skipped (too many) !\n);
 + continue;
 + }
 +#if defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE)

How about if (!IS_ENABLED(CONFIG_64BIT)) instead.

 + /* On 32 bits, limit I/O space to 16MB */
 + if (size  0x0100)
 + size = 0x0100;
 +
 + /* 32 bits needs to map IOs here */
 + hose-io_base_virt = ioremap(cpu_addr, size);
 +
 + /* Expect trouble if pci_addr is not 0 */
 + if (primary)
 + isa_io_base =
 + (unsigned long)hose-io_base_virt;
 +#endif /* CONFIG_PPC32 || CONFIG_MICROBLAZE */
 + /* pci_io_size and io_base_phys always represent IO
 +  * space starting at 0 so we factor in pci_addr
 +  */
 + hose-pci_io_size = pci_addr + size;
 + hose-io_base_phys = cpu_addr - pci_addr;

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

Re: [PATCH v5 2/3] of/pci: Provide support for parsing PCI DT ranges property

[Rob Herring]

On 04/10/2013 02:29 AM, Andrew Murray wrote:
 This patch factors out common implementation patterns to reduce overall kernel
 code and provide a means for host bridge drivers to directly obtain struct
 resources from the DT's ranges property without relying on architecture 
 specific
 DT handling. This will make it easier to write archiecture independent host 
 bridge
 drivers and mitigate against further duplication of DT parsing code.
 
 This patch can be used in the following way:
 
   struct of_pci_range_parser parser;
   struct of_pci_range range;
 
   if (of_pci_range_parser(parser, np))
   ; //no ranges property
 
   for_each_of_pci_range(parser, range) {
 
   /*
   directly access properties of the address range, e.g.:
   range.pci_space, range.pci_addr, range.cpu_addr,
   range.size, range.flags
 
   alternatively obtain a struct resource, e.g.:
   struct resource res;
   of_pci_range_to_resource(range, np, res);
   */
   }
 
 Additionally the implementation takes care of adjacent ranges and merges them
 into a single range (as was the case with powerpc and microblaze).
 
 Signed-off-by: Andrew Murray andrew.mur...@arm.com
 Signed-off-by: Liviu Dudau liviu.du...@arm.com
 Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
 ---

A few minor things below, otherwise:

Reviewed-by: Rob Herring rob.herr...@calxeda.com

  drivers/of/address.c   |   63 +
  drivers/of/of_pci.c|  112 
 
  include/linux/of_address.h |   42 
  3 files changed, 145 insertions(+), 72 deletions(-)
 
 diff --git a/drivers/of/address.c b/drivers/of/address.c
 index 04da786..e87f45e 100644
 --- a/drivers/of/address.c
 +++ b/drivers/of/address.c
 @@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev, 
 int bar,
   return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
  }
  EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
 +
 +int of_pci_range_parser(struct of_pci_range_parser *parser,
 + struct device_node *node)
 +{
 + const int na = 3, ns = 2;
 + int rlen;
 +
 + parser-node = node;
 + parser-pna = of_n_addr_cells(node);
 + parser-np = parser-pna + na + ns;
 +
 + parser-range = of_get_property(node, ranges, rlen);
 + if (parser-range == NULL)
 + return -ENOENT;
 +
 + parser-end = parser-range + rlen / sizeof(__be32);
 +
 + return 0;
 +}
 +
 +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser 
 *parser,
 + struct of_pci_range *range)
 +{
 + const int na = 3, ns = 2;
 +
 + if (!parser-range || parser-range + parser-np  parser-end)

Add a !range check

 + return NULL;
 +
 + range-pci_space = be32_to_cpup(parser-range);
 + range-flags = of_bus_pci_get_flags(parser-range);
 + range-pci_addr = of_read_number(parser-range + 1, ns);
 + range-cpu_addr = of_translate_address(parser-node,
 + parser-range + na);
 + range-size = of_read_number(parser-range + parser-pna + na, ns);
 +
 + parser-range += parser-np;
 +
 + /* Now consume following elements while they are contiguous */
 + while (parser-range + parser-np = parser-end) {
 + u32 flags, pci_space;
 + u64 pci_addr, cpu_addr, size;
 +
 + pci_space = be32_to_cpup(parser-range);

This line doesn't do anything.

 + flags = of_bus_pci_get_flags(parser-range);
 + pci_addr = of_read_number(parser-range + 1, ns);
 + cpu_addr = of_translate_address(parser-node,
 + parser-range + na);
 + size = of_read_number(parser-range + parser-pna + na, ns);
 +
 + if (flags != range-flags)
 + break;
 + if (pci_addr != range-pci_addr + range-size ||
 + cpu_addr != range-cpu_addr + range-size)
 + break;
 +
 + range-size += size;
 + parser-range += parser-np;
 + }
 +
 + return range;
 +}
 +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
 +
  #endif /* CONFIG_PCI */
  
  /*
 diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
 index 0611248..9680dc6 100644
 --- a/drivers/of/of_pci.c
 +++ b/drivers/of/of_pci.c
 @@ -82,67 +82,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
  void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 struct device_node *dev, int primary)
  {
 - const u32 *ranges;
 - int rlen;
 - int pna = of_n_addr_cells(dev);
 - int np = pna + 5;
   int memno = 0, isa_hole = -1;
 - u32 pci_space;
 - unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
   unsigned long long

Re: [PATCH v5 3/3] of/pci: mips: convert to common of_pci_range_parser

[Rob Herring]

On 04/10/2013 02:29 AM, Andrew Murray wrote:
 This patch converts the pci_load_of_ranges function to use the new common
 of_pci_range_parser.
 
 Signed-off-by: Andrew Murray andrew.mur...@arm.com
 Signed-off-by: Liviu Dudau liviu.du...@arm.com

Reviewed-by: Rob Herring rob.herr...@calxeda.com


 ---
  arch/mips/pci/pci.c |   50 --
  1 files changed, 16 insertions(+), 34 deletions(-)
 
 diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
 index 0872f12..bee49a4 100644
 --- a/arch/mips/pci/pci.c
 +++ b/arch/mips/pci/pci.c
 @@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
  #ifdef CONFIG_OF
  void pci_load_of_ranges(struct pci_controller *hose, struct device_node 
 *node)
  {
 - const __be32 *ranges;
 - int rlen;
 - int pna = of_n_addr_cells(node);
 - int np = pna + 5;
 + struct of_pci_range_range range;
 + struct of_pci_range_parser parser;
 + u32 res_type;
  
   pr_info(PCI host bridge %s ranges:\n, node-full_name);
 - ranges = of_get_property(node, ranges, rlen);
 - if (ranges == NULL)
 - return;
   hose-of_node = node;
  
 - while ((rlen -= np * 4) = 0) {
 - u32 pci_space;
 + if (of_pci_range_parser(parser, node))
 + return;
 +
 + for_each_of_pci_range(parser, range) {
   struct resource *res = NULL;
 - u64 addr, size;
 -
 - pci_space = be32_to_cpup(ranges[0]);
 - addr = of_translate_address(node, ranges + 3);
 - size = of_read_number(ranges + pna + 3, 2);
 - ranges += np;
 - switch ((pci_space  24)  0x3) {
 - case 1: /* PCI IO space */
 +
 + res_type = range.flags  IORESOURCE_TYPE_BITS;
 + if (res_type == IORESOURCE_IO) {
   pr_info(  IO 0x%016llx..0x%016llx\n,
 - addr, addr + size - 1);
 + range.addr, range.addr + range.size - 1);
   hose-io_map_base =
 - (unsigned long)ioremap(addr, size);
 + (unsigned long)ioremap(range.addr, range.size);
   res = hose-io_resource;
 - res-flags = IORESOURCE_IO;
 - break;
 - case 2: /* PCI Memory space */
 - case 3: /* PCI 64 bits Memory space */
 + } else if (res_type == IORESOURCE_MEM) {
   pr_info( MEM 0x%016llx..0x%016llx\n,
 - addr, addr + size - 1);
 + range.addr, range.addr + range.size - 1);
   res = hose-mem_resource;
 - res-flags = IORESOURCE_MEM;
 - break;
 - }
 - if (res != NULL) {
 - res-start = addr;
 - res-name = node-full_name;
 - res-end = res-start + size - 1;
 - res-parent = NULL;
 - res-sibling = NULL;
 - res-child = NULL;
   }
 + if (res != NULL)
 + of_pci_range_to_resource(range, node, res);
   }
  }
  #endif
 

--
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/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init

[Rob Herring]

On 04/04/2013 12:56 AM, Simon Horman wrote:
 On Mon, Apr 01, 2013 at 05:21:12PM -0500, Rob Herring wrote:
 From: Rob Herring rob.herr...@calxeda.com

 This converts arm and arm64 to use CLKSRC_OF DT based initialization for
 the arch timer. A new function arch_timer_arch_init is added to allow for
 arch specific setup.

 This has a side effect of enabling sched_clock on omap5 and exynos5. There
 should not be any reason not to use the arch timers for sched_clock.
 
 Would it be possible for you to either delay the removal of
 shmobile_timer_init. In general I am in favour of the following
 approach to wide changes such as this one:

I will simply change shmobile_timer_init to call clocksource_of_init
rather than deleting it. That should keep the new users working and then
it can be deleted latter.

 1. Add new feature
 2. Convert users to new feature
 3. Remove old feature.
 
 If it is not possible to delay the removal of shmobile_timer_init could you
 update your base such that you also remove its usage from the following
 files:
 
 arch/arm/mach-shmobile/board-kzm9g-reference.c
 arch/arm/mach-shmobile/setup-r8a73a4.c
 arch/arm/mach-shmobile/setup-r8a7779.c
 arch/arm/mach-shmobile/board-lager.c
 arch/arm/mach-shmobile/board-ape6evm.c
 arch/arm/mach-shmobile/setup-r8a7778.c
 arch/arm/mach-shmobile/board-marzen-reference.c
 arch/arm/mach-shmobile/setup-r8a7790.c
 arch/arm/mach-shmobile/board-bockw.c

Why so many boards? There's been prior discussions about whether to add
DT into existing board files or start with a minimal DT board file and
add to it. The fact that there are 14 mach desc's using
shmobile_timer_init which is a function only used for DT and 17 DT mach
descs total for shmobile tells me perhaps the latter approach is needed.

Either way, it is good to see progress on DT support in shmobile.

Rob

 The above files are all present in the arm-soc/next/boards2 branch
 of the arm-soc tree which has pulled the renesas-boards3-for-v3.10 tag
 of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git.
 I am happy for you use the later as a base if you wish.
 
 Signed-off-by: Rob Herring rob.herr...@calxeda.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Kukjin Kim kgene@samsung.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Simon Horman ho...@verge.net.au
 Cc: Magnus Damm magnus.d...@gmail.com
 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: John Stultz john.stu...@linaro.org
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: linux-samsung-soc@vger.kernel.org
 Cc: linux-o...@vger.kernel.org
 Cc: linux...@vger.kernel.org
 ---
  arch/arm/include/asm/arch_timer.h|   13 +
  arch/arm/kernel/arch_timer.c |   17 +++--
  arch/arm/mach-exynos/mach-exynos5-dt.c   |1 -
  arch/arm/mach-exynos/mct.c   |6 --
  arch/arm/mach-highbank/highbank.c|5 +
  arch/arm/mach-omap2/timer.c  |5 +
  arch/arm/mach-shmobile/board-kzm9d.c |1 -
 
 I have boot tested the board-kzm9d change on the kzm9d board, it seems fine.
 
  arch/arm/mach-shmobile/include/mach/common.h |1 -
  arch/arm/mach-shmobile/setup-emev2.c |1 -
 
 I am not able to test the setup-emev2 portion properly at this time,
 booting the kzm9d board without the board-kzm9d file seems broken without
 your patch. However, your change seems reasonable to me.
 
  arch/arm/mach-shmobile/setup-r8a7740.c   |1 -
 
 I am not able to test the setup-r8a7740 portion properly at this time,
 booting the armadillo800eva board without the board-armadillo800eva file
 seems broken without your patch. However, your change seems reasonable to
 me.
 
  arch/arm/mach-shmobile/setup-sh7372.c|1 -
 
 I am not able to test the setup-sh7372 portion properly at this time,
 booting the mackerel board without the board-mackerel file seems broken 
 without
 your patch. However, your change seems reasonable to me.
 
  arch/arm/mach-shmobile/setup-sh73a0.c|1 -
 
 I have boot tested the setup-sh73a0 change on the kzm9g board, it seems fine.
 
 
 The tests above were made by merging
 
 git://sources.calxeda.com/kernel/linux.git arm-timers
 head commit: df3f518db302caf9fc0511917c5e9021037f6fcd
(devtree: add binding documentation for sp804)
 
 and the renesas-next-20130403 tag of the renesas tree (URL above).
 
  arch/arm/mach-shmobile/timer.c   |6 --
  arch/arm/mach-vexpress/v2m.c |7 ++-
  arch/arm/mach-virt/virt.c|9 -
  arch/arm64/include/asm/arch_timer.h  |5 +
  arch/arm64/kernel/time.c |6 --
  drivers/clocksource/Kconfig  |1 +
  drivers/clocksource/arm_arch_timer.c |   23 +--
  include/clocksource/arm_arch_timer.h |6 --
  20 files changed, 27 insertions(+), 89 deletions(-)

 diff