Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH 11/12] ARM64: dts: marvell: use reworked NAND controller driver on Armada 7K
From: Gregory CLEMENT @ 2017-12-15 10:29 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
	Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Russell King,
	Daniel Mack, Haojian Zhuang, Robert Jarzmik, Eric Miao,
	Catalin Marinas, Will Deacon,
	Ezequiel Garcia <ezequiel.garcia>
In-Reply-To: <20171207201814.30411-12-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Hi Miquel,
 
 On jeu., déc. 07 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Use the new bindings of the reworked Marvell NAND controller driver.
> Also adapt the nand controller node organization to distinguish which
> property is relevant for the controller, and which one is NAND chip
> specific. Expose the partitions as a subnode of the NAND chip.
>
> Remove the 'marvell,nand-enable-arbiter' property, not needed anymore as
> the driver activates the arbiter by default for all boards (either
> needed or harmless).
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Applied on mvebu/dt64

Thanks,

Gregory

> ---
>  arch/arm64/boot/dts/marvell/armada-7040-db.dts     | 52 +++++++++++++---------
>  .../boot/dts/marvell/armada-cp110-master.dtsi      |  8 ++--
>  2 files changed, 36 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> index 52b5341cb270..758452c10612 100644
> --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> @@ -156,36 +156,48 @@
>  	};
>  };
>  
> -&cpm_nand {
> +&cpm_nand_controller {
>  	/*
>  	 * SPI on CPM and NAND have common pins on this board. We can
> -	 * use only one at a time. To enable the NAND (whihch will
> +	 * use only one at a time. To enable the NAND (which will
>  	 * disable the SPI), the "status = "okay";" line have to be
>  	 * added here.
>  	 */
> -	num-cs = <1>;
>  	pinctrl-0 = <&nand_pins>, <&nand_rb>;
>  	pinctrl-names = "default";
> -	nand-ecc-strength = <4>;
> -	nand-ecc-step-size = <512>;
> -	marvell,nand-enable-arbiter;
> -	nand-on-flash-bbt;
> -
> -	partition@0 {
> -		label = "U-Boot";
> -		reg = <0 0x200000>;
> -	};
> -	partition@200000 {
> -		label = "Linux";
> -		reg = <0x200000 0xe00000>;
> -	};
> -	partition@1000000 {
> -		label = "Filesystem";
> -		reg = <0x1000000 0x3f000000>;
> +
> +	nand@0 {
> +		reg = <0>;
> +		label = "pxa3xx_nand-0";
> +		marvell,rb = <0>;
> +		nand-on-flash-bbt;
> +		nand-ecc-strength = <4>;
> +		nand-ecc-step-size = <512>;
> +
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			partition@0 {
> +				label = "U-Boot";
> +				reg = <0 0x200000>;
> +			};
> +
> +			partition@200000 {
> +				label = "Linux";
> +				reg = <0x200000 0xe00000>;
> +			};
> +
> +			partition@1000000 {
> +				label = "Filesystem";
> +				reg = <0x1000000 0x3f000000>;
> +			};
> +
> +		};
>  	};
>  };
>  
> -
>  &cpm_spi1 {
>  	status = "okay";
>  
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index e3b64d03fbd8..8a3cff9a7343 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -309,17 +309,17 @@
>  				status = "disabled";
>  			};
>  
> -			cpm_nand: nand@720000 {
> +			cpm_nand_controller: nand@720000 {
>  				/*
>  				 * Due to the limiation of the pin available
>  				 * this controller is only usable on the CPM
>  				 * for A7K and on the CPS for A8K.
>  				 */
> -				compatible = "marvell,armada-8k-nand",
> -					     "marvell,armada370-nand";
> +				compatible = "marvell,armada-8k-nand-controller",
> +					     "marvell,armada370-nand-controller";
>  				reg = <0x720000 0x54>;
>  				#address-cells = <1>;
> -				#size-cells = <1>;
> +				#size-cells = <0>;
>  				interrupts = <ICU_GRP_NSR 115 IRQ_TYPE_LEVEL_HIGH>;
>  				clocks = <&cpm_clk 1 2>;
>  				marvell,system-controller = <&cpm_syscon0>;
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper
From: Lorenzo Pieralisi @ 2017-12-15 10:29 UTC (permalink / raw)
  To: Shameer Kolothum
  Cc: robin.murphy, marc.zyngier, will.deacon, joro, john.garry, xuwei5,
	guohanjun, iommu, linux-arm-kernel, linux-acpi, devicetree,
	linuxarm
In-Reply-To: <20171214160957.13716-2-shameerali.kolothum.thodi@huawei.com>

On Thu, Dec 14, 2017 at 04:09:55PM +0000, Shameer Kolothum wrote:
> On some platforms msi parent address regions have to be excluded from
> normal IOVA allocation in that they are detected and decoded in a HW
> specific way by system components and so they cannot be considered normal
> IOVA address space.
> 
> Add a helper function that retrieves ITS address regions - the msi
> parent - through IORT device <-> ITS mappings and reserves it so that
> these regions will not be translated by IOMMU and will be excluded from
> IOVA allocations. The function checks for the smmu model number and
> only applies the msi reservation if the platform requires it.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/acpi/arm64/iort.c        | 111 +++++++++++++++++++++++++++++++++++++--
>  drivers/irqchip/irq-gic-v3-its.c |   3 +-
>  include/linux/acpi_iort.h        |   7 ++-
>  3 files changed, 116 insertions(+), 5 deletions(-)

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 95255ec..e2f7bdd 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -39,6 +39,7 @@
>  struct iort_its_msi_chip {
>  	struct list_head	list;
>  	struct fwnode_handle	*fw_node;
> +	phys_addr_t		base_addr;
>  	u32			translation_id;
>  };
>  
> @@ -161,14 +162,16 @@ typedef acpi_status (*iort_find_node_callback)
>  static DEFINE_SPINLOCK(iort_msi_chip_lock);
>  
>  /**
> - * iort_register_domain_token() - register domain token and related ITS ID
> - * to the list from where we can get it back later on.
> + * iort_register_domain_token() - register domain token along with related
> + * ITS ID and base address to the list from where we can get it back later on.
>   * @trans_id: ITS ID.
> + * @base: ITS base address.
>   * @fw_node: Domain token.
>   *
>   * Returns: 0 on success, -ENOMEM if no memory when allocating list element
>   */
> -int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
> +int iort_register_domain_token(int trans_id, phys_addr_t base,
> +			       struct fwnode_handle *fw_node)
>  {
>  	struct iort_its_msi_chip *its_msi_chip;
>  
> @@ -178,6 +181,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
>  
>  	its_msi_chip->fw_node = fw_node;
>  	its_msi_chip->translation_id = trans_id;
> +	its_msi_chip->base_addr = base;
>  
>  	spin_lock(&iort_msi_chip_lock);
>  	list_add(&its_msi_chip->list, &iort_msi_chip_list);
> @@ -581,6 +585,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
>  	return -ENODEV;
>  }
>  
> +static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
> +{
> +	struct iort_its_msi_chip *its_msi_chip;
> +	int ret = -ENODEV;
> +
> +	spin_lock(&iort_msi_chip_lock);
> +	list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
> +		if (its_msi_chip->translation_id == its_id) {
> +			*base = its_msi_chip->base_addr;
> +			ret = 0;
> +			break;
> +		}
> +	}
> +	spin_unlock(&iort_msi_chip_lock);
> +
> +	return ret;
> +}
> +
>  /**
>   * iort_dev_find_its_id() - Find the ITS identifier for a device
>   * @dev: The device.
> @@ -766,6 +788,24 @@ static inline bool iort_iommu_driver_enabled(u8 type)
>  }
>  
>  #ifdef CONFIG_IOMMU_API
> +static struct acpi_iort_node *iort_get_msi_resv_iommu(struct device *dev)
> +{
> +	struct acpi_iort_node *iommu;
> +	struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> +
> +	iommu = iort_get_iort_node(fwspec->iommu_fwnode);
> +
> +	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> +		struct acpi_iort_smmu_v3 *smmu;
> +
> +		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> +		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X)
> +			return iommu;
> +	}
> +
> +	return NULL;
> +}
> +
>  static inline const struct iommu_ops *iort_fwspec_iommu_ops(
>  				struct iommu_fwspec *fwspec)
>  {
> @@ -782,6 +822,69 @@ static inline int iort_add_device_replay(const struct iommu_ops *ops,
>  
>  	return err;
>  }
> +
> +/**
> + * iort_iommu_msi_get_resv_regions - Reserved region driver helper
> + * @dev: Device from iommu_get_resv_regions()
> + * @head: Reserved region list from iommu_get_resv_regions()
> + *
> + * Returns: Number of msi reserved regions on success (0 if platform
> + *          doesn't require the reservation or no associated msi regions),
> + *          appropriate error value otherwise. The ITS interrupt translation
> + *          spaces (ITS_base + SZ_64K, SZ_64K) associated with the device
> + *          are the msi reserved regions.
> + */
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{
> +	struct acpi_iort_its_group *its;
> +	struct acpi_iort_node *iommu_node, *its_node = NULL;
> +	int i, resv = 0;
> +
> +	iommu_node = iort_get_msi_resv_iommu(dev);
> +	if (!iommu_node)
> +		return 0;
> +
> +	/*
> +	 * Current logic to reserve ITS regions relies on HW topologies
> +	 * where a given PCI or named component maps its IDs to only one
> +	 * ITS group; if a PCI or named component can map its IDs to
> +	 * different ITS groups through IORT mappings this function has
> +	 * to be reworked to ensure we reserve regions for all ITS groups
> +	 * a given PCI or named component may map IDs to.
> +	 */
> +
> +	for (i = 0; i < dev->iommu_fwspec->num_ids; i++) {
> +		its_node = iort_node_map_id(iommu_node,
> +					dev->iommu_fwspec->ids[i],
> +					NULL, IORT_MSI_TYPE);
> +		if (its_node)
> +			break;
> +	}
> +
> +	if (!its_node)
> +		return 0;
> +
> +	/* Move to ITS specific data */
> +	its = (struct acpi_iort_its_group *)its_node->node_data;
> +
> +	for (i = 0; i < its->its_count; i++) {
> +		phys_addr_t base;
> +
> +		if (!iort_find_its_base(its->identifiers[i], &base)) {
> +			int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> +			struct iommu_resv_region *region;
> +
> +			region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
> +							 prot, IOMMU_RESV_MSI);
> +			if (region) {
> +				list_add_tail(&region->list, head);
> +				resv++;
> +			}
> +		}
> +	}
> +
> +	return (resv == its->its_count) ? resv : -ENODEV;
> +}
>  #else
>  static inline const struct iommu_ops *iort_fwspec_iommu_ops(
>  				struct iommu_fwspec *fwspec)
> @@ -789,6 +892,8 @@ static inline const struct iommu_ops *iort_fwspec_iommu_ops(
>  static inline int iort_add_device_replay(const struct iommu_ops *ops,
>  					 struct device *dev)
>  { return 0; }
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{ return 0; }
>  #endif
>  
>  static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 4039e64..d4cff12 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3450,7 +3450,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
>  		return -ENOMEM;
>  	}
>  
> -	err = iort_register_domain_token(its_entry->translation_id, dom_handle);
> +	err = iort_register_domain_token(its_entry->translation_id, res.start,
> +					 dom_handle);
>  	if (err) {
>  		pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
>  		       &res.start, its_entry->translation_id);
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 2f7a292..38cd77b 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -26,7 +26,8 @@
>  #define IORT_IRQ_MASK(irq)		(irq & 0xffffffffULL)
>  #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
>  
> -int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
> +int iort_register_domain_token(int trans_id, phys_addr_t base,
> +			       struct fwnode_handle *fw_node);
>  void iort_deregister_domain_token(int trans_id);
>  struct fwnode_handle *iort_find_domain_token(int trans_id);
>  #ifdef CONFIG_ACPI_IORT
> @@ -38,6 +39,7 @@
>  /* IOMMU interface */
>  void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
>  const struct iommu_ops *iort_iommu_configure(struct device *dev);
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
>  #else
>  static inline void acpi_iort_init(void) { }
>  static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> @@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
>  static inline const struct iommu_ops *iort_iommu_configure(
>  				      struct device *dev)
>  { return NULL; }
> +static inline
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{ return 0; }
>  #endif
>  
>  #endif /* __ACPI_IORT_H__ */
> -- 
> 1.9.1
> 
> 

^ permalink raw reply

* Re: [PATCH] arm64: dts: marvell: add NAND support on the 8040-DB board
From: Gregory CLEMENT @ 2017-12-15 10:24 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
	Thomas Petazzoni, Antoine Tenart, Nadav Haklai,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171106222823.3442-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Hi Miquel,
 
 On lun., nov. 06 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Add NAND support on the Armada-8040-DB by adding the same tree as for
> the Armada-7040-DB by using the same compatible string
> "marvell,armada-8k-nand".
>
> Do not enable the NAND node as enabling it (and changing manually the
> proper DPR-76 switch) would disable MDIO from CP1 (and thus disable CPS
> Ethernet PHY).
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>


Applied on mvebu/dt64

Thanks,

Gregory


> ---
>  arch/arm64/boot/dts/marvell/armada-8040-db.dts     | 28 ++++++++++++++++++++++
>  arch/arm64/boot/dts/marvell/armada-80x0.dtsi       | 17 +++++++++++++
>  .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi |  3 ++-
>  3 files changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> index 0d7b2ae46610..1c4b4e9137e8 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> @@ -216,6 +216,34 @@
>  	clock-frequency = <100000>;
>  };
>  
> +/*
> + * Proper NAND usage will require DPR-76 to be in position 1-2, which disables
> + * MDIO signal of CP1.
> + */
> +&cps_nand {
> +	num-cs = <1>;
> +	pinctrl-0 = <&nand_pins>, <&nand_rb>;
> +	pinctrl-names = "default";
> +	nand-ecc-strength = <4>;
> +	nand-ecc-step-size = <512>;
> +	marvell,nand-enable-arbiter;
> +	marvell,system-controller = <&cps_syscon0>;
> +	nand-on-flash-bbt;
> +
> +	partition@0 {
> +		label = "U-Boot";
> +		reg = <0 0x200000>;
> +	};
> +	partition@200000 {
> +		label = "Linux";
> +		reg = <0x200000 0xe00000>;
> +	};
> +	partition@1000000 {
> +		label = "Filesystem";
> +		reg = <0x1000000 0x3f000000>;
> +	};
> +};
> +
>  /* CON4 on CP1 expansion */
>  &cps_sata0 {
>  	status = "okay";
> diff --git a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
> index 666ebe96ba0d..b280ddd3c397 100644
> --- a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
> @@ -72,5 +72,22 @@
>  &cps_syscon0 {
>  	cps_pinctrl: pinctrl {
>  		compatible = "marvell,armada-8k-cps-pinctrl";
> +
> +		nand_pins: nand-pins {
> +			marvell,pins =
> +			"mpp0", "mpp1", "mpp2", "mpp3",
> +			"mpp4", "mpp5", "mpp6", "mpp7",
> +			"mpp8", "mpp9", "mpp10", "mpp11",
> +			"mpp15", "mpp16", "mpp17", "mpp18",
> +			"mpp19", "mpp20", "mpp21", "mpp22",
> +			"mpp23", "mpp24", "mpp25", "mpp26",
> +			"mpp27";
> +			marvell,function = "dev";
> +		};
> +
> +		nand_rb: nand-rb {
> +			marvell,pins = "mpp13", "mpp12";
> +			marvell,function = "nf";
> +		};
>  	};
>  };
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index b71ee6c83668..64663f3f4dfe 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -275,12 +275,13 @@
>  				 * this controller is only usable on the CPM
>  				 * for A7K and on the CPS for A8K.
>  				 */
> -				compatible = "marvell,armada370-nand";
> +				compatible = "marvell,armada-8k-nand";
>  				reg = <0x720000 0x54>;
>  				#address-cells = <1>;
>  				#size-cells = <1>;
>  				interrupts = <ICU_GRP_NSR 115 IRQ_TYPE_LEVEL_HIGH>;
>  				clocks = <&cps_clk 1 2>;
> +				marvell,system-controller = <&cpm_syscon0>;
>  				status = "disabled";
>  			};
>  
> -- 
> 2.11.0
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v5 01/16] dt-bindings: mtd: gpmc-onenand: Update properties description
From: Roger Quadros @ 2017-12-15 10:18 UTC (permalink / raw)
  To: Ladislav Michl, Boris Brezillon
  Cc: Rob Herring, Aaro Koskinen, Tony Lindgren, Peter Ujfalusi,
	Kyungmin Park, linux-mtd, linux-omap, devicetree
In-Reply-To: <20171130130907.GA16809@lenoch>

Ladislav,

On 30/11/17 15:09, Ladislav Michl wrote:
> On Thu, Nov 30, 2017 at 11:25:44AM +0100, Boris Brezillon wrote:
>> +Rob and the DT ML
>>
>> On Wed, 15 Nov 2017 17:24:58 +0100
>> Ladislav Michl <ladis@linux-mips.org> wrote:
>>
>>> Compatible property is required for OMAP2+ mtd driver. Also
>>> add INT pin gpio description and delete unused dma-channel
>>> property.
>>>
>>> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
>>> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>> ---
>>>
>>> Changes in v5:
>>> - renamed R/B pin to INT pin
>>>
>>> Changes in v4:
>>> - new patch
>>>
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>>  Documentation/devicetree/bindings/mtd/gpmc-onenand.txt | 6 ++++--
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>>> index b6e8bfd024f4..e9f01a963a0a 100644
>>> --- a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>>> +++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>>> @@ -9,13 +9,14 @@ Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>>>  
>>>  Required properties:
>>>  
>>> + - compatible:		"ti,omap2-onenand"
>>
>> Don't you break backward compat by adding this new requirement?
> 
> I was told it is okay in this case as OneNAND conversion to DT is unfinished.
> There was compat fixup code in earlier versions of patchset and it was dropped
> later. If others see it opposite way I can add it back.
> 

If it is possible not to break backward compatibility then we shouldn't.
Only if things are getting real messy because of the poor way the earlier DT
implementation was done we can consider it as an exception.

I thought we rely on GPMC timings entirely from the DT now and so things don't
work with older DT nodes?

>>>   - reg:			The CS line the peripheral is connected to
>>> - - gpmc,device-width	Width of the ONENAND device connected to the GPMC
>>> + - gpmc,device-width:	Width of the ONENAND device connected to the GPMC
>>>  			in bytes. Must be 1 or 2.
>>>  
>>>  Optional properties:
>>>  
>>> - - dma-channel:		DMA Channel index
>>> + - int-gpios:		GPIO specifier for the INT pin.
>>>  
>>>  For inline partition table parsing (optional):
>>>  
>>> @@ -35,6 +36,7 @@ Example for an OMAP3430 board:
>>>  		#size-cells = <1>;
>>>  
>>>  		onenand@0 {
>>> +			compatible = "ti,omap2-onenand";
>>>  			reg = <0 0 0>; /* CS0, offset 0 */
>>>  			gpmc,device-width = <2>;
>>>  

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH v4 2/4] ARM: PWM: add allwinner sun8i R40/V40/T3 pwm support.
From: Claudiu Beznea @ 2017-12-15  9:30 UTC (permalink / raw)
  To: hao_zhang, thierry.reding, robh+dt, mark.rutland, linux, wens,
	linus.walleij, maxime.ripard
  Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
	linux-pwm
In-Reply-To: <2d5b5421-1c1a-f293-e197-7a1a673ddbaa@microchip.com>



On 14.12.2017 12:44, Claudiu Beznea wrote:
> 
> 
> On 13.12.2017 16:44, hao_zhang wrote:
>> This patch add allwinner sun8i R40/V40/T3 pwm support.
>>
>> Signed-off-by: hao_zhang <hao5781286@gmail.com>
>> ---
>>  drivers/pwm/Kconfig         |  10 +
>>  drivers/pwm/Makefile        |   1 +
>>  drivers/pwm/pwm-sun8i-r40.c | 449 ++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 460 insertions(+)
>>  create mode 100644 drivers/pwm/pwm-sun8i-r40.c
>>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index 763ee50..cde5a70 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -444,6 +444,16 @@ config PWM_SUN4I
>>  	  To compile this driver as a module, choose M here: the module
>>  	  will be called pwm-sun4i.
>>  
>> +config PWM_SUN8I_R40
>> +	tristate "Allwinner PWM SUN8I R40 support"
>> +	depends on ARCH_SUNXI || COMPILE_TEST
>> +	depends on HAS_IOMEM && COMMON_CLK
>> +	help
>> +	  Generic PWM framework driver for Allwinner SoCs R40, V40, T3.
>> +
>> +	  To compile this driver as a module, choose M here: the module
>> +	  will be called pwm-sun8i-r40.
>> +
>>  config PWM_TEGRA
>>  	tristate "NVIDIA Tegra PWM support"
>>  	depends on ARCH_TEGRA
>> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
>> index 0258a74..026a55b 100644
>> --- a/drivers/pwm/Makefile
>> +++ b/drivers/pwm/Makefile
>> @@ -44,6 +44,7 @@ obj-$(CONFIG_PWM_STM32)		+= pwm-stm32.o
>>  obj-$(CONFIG_PWM_STM32_LP)	+= pwm-stm32-lp.o
>>  obj-$(CONFIG_PWM_STMPE)		+= pwm-stmpe.o
>>  obj-$(CONFIG_PWM_SUN4I)		+= pwm-sun4i.o
>> +obj-$(CONFIG_PWM_SUN8I_R40)	+= pwm-sun8i-r40.o
>>  obj-$(CONFIG_PWM_TEGRA)		+= pwm-tegra.o
>>  obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
>>  obj-$(CONFIG_PWM_TIEHRPWM)	+= pwm-tiehrpwm.o
>> diff --git a/drivers/pwm/pwm-sun8i-r40.c b/drivers/pwm/pwm-sun8i-r40.c
>> new file mode 100644
>> index 0000000..8df538d
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-sun8i-r40.c
>> @@ -0,0 +1,449 @@
>> +#include <linux/bitops.h>
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pwm.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/time.h>
>> +
>> +#define PWM_IRQ_ENABLE_REG	0x0000
>> +#define PCIE(ch)	BIT(ch)
>> +
>> +#define PWM_IRQ_STATUS_REG	0x0004
>> +#define PIS(ch)	BIT(ch)
>> +
>> +#define CAPTURE_IRQ_ENABLE_REG	0x0010
>> +#define CFIE(ch)	BIT(ch << 1 + 1)
>> +#define CRIE(ch)	BIT(ch << 1)
>> +
>> +#define CAPTURE_IRQ_STATUS_REG	0x0014
>> +#define CFIS(ch)	BIT(ch << 1 + 1)
>> +#define CRIS(ch)	BIT(ch << 1)
>> +
>> +#define CLK_CFG_REG(ch)	(0x0020 + (ch >> 1) * 4)
>> +#define CLK_SRC	BIT(7)
>> +#define CLK_SRC_BYPASS_SEC	BIT(6)
>> +#define CLK_SRC_BYPASS_FIR	BIT(5)
>> +#define CLK_GATING	BIT(4)
>> +#define CLK_DIV_M	GENMASK(3, 0)
>> +
>> +#define PWM_DZ_CTR_REG(ch)	(0x0030 + (ch >> 1) * 4)
>> +#define PWM_DZ_INTV	GENMASK(15, 8)
>> +#define PWM_DZ_EN	BIT(0)
>> +
>> +#define PWM_ENABLE_REG	0x0040
>> +#define PWM_EN(ch)	BIT(ch)
>> +
>> +#define CAPTURE_ENABLE_REG	0x0044
>> +#define CAP_EN(ch)	BIT(ch)
>> +
>> +#define PWM_CTR_REG(ch)	(0x0060 + ch * 0x20)
>> +#define PWM_PERIOD_RDY	BIT(11)
>> +#define PWM_PUL_START	BIT(10)
>> +#define PWM_MODE	BIT(9)
>> +#define PWM_ACT_STA	BIT(8)
>> +#define PWM_PRESCAL_K	GENMASK(7, 0)
>> +
>> +#define PWM_PERIOD_REG(ch)	(0x0064 + ch * 0x20)
>> +#define PWM_ENTIRE_CYCLE	GENMASK(31, 16)
>> +#define PWM_ACT_CYCLE	GENMASK(15, 0)
>> +
>> +#define PWM_CNT_REG(ch)	(0x0068 + ch * 0x20)
>> +#define PWM_CNT_VAL	GENMASK(15, 0)
>> +
>> +#define CAPTURE_CTR_REG(ch)	(0x006c + ch * 0x20)
>> +#define CAPTURE_CRLF	BIT(2)
>> +#define CAPTURE_CFLF	BIT(1)
>> +#define CAPINV	BIT(0)
>> +
>> +#define CAPTURE_RISE_REG(ch)	(0x0070 + ch * 0x20)
>> +#define CAPTURE_CRLR	GENMASK(15, 0)
>> +
>> +#define CAPTURE_FALL_REG(ch)	(0x0074 + ch * 0x20)
>> +#define CAPTURE_CFLR	GENMASK(15, 0)
>> +
>> +struct sunxi_pwm_data {
>> +	bool has_prescaler_bypass;
>> +	bool has_rdy;
>> +	unsigned int npwm;
>> +};
>> +
>> +struct sunxi_pwm_chip {
>> +	struct pwm_chip chip;
>> +	struct clk *clk;
>> +	void __iomem *base;
>> +	spinlock_t ctrl_lock;
>> +	const struct sunxi_pwm_data *data;
>> +};
>> +
>> +static const u16 div_m_table[] = {
>> +	1,
>> +	2,
>> +	4,
>> +	8,
>> +	16,
>> +	32,
>> +	64,
>> +	128,
>> +	256
>> +};
>> +
>> +static inline struct sunxi_pwm_chip *to_sunxi_pwm_chip(struct pwm_chip *chip)
>> +{
>> +	return container_of(chip, struct sunxi_pwm_chip, chip);
>> +}
>> +
>> +static inline u32 sunxi_pwm_readl(struct sunxi_pwm_chip *chip,
>> +		unsigned long offset)
>> +{
>> +	return readl(chip->base + offset);
>> +}
>> +
>> +static inline void sunxi_pwm_writel(struct sunxi_pwm_chip *chip,
>> +		u32 val, unsigned long offset)
>> +{
>> +	writel(val, chip->base + offset);
>> +}
>> +
>> +static void sunxi_pwm_set_bit(struct sunxi_pwm_chip *sunxi_pwm,
>> +		unsigned long reg, u32 bit)
>> +{
>> +	u32 val;
>> +
>> +	val = sunxi_pwm_readl(sunxi_pwm, reg);
>> +	val |= bit;
>> +	sunxi_pwm_writel(sunxi_pwm, val, reg);
>> +}
>> +
>> +static void sunxi_pwm_clear_bit(struct sunxi_pwm_chip *sunxi_pwm,
>> +		unsigned long reg, u32 bit)
>> +{
>> +	u32 val;
>> +
>> +	val = sunxi_pwm_readl(sunxi_pwm, reg);
>> +	val &= ~bit;
>> +	sunxi_pwm_writel(sunxi_pwm, val, reg);
>> +}
>> +
>> +static void sunxi_pwm_set_value(struct sunxi_pwm_chip *sunxi_pwm,
>> +		unsigned long reg, u32 mask, u32 val)
>> +{
>> +	u32 tmp;
>> +
>> +	tmp = sunxi_pwm_readl(sunxi_pwm, reg);
>> +	tmp &= ~mask;
>> +	tmp |= mask & val;
>> +	sunxi_pwm_writel(sunxi_pwm, tmp, reg);
>> +}
>> +
>> +static void sunxi_pwm_set_polarity(struct sunxi_pwm_chip *chip, u32 ch,
>> +		enum pwm_polarity polarity)
>> +{
>> +	if (polarity == PWM_POLARITY_NORMAL)
>> +		sunxi_pwm_set_bit(chip, PWM_CTR_REG(ch), PWM_ACT_STA);
>> +	else
>> +		sunxi_pwm_clear_bit(chip, PWM_CTR_REG(ch), PWM_ACT_STA);
>> +}
>> +
>> +static void sunxi_dump_reg(struct sunxi_pwm_chip *sunxi_pwm, u8 ch)
>> +{
>> +	dev_dbg(sunxi_pwm->chip.dev, "ch: %d\n"
>> +			"\tPWM_IRQ_ENABLE_REG(%04x): \t0x%08x\n"
>> +			"\tPWM_IRQ_STATUS_REG(%04x): \t0x%08x\n"
>> +			"\tCAPTURE_IRQ_ENABLE_REG(%04x): \t0x%08x\n"
>> +			"\tCAPTURE_IRQ_STATUS_REG(%04x): \t0x%08x\n"
>> +			"\tCLK_CFG_REG(%04x)(%d): \t0x%08x\n"
>> +			"\tPWM_DZ_CTR_REG(%04x)(%d): \t0x%08x\n"
>> +			"\tPWM_ENABLE_REG(%04x): \t0x%08x\n"
>> +			"\tCAPTURE_ENABLE_REG(%04x): \t0x%08x\n"
>> +			"\tPWM_CTR_REG(%04x)(%d): \t0x%08x\n"
>> +			"\tPWM_PERIOD_REG(%04x)(%d): \t0x%08x\n"
>> +			"\tPWM_CNT_REG(%04x)(%d): \t0x%08x\n"
>> +			"\tCAPTURE_CTR_REG(%04x)(%d): \t0x%08x\n"
>> +			"\tCAPTURE_RISE_REG(%04x)(%d): \t0x%08x\n"
>> +			"\tCAPTURE_FALL_REG(%04x)(%d): \t0x%08x\n",
>> +			ch,
>> +			PWM_IRQ_ENABLE_REG,
>> +			readl(sunxi_pwm->base + PWM_IRQ_ENABLE_REG),
>> +			PWM_IRQ_STATUS_REG,
>> +			readl(sunxi_pwm->base + PWM_IRQ_STATUS_REG),
>> +			CAPTURE_IRQ_ENABLE_REG,
>> +			readl(sunxi_pwm->base + CAPTURE_IRQ_ENABLE_REG),
>> +			CAPTURE_IRQ_STATUS_REG,
>> +			readl(sunxi_pwm->base + CAPTURE_IRQ_STATUS_REG),
>> +			CLK_CFG_REG(ch),
>> +			ch, readl(sunxi_pwm->base + CLK_CFG_REG(ch)),
>> +			PWM_DZ_CTR_REG(ch),
>> +			ch, readl(sunxi_pwm->base + PWM_DZ_CTR_REG(ch)),
>> +			PWM_ENABLE_REG,
>> +			readl(sunxi_pwm->base + PWM_ENABLE_REG),
>> +			CAPTURE_ENABLE_REG,
>> +			readl(sunxi_pwm->base + CAPTURE_ENABLE_REG),
>> +			PWM_CTR_REG(ch),
>> +			ch, readl(sunxi_pwm->base + PWM_CTR_REG(ch)),
>> +			PWM_PERIOD_REG(ch),
>> +			ch, readl(sunxi_pwm->base + PWM_PERIOD_REG(ch)),
>> +			PWM_CNT_REG(ch),
>> +			ch, readl(sunxi_pwm->base + PWM_CNT_REG(ch)),
>> +			CAPTURE_CTR_REG(ch),
>> +			ch, readl(sunxi_pwm->base + CAPTURE_CTR_REG(ch)),
>> +			CAPTURE_RISE_REG(ch),
>> +			ch, readl(sunxi_pwm->base + CAPTURE_RISE_REG(ch)),
>> +			CAPTURE_FALL_REG(ch),
>> +			ch, readl(sunxi_pwm->base + CAPTURE_FALL_REG(ch)));
>> +}
>> +
>> +static int sunxi_pwm_config(struct sunxi_pwm_chip *sunxi_pwm, u8 ch,
>> +		struct pwm_state *state)
>> +{
>> +	u64 clk_rate, clk_div, val;
>> +	u16 prescaler = 0;
>> +	u8 id = 0;
>> +
>> +	clk_rate = clk_get_rate(sunxi_pwm->clk);
>> +	dev_dbg(sunxi_pwm->chip.dev, "clock rate:%lld\n", clk_rate);
>> +
>> +	if (clk_rate == 24000000)
>> +		sunxi_pwm_clear_bit(sunxi_pwm, CLK_CFG_REG(ch), CLK_SRC);
>> +	else
>> +		sunxi_pwm_set_bit(sunxi_pwm, CLK_CFG_REG(ch), CLK_SRC);
>> +
>> +	if (sunxi_pwm->data->has_prescaler_bypass) {
>> +		/* pwm output bypass */
>> +		if (ch % 2)
>> +			sunxi_pwm_set_bit(sunxi_pwm, CLK_CFG_REG(ch),
>> +					CLK_SRC_BYPASS_FIR);
>> +		else
>> +			sunxi_pwm_set_bit(sunxi_pwm, CLK_CFG_REG(ch),
>> +					CLK_SRC_BYPASS_SEC);
>> +		return 0;
>> +	}
>> +
>> +	val = state->period * clk_rate;
>> +	do_div(val, NSEC_PER_SEC);
>> +	if (val < 1) {
>> +		dev_err(sunxi_pwm->chip.dev,
>> +				"period expects a larger value\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	/* calculate and set prescalar, div table, pwn entrie cycle */
>> +	clk_div = val;
>> +
>> +	while (clk_div > 65535) {
>> +		prescaler++;
>> +		clk_div = val;
>> +		do_div(clk_div, prescaler + 1);
>> +		do_div(clk_div, div_m_table[id]);
>> +
>> +		if (prescaler == 255) {
>> +			prescaler = 0;
>> +			id++;
>> +			if (id == 9)
>> +				return -EINVAL;
>> +		}
>> +	}
>> +
>> +	sunxi_pwm_set_value(sunxi_pwm, PWM_PERIOD_REG(ch),
>> +			PWM_ENTIRE_CYCLE, clk_div << 16);
>> +	sunxi_pwm_set_value(sunxi_pwm, PWM_CTR_REG(ch),
>> +			PWM_PRESCAL_K, prescaler << 0);
>> +	sunxi_pwm_set_value(sunxi_pwm, CLK_CFG_REG(ch),
>> +			CLK_DIV_M, id << 0);
>> +
>> +	/* set duty cycle */
>> +	val = (prescaler + 1) * div_m_table[id] * clk_div;
>> +	val = state->period;
>> +	do_div(val, clk_div);
>> +	clk_div = state->duty_cycle;
>> +	do_div(clk_div, val);
>> +
>> +	sunxi_pwm_set_value(sunxi_pwm, PWM_PERIOD_REG(ch),
>> +			PWM_ACT_CYCLE, clk_div << 0);
>> +
>> +	return 0;
>> +}
>> +
>> +static int sunxi_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>> +		struct pwm_state *state)
>> +{
>> +	int ret;
>> +	struct sunxi_pwm_chip *sunxi_pwm = to_sunxi_pwm_chip(chip);
>> +	struct pwm_state cstate;
>> +
>> +	sunxi_dump_reg(sunxi_pwm, pwm->hwpwm);
>> +	pwm_get_state(pwm, &cstate);
>> +	if (!cstate.enabled) {
>> +		ret = clk_prepare_enable(sunxi_pwm->clk);
>> +		if (ret) {
>> +			dev_err(chip->dev, "failed to enable PWM clock\n");
>> +			return ret;
>> +		}
>> +	}
>> +
>> +	spin_lock(&sunxi_pwm->ctrl_lock);
>> +
>> +	if (state->polarity != cstate.polarity)
>> +		sunxi_pwm_set_polarity(sunxi_pwm, pwm->hwpwm, state->polarity);
>> +
>> +	if ((cstate.period != state->period) ||
>> +			(cstate.duty_cycle != state->duty_cycle)) {
>> +		ret = sunxi_pwm_config(sunxi_pwm, pwm->hwpwm, state);
>> +		if (ret) {
>> +			dev_err(chip->dev, "failed to enable PWM clock\n");
>> +			return ret;
> Here you might want to undo the previous polarity and do clk_disable_unprepare(),
> if any, in order to not reach inconsistency b/w software state of PWM and hardware
> state. Also, unlock the spinlock.
>> +		}
>> +	}
>> +
>> +	if (state->enabled) {
>> +		sunxi_pwm_set_bit(sunxi_pwm,
>> +				CLK_CFG_REG(pwm->hwpwm), CLK_GATING);
>> +
>> +		sunxi_pwm_set_bit(sunxi_pwm,
>> +				PWM_ENABLE_REG, PWM_EN(pwm->hwpwm));
>> +	} else {
>> +		sunxi_pwm_clear_bit(sunxi_pwm,
>> +				CLK_CFG_REG(pwm->hwpwm), CLK_GATING);
>> +
>> +		sunxi_pwm_clear_bit(sunxi_pwm,
>> +				PWM_ENABLE_REG, PWM_EN(pwm->hwpwm));
>> +	}
>> +
>> +	spin_unlock(&sunxi_pwm->ctrl_lock);
>> +	sunxi_dump_reg(sunxi_pwm, pwm->hwpwm);
>> +
>> +	return 0;
>> +}
>> +
>> +static void sunxi_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
>> +		struct pwm_state *state)
>> +{
>> +	struct sunxi_pwm_chip *sunxi_pwm = to_sunxi_pwm_chip(chip);
>> +	u64 clk_rate, tmp;
>> +	u32 val;
>> +	u16 clk_div, act_cycle;
>> +	u8 prescal, id;
>> +
>> +	clk_rate = clk_get_rate(sunxi_pwm->clk);
>> +
>> +	val = sunxi_pwm_readl(sunxi_pwm, PWM_CTR_REG(pwm->hwpwm));
>> +	if (PWM_ACT_STA & val)
>> +		state->polarity = PWM_POLARITY_NORMAL;
>> +	else
>> +		state->polarity = PWM_POLARITY_INVERSED;
>> +
>> +	prescal = PWM_PRESCAL_K & val;
>> +
>> +	val = sunxi_pwm_readl(sunxi_pwm, PWM_ENABLE_REG);
>> +	if (PWM_EN(pwm->hwpwm) & val)
>> +		state->enabled = true;
>> +	else
>> +		state->enabled = false;
>> +
>> +	val = sunxi_pwm_readl(sunxi_pwm, PWM_PERIOD_REG(pwm->hwpwm));
>> +	act_cycle = PWM_ACT_CYCLE & val;
>> +	clk_div = val >> 16;
>> +
>> +	val = sunxi_pwm_readl(sunxi_pwm, CLK_CFG_REG(pwm->hwpwm));
>> +	id = CLK_DIV_M & val;
>> +
>> +	tmp = act_cycle * prescal * div_m_table[id] * NSEC_PER_SEC;
>> +	state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
>> +	tmp = clk_div * prescal * div_m_table[id] * NSEC_PER_SEC;
>> +	state->period = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
>> +}
>> +
>> +static const struct pwm_ops sunxi_pwm_ops = {
>> +	.apply = sunxi_pwm_apply,
>> +	.get_state = sunxi_pwm_get_state,
>> +	.owner = THIS_MODULE,
>> +};
>> +
>> +static const struct sunxi_pwm_data sunxi_pwm_data_r40 = {
>> +	.has_prescaler_bypass = false,
>> +	.has_rdy = true,
>> +	.npwm = 8,
>> +};
>> +
>> +static const struct of_device_id sunxi_pwm_dt_ids[] = {
>> +	{
>> +		.compatible = "allwinner,sun8i-r40-pwm",
>> +		.data = &sunxi_pwm_data_r40,
>> +	},
>> +	{},
>> +};
>> +MODULE_DEVICE_TABLE(of, sunxi_pwm_dt_ids);
>> +
>> +static int sunxi_pwm_probe(struct platform_device *pdev)
>> +{
>> +	struct sunxi_pwm_chip *pwm;
>> +	struct resource *res;
>> +	int ret;
>> +	const struct of_device_id *match;
>> +
>> +	match = of_match_device(sunxi_pwm_dt_ids, &pdev->dev);
>> +
>> +	pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
>> +	if (!pwm)
>> +		return -ENOMEM;
>> +
>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> check for res == NULL
My bad here, no need to check res == NULL since devm_ioremap_resource() will take
care of this case.

Thanks,
Claudiu
>> +	pwm->base = devm_ioremap_resource(&pdev->dev, res);
>> +	if (IS_ERR(pwm->base))
>> +		return PTR_ERR(pwm->base);
>> +
>> +	pwm->clk = devm_clk_get(&pdev->dev, NULL);
>> +	if (IS_ERR(pwm->clk))
>> +		return PTR_ERR(pwm->clk);
>> +
>> +	pwm->data = match->data;
>> +	pwm->chip.dev = &pdev->dev;
>> +	pwm->chip.ops = &sunxi_pwm_ops;
>> +	pwm->chip.base = -1;
>> +	pwm->chip.npwm = pwm->data->npwm;
>> +	pwm->chip.of_xlate = of_pwm_xlate_with_flags;
>> +	pwm->chip.of_pwm_n_cells = 3;
>> +
>> +	dev_dbg(pwm->chip.dev, "npwm: %d\n", pwm->chip.npwm);
>> +
>> +	spin_lock_init(&pwm->ctrl_lock);
>> +
>> +	ret = pwmchip_add(&pwm->chip);
>> +	if (ret < 0) {
>> +		dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	platform_set_drvdata(pdev, pwm);
>> +
>> +	return 0;
>> +}
>> +
>> +static int sunxi_pwm_remove(struct platform_device *pdev)
>> +{
>> +	struct sunxi_pwm_chip *pwm = platform_get_drvdata(pdev);
>> +
>> +	return pwmchip_remove(&pwm->chip);
>> +}
>> +
>> +static struct platform_driver sunxi_pwm_driver = {
>> +	.driver = {
>> +		.name = "sun8i-r40-pwm",
>> +		.of_match_table = sunxi_pwm_dt_ids,
>> +	},
>> +	.probe = sunxi_pwm_probe,
>> +	.remove = sunxi_pwm_remove,
>> +};
>> +module_platform_driver(sunxi_pwm_driver);
>> +
>> +MODULE_ALIAS("platform:sun8i-r40-pwm");
>> +MODULE_AUTHOR("Hao Zhang <hao5781286@gmail.com>");
>> +MODULE_DESCRIPTION("Allwinner sun8i-r40 PWM driver");
>> +MODULE_LICENSE("GPL v2");
>>

^ permalink raw reply

* Re: [PATCH v4 4/6] dt: bindings: lp8860: Add trigger binding to the lp8860
From: Pavel Machek @ 2017-12-15  9:09 UTC (permalink / raw)
  To: Dan Murphy
  Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
	jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-leds-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171212220143.31210-5-dmurphy-l0cyMroinI0@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

Hi!

> @@ -35,6 +37,7 @@ led-controller@2d {
>  	led@0 {
>  		reg = <0>;
>  		label = "white:display_cluster";
> +		linux,default-trigger = "backlight";
>  	};
>  }

What is "display_cluster"? Is it display backlight?

Could we use ":backlight" and perhaps start documentation file listing
"common" LED descriptions so they are shared across machines?

For the record, I'd prefer this to be
"/sys/class/leds/display:white:backlight" in the end... so that we
have nice naming for userspace, consistent between different machines.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply

* Re: [PATCH] arm: dts: Remove leading 0x and 0s from bindings notation
From: Krzysztof Kozlowski @ 2017-12-15  8:59 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: Rob Herring, Benoît Cousson, Tony Lindgren, Mark Rutland,
	Russell King, Jesper Nilsson, Lars Persson, Niklas Cassel,
	Nicolas Ferre, Alexandre Belloni, Ray Jui, Scott Branden,
	Jon Mason, bcm-kernel-feedback-list, Florian Fainelli,
	Sekhar Nori, Kevin Hilman, Kukjin Kim, Shawn Guo
In-Reply-To: <20171214165350.27850-1-malat@debian.org>

On Thu, Dec 14, 2017 at 5:53 PM, Mathieu Malaterre <malat@debian.org> wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
>  arch/arm/boot/dts/am3517.dtsi                 |  4 +--
>  arch/arm/boot/dts/arm-realview-eb.dtsi        | 18 +++++++-------
>  arch/arm/boot/dts/arm-realview-pb1176.dts     | 18 +++++++-------
>  arch/arm/boot/dts/arm-realview-pb11mp.dts     | 18 +++++++-------
>  arch/arm/boot/dts/arm-realview-pbx.dtsi       | 18 +++++++-------
>  arch/arm/boot/dts/artpec6.dtsi                |  2 +-
>  arch/arm/boot/dts/at91sam9261.dtsi            |  2 +-
>  arch/arm/boot/dts/at91sam9261ek.dts           |  2 +-
>  arch/arm/boot/dts/at91sam9263.dtsi            |  2 +-
>  arch/arm/boot/dts/at91sam9263ek.dts           |  2 +-
>  arch/arm/boot/dts/at91sam9g25ek.dts           |  2 +-
>  arch/arm/boot/dts/at91sam9g45.dtsi            |  2 +-
>  arch/arm/boot/dts/at91sam9m10g45ek.dts        |  2 +-
>  arch/arm/boot/dts/atlas7.dtsi                 | 12 ++++-----
>  arch/arm/boot/dts/bcm11351.dtsi               |  2 +-
>  arch/arm/boot/dts/bcm21664.dtsi               |  2 +-
>  arch/arm/boot/dts/bcm283x.dtsi                |  2 +-
>  arch/arm/boot/dts/da850-lcdk.dts              |  4 +--
>  arch/arm/boot/dts/dm8148-evm.dts              |  8 +++---
>  arch/arm/boot/dts/dm8168-evm.dts              |  8 +++---
>  arch/arm/boot/dts/dra62x-j5eco-evm.dts        |  8 +++---
>  arch/arm/boot/dts/exynos5420.dtsi             | 36 +++++++++++++--------------
>  arch/arm/boot/dts/exynos5422-odroid-core.dtsi |  2 +-
>  arch/arm/boot/dts/imx7d.dtsi                  |  2 +-
>  arch/arm/boot/dts/keystone-k2e-netcp.dtsi     |  2 +-
>  arch/arm/boot/dts/keystone-k2hk-netcp.dtsi    |  2 +-
>  arch/arm/boot/dts/keystone-k2l-netcp.dtsi     |  2 +-
>  arch/arm/boot/dts/omap3-cm-t3x.dtsi           |  8 +++---
>  arch/arm/boot/dts/omap3-evm-37xx.dts          |  8 +++---
>  arch/arm/boot/dts/omap3-lilly-a83x.dtsi       |  8 +++---
>  arch/arm/boot/dts/s3c2416.dtsi                |  2 +-

For Exynos and S3C:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses
From: Baruch Siach @ 2017-12-15  8:56 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Catalin Marinas, Will Deacon, linux-pm, devicetree,
	linux-arm-kernel, Thomas Petazzoni, Antoine Tenart, Nadav Haklai,
	David Sniatkiwicz
In-Reply-To: <20171214103011.24713-5-miquel.raynal@free-electrons.com>

Hi Miquèl,

On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
> 
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
>  drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
>  1 file changed, 55 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 26698f2d3ca7..e5b184cee79b 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -39,12 +39,21 @@
>  #define A375_HW_RESETn			BIT(8)
>  #define A380_HW_RESET			BIT(8)
>  
> +/* Legacy bindings */
> +#define LEGACY_CONTROL_MEM_LEN		0x4
> +
> +/* Current bindings with the 2 control registers under the same memory area */
> +#define LEGACY_CONTROL1_OFFSET		0x0
> +#define CONTROL0_OFFSET			0x0
> +#define CONTROL1_OFFSET			0x4
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
>  struct armada_thermal_priv {
> -	void __iomem *sensor;
> -	void __iomem *control;
> +	void __iomem *status;
> +	void __iomem *control0;
> +	void __iomem *control1;

The 'status' -> 'sensor' rename is not mentioned in the commit log. I'd say it 
is a matter for a separate patch.

Otherwise, good cleanup.

baruch

>  	struct armada_thermal_data *data;
>  };
>  
> @@ -71,45 +80,45 @@ struct armada_thermal_data {
>  static void armadaxp_init_sensor(struct platform_device *pdev,
>  				 struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reset the sensor */
> -	reg = readl_relaxed(priv->control);
> -	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> +	reg = readl_relaxed(priv->control1);
> +	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
>  
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Enable the sensor */
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg &= ~PMU_TM_DISABLE_MASK;
> -	writel(reg, priv->sensor);
> +	writel(reg, priv->status);
>  }
>  
>  static void armada370_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	reg &= ~PMU_TDC0_START_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	msleep(10);
>  }
> @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
>  static void armada375_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl(priv->control + 4);
> +	reg = readl(priv->control1);
>  	reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
>  	reg &= ~A375_READOUT_INVERT;
>  	reg &= ~A375_HW_RESETn;
>  
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(20);
>  
>  	reg |= A375_HW_RESETn;
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(50);
>  }
>  
>  static void armada380_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->control);
> +	u32 reg = readl_relaxed(priv->control1);
>  
>  	/* Reset hardware once */
>  	if (!(reg & A380_HW_RESET)) {
>  		reg |= A380_HW_RESET;
> -		writel(reg, priv->control);
> +		writel(reg, priv->control1);
>  		msleep(10);
>  	}
>  }
>  
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->sensor);
> +	u32 reg = readl_relaxed(priv->status);
>  
>  	return reg & priv->data->is_valid_bit;
>  }
> @@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  			  int *temp)
>  {
>  	struct armada_thermal_priv *priv = thermal->devdata;
> -	unsigned long reg;
> +	u32 reg;
>  	unsigned long m, b, div;
>  
>  	/* Valid check */
> @@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  		return -EIO;
>  	}
>  
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
>  
>  	/* Get formula coeficients */
> @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
>  
>  static int armada_thermal_probe(struct platform_device *pdev)
>  {
> +	void __iomem *control = NULL;
>  	struct thermal_zone_device *thermal;
>  	const struct of_device_id *match;
>  	struct armada_thermal_priv *priv;
> @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->sensor))
> -		return PTR_ERR(priv->sensor);
> +	priv->status = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->status))
> +		return PTR_ERR(priv->status);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -	priv->control = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->control))
> -		return PTR_ERR(priv->control);
> +	control = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(control))
> +		return PTR_ERR(control);
> +
> +	/*
> +	 * Legacy DT bindings only described "control1" register (also referred
> +	 * as "control MSB" on old documentation). New bindings cover
> +	 * "control0/control LSB" and "control1/control MSB" registers within
> +	 * the same resource, which is then of size 8 instead of 4.
> +	 */
> +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> +		/* ->control0 unavailable in this configuration */
> +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> +	} else {
> +		priv->control0 = control + CONTROL0_OFFSET;
> +		priv->control1 = control + CONTROL1_OFFSET;
> +	}
>  
>  	priv->data = (struct armada_thermal_data *)match->data;
>  	priv->data->init_sensor(pdev, priv);

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

^ permalink raw reply

* Re: [PATCH] arm: dts: Remove leading 0x and 0s from bindings notation
From: Jesper Nilsson @ 2017-12-15  8:50 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: Rob Herring, Benoît Cousson, Tony Lindgren, Mark Rutland,
	Russell King, Jesper Nilsson, Lars Persson, Niklas Cassel,
	Nicolas Ferre, Alexandre Belloni, Ray Jui, Scott Branden,
	Jon Mason, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	Florian Fainelli, Sekhar Nori, Kevin Hilman, Kukjin Kim,
	Krzysztof Kozlowski
In-Reply-To: <20171214165350.27850-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>

On Thu, Dec 14, 2017 at 05:53:48PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
> 
> and
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
> 
> Converted using the following command:
> 
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} +
> 
> For simplicity, two sed expressions were used to solve each warnings separately.
> 
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
> 
> https://elinux.org/Device_Tree_Linux#Linux_conventions
> 
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
> 
> Reported-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Suggested-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
> ---
>  arch/arm/boot/dts/artpec6.dtsi                |  2 +-

Acked-by: Jesper Nilsson <jesper.nilsson-VrBV9hrLPhE@public.gmane.org>

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson-VrBV9hrLPhE@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Gregory CLEMENT @ 2017-12-15  8:44 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Baruch Siach, Mark Rutland, Andrew Lunn, Jason Cooper,
	Nadav Haklai, linux-pm-u79uwXL29TY76Z2rM5mHXA, Catalin Marinas,
	Antoine Tenart, Will Deacon, David Sniatkiwicz, Eduardo Valentin,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Zhang Rui,
	Thomas Petazzoni,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Sebastian Hesselbarth
In-Reply-To: <20171215093203.74b7a59c@xps13>

Hi Miquel,
 
 On ven., déc. 15 2017, Miquel RAYNAL <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hello Baruch,
>
> On Fri, 15 Dec 2017 10:27:59 +0200
> Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
>
>> Hi Miquel
>> 
>> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
>> > +- marvell,thermal-zone-name: The name to identify the thermal zone
>> > +                             within the sysfs, useful when multiple
>> > +                             thermal zones are registered (AP,
>> > CPx...).  
>> 
>> I don't think that would be acceptable. DT is about describing the
>> hardware. sysfs is a Linux implementation detail which is not tied to
>> any specific hardware. If this is accepted, the property should be
>> named 'linux,thermal-zone-name'.
>
> You are right the sysfs mention should not appear in the description.
>
> Otherwise for the naming I'm not sure "linux," is a valid prefix in
> that case.

Actually the choice between linux or marvell make me realize that there
is something wrong. Having a name associated to a device is something
pretty usual with the device tree, however it is as the class device
level, such as clock-names, line-name, or regulator-name. So in my
opinion if we want to support naming from device tree it would be done
for all the thermal device not just for the Marvell one.

However I don't think we need it. For example for the clocks we created
the name dynamically using of the base address of the register to keep
them unique.

Gregory


>
> Miquèl
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Baruch Siach @ 2017-12-15  8:44 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171215093203.74b7a59c@xps13>

HI Miquèl

On Fri, Dec 15, 2017 at 09:32:03AM +0100, Miquel RAYNAL wrote:
> On Fri, 15 Dec 2017 10:27:59 +0200
> Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > 
> > On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > > +- marvell,thermal-zone-name: The name to identify the thermal zone
> > > +                             within the sysfs, useful when multiple
> > > +                             thermal zones are registered (AP,
> > > CPx...).  
> > 
> > I don't think that would be acceptable. DT is about describing the
> > hardware. sysfs is a Linux implementation detail which is not tied to
> > any specific hardware. If this is accepted, the property should be
> > named 'linux,thermal-zone-name'.
> 
> You are right the sysfs mention should not appear in the description.

My comment was not about the description language. I don't think that this 
property is acceptable at all. But I'll let DT maintainers comment on that.

> Otherwise for the naming I'm not sure "linux," is a valid prefix in
> that case.

We use the 'linux' prefix for input key names and led triggers, for example.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 1/5] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Chanwoo Choi @ 2017-12-15  8:33 UTC (permalink / raw)
  To: Lee Jones
  Cc: Enric Balletbo i Serra, MyungJoo Ham, Rob Herring, Heiko Stuebner,
	groeck-F7+t8E8rja9g9hUCZPvPmw, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Benson Leung
In-Reply-To: <5A3385D0.2050308-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

On 2017년 12월 15일 17:20, Chanwoo Choi wrote:
> On 2017년 12월 15일 17:14, Lee Jones wrote:
>>> On 2017년 12월 13일 19:32, Enric Balletbo i Serra wrote:
>>>> From: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>>
>>>> Extend the driver to notify host and device type cables and the presence
>>>> of power.
>>>>
>>>> Signed-off-by: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>>>> Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>> ---
>>>> Changes since v1:
>>>>  - Use the BIT macro. Requested by Lee Jones.
>>>>  - Add the Reviewed-by: Chanwoo Choi.
>>>>
>>>>  drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
>>>>  include/linux/mfd/cros_ec_commands.h |  17 +++++
>>>>  2 files changed, 155 insertions(+), 4 deletions(-)
>>
>>> Looks good to me. After reviewing the Lee Jones,
>>> I'll take it on next branch.
>>
>> If you take it, you need to send me a pull-request to an immutable
>> branch.
>>
>> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>
> 
> Sure. I'll send the immutable branch. Thanks.
> 

Dear Lee,

I make the immutable branch (ib-extcon-mfd-4.16)
and send the following pull request.

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git ib-extcon-mfd-4.16

for you to fetch changes up to c7eb47f9e45226571be31212f6efd4b307d3b59d:

  extcon: usbc-cros-ec: add support to notify USB type cables. (2017-12-15 17:21:49 +0900)

----------------------------------------------------------------
Benson Leung (1):
      extcon: usbc-cros-ec: add support to notify USB type cables.

 drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
 include/linux/mfd/cros_ec_commands.h |  17 +++++
 2 files changed, 155 insertions(+), 4 deletions(-)


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit
From: Baruch Siach @ 2017-12-15  8:33 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171214103011.24713-4-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Hi Miquel,

On Thu, Dec 14, 2017 at 11:30:03AM +0100, Miquel Raynal wrote:
> All Armada SoCs use one bit to declare if the sensor values are valid.
> This bit moves across the versions of the IP.
> 
> The method until then was to do both a shift and compare with an useless
> flag of "0x1". It is clearer and quicker to directly save the value that
> must be ANDed instead of the bit position and do a single bitwise AND
> operation.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>  drivers/thermal/armada_thermal.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 6c4af2622d4f..26698f2d3ca7 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -24,8 +24,6 @@
>  #include <linux/of_device.h>
>  #include <linux/thermal.h>
>  
> -#define THERMAL_VALID_MASK		0x1
> -
>  /* Thermal Manager Control and Status Register */
>  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
>  #define PMU_TM_DISABLE_OFFS		0
> @@ -67,7 +65,7 @@ struct armada_thermal_data {
>  	/* Register shift and mask to access the sensor temperature */
>  	unsigned int temp_shift;
>  	unsigned int temp_mask;
> -	unsigned int is_valid_shift;
> +	unsigned int is_valid_bit;

Type should be u32 now, I think.

>  };
>  
>  static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
>  	unsigned long reg = readl_relaxed(priv->sensor);

u32 here also, I think. But that's unrelated to this patch.

> -	return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
> +	return reg & priv->data->is_valid_bit;
>  }
>  
>  static int armada_get_temp(struct thermal_zone_device *thermal,
> @@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
>  static const struct armada_thermal_data armada370_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada370_init_sensor,
> -	.is_valid_shift = 9,
> +	.is_valid_bit = BIT(9),
>  	.temp_shift = 10,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3153000000UL,
> @@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
>  static const struct armada_thermal_data armada375_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada375_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3171900000UL,
> @@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
>  static const struct armada_thermal_data armada380_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada380_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x3ff,
>  	.coef_b = 1172499100UL,

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-15  8:32 UTC (permalink / raw)
  To: Baruch Siach
  Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171215082759.7t24ka3lpkulcb7r@tarshish>

Hello Baruch,

On Fri, 15 Dec 2017 10:27:59 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:

> Hi Miquel
> 
> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > +- marvell,thermal-zone-name: The name to identify the thermal zone
> > +                             within the sysfs, useful when multiple
> > +                             thermal zones are registered (AP,
> > CPx...).  
> 
> I don't think that would be acceptable. DT is about describing the
> hardware. sysfs is a Linux implementation detail which is not tied to
> any specific hardware. If this is accepted, the property should be
> named 'linux,thermal-zone-name'.

You are right the sysfs mention should not appear in the description.

Otherwise for the naming I'm not sure "linux," is a valid prefix in
that case.

Miquèl

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Baruch Siach @ 2017-12-15  8:27 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171214103011.24713-2-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Hi Miquel

On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> +- marvell,thermal-zone-name: The name to identify the thermal zone
> +                             within the sysfs, useful when multiple
> +                             thermal zones are registered (AP, CPx...).

I don't think that would be acceptable. DT is about describing the hardware. 
sysfs is a Linux implementation detail which is not tied to any specific 
hardware. If this is accepted, the property should be named 
'linux,thermal-zone-name'.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 1/5] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Chanwoo Choi @ 2017-12-15  8:20 UTC (permalink / raw)
  To: Lee Jones
  Cc: Enric Balletbo i Serra, MyungJoo Ham, Rob Herring, Heiko Stuebner,
	groeck-F7+t8E8rja9g9hUCZPvPmw, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Benson Leung
In-Reply-To: <20171215081453.6jwjdetwe655imqo@dell>

On 2017년 12월 15일 17:14, Lee Jones wrote:
>> On 2017년 12월 13일 19:32, Enric Balletbo i Serra wrote:
>>> From: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>
>>> Extend the driver to notify host and device type cables and the presence
>>> of power.
>>>
>>> Signed-off-by: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>>> Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> ---
>>> Changes since v1:
>>>  - Use the BIT macro. Requested by Lee Jones.
>>>  - Add the Reviewed-by: Chanwoo Choi.
>>>
>>>  drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
>>>  include/linux/mfd/cros_ec_commands.h |  17 +++++
>>>  2 files changed, 155 insertions(+), 4 deletions(-)
> 
>> Looks good to me. After reviewing the Lee Jones,
>> I'll take it on next branch.
> 
> If you take it, you need to send me a pull-request to an immutable
> branch.
> 
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> 

Sure. I'll send the immutable branch. Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 1/5] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Lee Jones @ 2017-12-15  8:14 UTC (permalink / raw)
  To: Chanwoo Choi
  Cc: Enric Balletbo i Serra, MyungJoo Ham, Rob Herring, Heiko Stuebner,
	groeck, devicetree, linux-arm-kernel, linux-rockchip,
	linux-kernel, Benson Leung
In-Reply-To: <5A33702D.60004@samsung.com>

> On 2017년 12월 13일 19:32, Enric Balletbo i Serra wrote:
> > From: Benson Leung <bleung@chromium.org>
> > 
> > Extend the driver to notify host and device type cables and the presence
> > of power.
> > 
> > Signed-off-by: Benson Leung <bleung@chromium.org>
> > Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > ---
> > Changes since v1:
> >  - Use the BIT macro. Requested by Lee Jones.
> >  - Add the Reviewed-by: Chanwoo Choi.
> > 
> >  drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
> >  include/linux/mfd/cros_ec_commands.h |  17 +++++
> >  2 files changed, 155 insertions(+), 4 deletions(-)

> Looks good to me. After reviewing the Lee Jones,
> I'll take it on next branch.

If you take it, you need to send me a pull-request to an immutable
branch.

Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [PATCH net-next v6 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
From: Kunihiko Hayashi @ 2017-12-15  8:03 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: David Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Andrew Lunn,
	Rob Herring, Mark Rutland,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Masahiro Yamada,
	Masami Hiramatsu, Jassi Brar
In-Reply-To: <7749e13a-56ef-0d43-1a41-dbd457227575-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hello Florian,

On Thu, 14 Dec 2017 15:24:17 -0800 <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> 
> On 12/14/2017 02:05 AM, Kunihiko Hayashi wrote:
> > DT bindings for the AVE ethernet controller found on Socionext's
> > UniPhier platforms.
> > 
> > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> > Signed-off-by: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > ---
> >  .../bindings/net/socionext,uniphier-ave4.txt       | 48 ++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> > new file mode 100644
> > index 0000000..4700377
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> > @@ -0,0 +1,48 @@
> > +* Socionext AVE ethernet controller
> > +
> > +This describes the devicetree bindings for AVE ethernet controller
> > +implemented on Socionext UniPhier SoCs.
> > +
> > +Required properties:
> > + - compatible: Should be
> > +	- "socionext,uniphier-pro4-ave4" : for Pro4 SoC
> > +	- "socionext,uniphier-pxs2-ave4" : for PXs2 SoC
> > +	- "socionext,uniphier-ld11-ave4" : for LD11 SoC
> > +	- "socionext,uniphier-ld20-ave4" : for LD20 SoC
> > + - reg: Address where registers are mapped and size of region.
> > + - interrupts: Should contain the MAC interrupt.
> > + - phy-mode: See ethernet.txt in the same directory. Allow to choose
> > +	"rgmii", "rmii", or "mii" according to the PHY.
> > + - phy-handle: Should point to the external phy device.
> > +	See ethernet.txt file in the same directory.
> > + - clocks: A phandle to the clock for the MAC.
> > +
> > +Optional properties:
> > + - resets: A phandle to the reset control for the MAC
> > + - local-mac-address: See ethernet.txt in the same directory.
> > +
> > +Required subnode:
> > + - mdio: Device tree subnode with the following required properties:
> > +	- #address-cells: Must be <1>.
> > +	- #size-cells: Must be <0>.
> > +	- reg: phy ID number, usually a small integer.
> 
> Almost, the "reg" property applies to the MDIO child nodes: the Ethernet
> PHYs/MDIO devices. For the MDIO controller itself, the "reg" property,
> if specified, would be relative to the Ethernet controller's base
> register address.
> 
> Please drop this property's description here.

Thank you for pointing out.
Surely this MDIO node doesn't have own "reg" property, and this description
shows "reg" property of PHY device connected to the MDIO bus.

I'll remove the description.

Thank you,

> > +
> > +Example:
> > +
> > +	ether: ethernet@65000000 {
> > +		compatible = "socionext,uniphier-ld20-ave4";
> > +		reg = <0x65000000 0x8500>;
> > +		interrupts = <0 66 4>;
> > +		phy-mode = "rgmii";
> > +		phy-handle = <&ethphy>;
> > +		clocks = <&sys_clk 6>;
> > +		resets = <&sys_rst 6>;
> > +		local-mac-address = [00 00 00 00 00 00];
> > +		mdio {
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> > +			ethphy: ethphy@1 {
> > +				reg = <1>;
> > +			};
> > +		};
> > +	};
> > 
> 
> -- 
> Florian

---
Best Regards,
Kunihiko Hayashi


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: DT dtc warnings
From: Krzysztof Kozlowski @ 2017-12-15  7:34 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Fabio Estevam, Rob Herring, Barry Song, Kukjin Kim, Maxime Ripard,
	Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Mathieu Malaterre
In-Reply-To: <20171215072921.GJ2559-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>

On Fri, Dec 15, 2017 at 8:29 AM, Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On 15/12/2017 at 08:23:39 +0100, Krzysztof Kozlowski wrote:
>> On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> >
>> >> Thanks for reply!
>> >>
>> >> Isn't this property of a SoC? The registers used by
>> >> syscon-poweroff/reboot are part of SoC power management unit. It does
>> >> not refer to any externals. Why then it should be put outside of soc?
>> >
>> > If these nodes have registers, then they should have a unit address
>> > and reg property.
>>
>> That's the point - they do not have unit address.
>>
>
> Should they be put under the syscon they are using?

They are not using syscon but regmap provided by such external IP
block (for example this:
http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos3250.dtsi#L153).
I guess you are proposing something like on imx7s:
http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/imx7s.dtsi#L539

That makes sense... I am not sure how this would be related to the
warning itself but anyway it looks logically.

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

^ permalink raw reply

* Re: DT dtc warnings
From: Alexandre Belloni @ 2017-12-15  7:29 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Fabio Estevam, Rob Herring, Barry Song, Kukjin Kim, Maxime Ripard,
	Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Mathieu Malaterre
In-Reply-To: <CAJKOXPeqm-KRnuc7uUena=iH+rYLzSVSCb-uSbLB4SdRGqLRtw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 15/12/2017 at 08:23:39 +0100, Krzysztof Kozlowski wrote:
> On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >
> >> Thanks for reply!
> >>
> >> Isn't this property of a SoC? The registers used by
> >> syscon-poweroff/reboot are part of SoC power management unit. It does
> >> not refer to any externals. Why then it should be put outside of soc?
> >
> > If these nodes have registers, then they should have a unit address
> > and reg property.
> 
> That's the point - they do not have unit address.
> 

Should they be put under the syscon they are using?

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
From: Dhaval Shah @ 2017-12-15  7:24 UTC (permalink / raw)
  To: arnd, gregkh, robh+dt, mark.rutland, rdunlap
  Cc: devicetree, linux-kernel, michal.simek, hyunk, Dhaval Shah
In-Reply-To: <1513322656-4571-1-git-send-email-dshah@xilinx.com>

Xilinx ZYNQMP logicoreIP Init driver is based on the new
LogiCoreIP design created. This driver provides the processing system
and programmable logic isolation. Set the frequency based on the clock
information get from the logicoreIP register set.

It is put in drivers/misc as there is no subsystem for this logicoreIP.

Signed-off-by: Dhaval Shah <dshah@xilinx.com>
---
Changes since v4:
 * Indent the help text (below) by 2 additional spaces, as documented in coding-style.rst
 * Spell check are resolved as per the review comment.
 * inline the read() and write() functions..
 * multi-line comment style
 * Updated subject line prefix
Changes since v3:
 No Changes.
Changes since v2:
 * Removed the "default n" from the Kconfig
 * More help text added to explain more about the logicoreIP driver
 * SPDX id is relocated at top of the file with // style comment
 * Removed the export API and header file and make it a single driver
   which provides logocoreIP init.
 * Provide the information in commit message as well for the why driver
   in drivers/misc.

 drivers/misc/Kconfig    |  15 ++
 drivers/misc/Makefile   |   1 +
 drivers/misc/xlnx_vcu.c | 631 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 647 insertions(+)
 create mode 100644 drivers/misc/xlnx_vcu.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f1a5c23..e679936 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -496,6 +496,21 @@ config PCI_ENDPOINT_TEST
            Enable this configuration option to enable the host side test driver
            for PCI Endpoint.
 
+config XILINX_VCU
+	tristate "Xilinx VCU logicoreIP Init"
+	help
+	  Provides the driver to enable and disable the isolation between the
+	  processing system and programmable logic part by using the logicoreIP
+	  register set. This driver also configures the frequency based on the
+	  clock information from the logicoreIP register set.
+
+	  If you say yes here you get support for the logicoreIP.
+
+	  If unsure, say N.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called xlnx_vcu.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5ca5f64..a6bd0b1 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_CXL_BASE)		+= cxl/
 obj-$(CONFIG_ASPEED_LPC_CTRL)	+= aspeed-lpc-ctrl.o
 obj-$(CONFIG_ASPEED_LPC_SNOOP)	+= aspeed-lpc-snoop.o
 obj-$(CONFIG_PCI_ENDPOINT_TEST)	+= pci_endpoint_test.o
+obj-$(CONFIG_XILINX_VCU)	+= xlnx_vcu.o
 
 lkdtm-$(CONFIG_LKDTM)		+= lkdtm_core.o
 lkdtm-$(CONFIG_LKDTM)		+= lkdtm_bugs.o
diff --git a/drivers/misc/xlnx_vcu.c b/drivers/misc/xlnx_vcu.c
new file mode 100644
index 0000000..f489d34
--- /dev/null
+++ b/drivers/misc/xlnx_vcu.c
@@ -0,0 +1,631 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx VCU Init
+ *
+ * Copyright (C) 2016 - 2017 Xilinx, Inc.
+ *
+ * Contacts   Dhaval Shah <dshah@xilinx.com>
+ */
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+/* Address map for different registers implemented in the VCU LogiCORE IP. */
+#define VCU_ECODER_ENABLE		0x00
+#define VCU_DECODER_ENABLE		0x04
+#define VCU_MEMORY_DEPTH		0x08
+#define VCU_ENC_COLOR_DEPTH		0x0c
+#define VCU_ENC_VERTICAL_RANGE		0x10
+#define VCU_ENC_FRAME_SIZE_X		0x14
+#define VCU_ENC_FRAME_SIZE_Y		0x18
+#define VCU_ENC_COLOR_FORMAT		0x1c
+#define VCU_ENC_FPS			0x20
+#define VCU_MCU_CLK			0x24
+#define VCU_CORE_CLK			0x28
+#define VCU_PLL_BYPASS			0x2c
+#define VCU_ENC_CLK			0x30
+#define VCU_PLL_CLK			0x34
+#define VCU_ENC_VIDEO_STANDARD		0x38
+#define VCU_STATUS			0x3c
+#define VCU_AXI_ENC_CLK			0x40
+#define VCU_AXI_DEC_CLK			0x44
+#define VCU_AXI_MCU_CLK			0x48
+#define VCU_DEC_VIDEO_STANDARD		0x4c
+#define VCU_DEC_FRAME_SIZE_X		0x50
+#define VCU_DEC_FRAME_SIZE_Y		0x54
+#define VCU_DEC_FPS			0x58
+#define VCU_BUFFER_B_FRAME		0x5c
+#define VCU_WPP_EN			0x60
+#define VCU_PLL_CLK_DEC			0x64
+#define VCU_GASKET_INIT			0x74
+#define VCU_GASKET_VALUE		0x03
+
+/* vcu slcr registers, bitmask and shift */
+#define VCU_PLL_CTRL			0x24
+#define VCU_PLL_CTRL_RESET_MASK		0x01
+#define VCU_PLL_CTRL_RESET_SHIFT	0
+#define VCU_PLL_CTRL_BYPASS_MASK	0x01
+#define VCU_PLL_CTRL_BYPASS_SHIFT	3
+#define VCU_PLL_CTRL_FBDIV_MASK		0x7f
+#define VCU_PLL_CTRL_FBDIV_SHIFT	8
+#define VCU_PLL_CTRL_POR_IN_MASK	0x01
+#define VCU_PLL_CTRL_POR_IN_SHIFT	1
+#define VCU_PLL_CTRL_PWR_POR_MASK	0x01
+#define VCU_PLL_CTRL_PWR_POR_SHIFT	2
+#define VCU_PLL_CTRL_CLKOUTDIV_MASK	0x03
+#define VCU_PLL_CTRL_CLKOUTDIV_SHIFT	16
+#define VCU_PLL_CTRL_DEFAULT		0
+#define VCU_PLL_DIV2			2
+
+#define VCU_PLL_CFG			0x28
+#define VCU_PLL_CFG_RES_MASK		0x0f
+#define VCU_PLL_CFG_RES_SHIFT		0
+#define VCU_PLL_CFG_CP_MASK		0x0f
+#define VCU_PLL_CFG_CP_SHIFT		5
+#define VCU_PLL_CFG_LFHF_MASK		0x03
+#define VCU_PLL_CFG_LFHF_SHIFT		10
+#define VCU_PLL_CFG_LOCK_CNT_MASK	0x03ff
+#define VCU_PLL_CFG_LOCK_CNT_SHIFT	13
+#define VCU_PLL_CFG_LOCK_DLY_MASK	0x7f
+#define VCU_PLL_CFG_LOCK_DLY_SHIFT	25
+#define VCU_ENC_CORE_CTRL		0x30
+#define VCU_ENC_MCU_CTRL		0x34
+#define VCU_DEC_CORE_CTRL		0x38
+#define VCU_DEC_MCU_CTRL		0x3c
+#define VCU_PLL_DIVISOR_MASK		0x3f
+#define VCU_PLL_DIVISOR_SHIFT		4
+#define VCU_SRCSEL_MASK			0x01
+#define VCU_SRCSEL_SHIFT		0
+#define VCU_SRCSEL_PLL			1
+
+#define VCU_PLL_STATUS			0x60
+#define VCU_PLL_STATUS_LOCK_STATUS_MASK	0x01
+
+#define MHZ				1000000
+#define FVCO_MIN			(1500U * MHZ)
+#define FVCO_MAX			(3000U * MHZ)
+#define DIVISOR_MIN			0
+#define DIVISOR_MAX			63
+#define FRAC				100
+#define LIMIT				(10 * MHZ)
+
+/**
+ * struct xvcu_device - Xilinx VCU init device structure
+ * @dev: Platform device
+ * @pll_ref: pll ref clock source
+ * @aclk: axi clock source
+ * @logicore_reg_ba: logicore reg base address
+ * @vcu_slcr_ba: vcu_slcr Register base address
+ * @coreclk: core clock frequency
+ */
+struct xvcu_device {
+	struct device *dev;
+	struct clk *pll_ref;
+	struct clk *aclk;
+	void __iomem *logicore_reg_ba;
+	void __iomem *vcu_slcr_ba;
+	u32 coreclk;
+};
+
+/**
+ * struct xvcu_pll_cfg - Helper data
+ * @fbdiv: The integer portion of the feedback divider to the PLL
+ * @cp: PLL charge pump control
+ * @res: PLL loop filter resistor control
+ * @lfhf: PLL loop filter high frequency capacitor control
+ * @lock_dly: Lock circuit configuration settings for lock windowsize
+ * @lock_cnt: Lock circuit counter setting
+ */
+struct xvcu_pll_cfg {
+	u32 fbdiv;
+	u32 cp;
+	u32 res;
+	u32 lfhf;
+	u32 lock_dly;
+	u32 lock_cnt;
+};
+
+static const struct xvcu_pll_cfg xvcu_pll_cfg[] = {
+	{ 25, 3, 10, 3, 63, 1000 },
+	{ 26, 3, 10, 3, 63, 1000 },
+	{ 27, 4, 6, 3, 63, 1000 },
+	{ 28, 4, 6, 3, 63, 1000 },
+	{ 29, 4, 6, 3, 63, 1000 },
+	{ 30, 4, 6, 3, 63, 1000 },
+	{ 31, 6, 1, 3, 63, 1000 },
+	{ 32, 6, 1, 3, 63, 1000 },
+	{ 33, 4, 10, 3, 63, 1000 },
+	{ 34, 5, 6, 3, 63, 1000 },
+	{ 35, 5, 6, 3, 63, 1000 },
+	{ 36, 5, 6, 3, 63, 1000 },
+	{ 37, 5, 6, 3, 63, 1000 },
+	{ 38, 5, 6, 3, 63, 975 },
+	{ 39, 3, 12, 3, 63, 950 },
+	{ 40, 3, 12, 3, 63, 925 },
+	{ 41, 3, 12, 3, 63, 900 },
+	{ 42, 3, 12, 3, 63, 875 },
+	{ 43, 3, 12, 3, 63, 850 },
+	{ 44, 3, 12, 3, 63, 850 },
+	{ 45, 3, 12, 3, 63, 825 },
+	{ 46, 3, 12, 3, 63, 800 },
+	{ 47, 3, 12, 3, 63, 775 },
+	{ 48, 3, 12, 3, 63, 775 },
+	{ 49, 3, 12, 3, 63, 750 },
+	{ 50, 3, 12, 3, 63, 750 },
+	{ 51, 3, 2, 3, 63, 725 },
+	{ 52, 3, 2, 3, 63, 700 },
+	{ 53, 3, 2, 3, 63, 700 },
+	{ 54, 3, 2, 3, 63, 675 },
+	{ 55, 3, 2, 3, 63, 675 },
+	{ 56, 3, 2, 3, 63, 650 },
+	{ 57, 3, 2, 3, 63, 650 },
+	{ 58, 3, 2, 3, 63, 625 },
+	{ 59, 3, 2, 3, 63, 625 },
+	{ 60, 3, 2, 3, 63, 625 },
+	{ 61, 3, 2, 3, 63, 600 },
+	{ 62, 3, 2, 3, 63, 600 },
+	{ 63, 3, 2, 3, 63, 600 },
+	{ 64, 3, 2, 3, 63, 600 },
+	{ 65, 3, 2, 3, 63, 600 },
+	{ 66, 3, 2, 3, 63, 600 },
+	{ 67, 3, 2, 3, 63, 600 },
+	{ 68, 3, 2, 3, 63, 600 },
+	{ 69, 3, 2, 3, 63, 600 },
+	{ 70, 3, 2, 3, 63, 600 },
+	{ 71, 3, 2, 3, 63, 600 },
+	{ 72, 3, 2, 3, 63, 600 },
+	{ 73, 3, 2, 3, 63, 600 },
+	{ 74, 3, 2, 3, 63, 600 },
+	{ 75, 3, 2, 3, 63, 600 },
+	{ 76, 3, 2, 3, 63, 600 },
+	{ 77, 3, 2, 3, 63, 600 },
+	{ 78, 3, 2, 3, 63, 600 },
+	{ 79, 3, 2, 3, 63, 600 },
+	{ 80, 3, 2, 3, 63, 600 },
+	{ 81, 3, 2, 3, 63, 600 },
+	{ 82, 3, 2, 3, 63, 600 },
+	{ 83, 4, 2, 3, 63, 600 },
+	{ 84, 4, 2, 3, 63, 600 },
+	{ 85, 4, 2, 3, 63, 600 },
+	{ 86, 4, 2, 3, 63, 600 },
+	{ 87, 4, 2, 3, 63, 600 },
+	{ 88, 4, 2, 3, 63, 600 },
+	{ 89, 4, 2, 3, 63, 600 },
+	{ 90, 4, 2, 3, 63, 600 },
+	{ 91, 4, 2, 3, 63, 600 },
+	{ 92, 4, 2, 3, 63, 600 },
+	{ 93, 4, 2, 3, 63, 600 },
+	{ 94, 4, 2, 3, 63, 600 },
+	{ 95, 4, 2, 3, 63, 600 },
+	{ 96, 4, 2, 3, 63, 600 },
+	{ 97, 4, 2, 3, 63, 600 },
+	{ 98, 4, 2, 3, 63, 600 },
+	{ 99, 4, 2, 3, 63, 600 },
+	{ 100, 4, 2, 3, 63, 600 },
+	{ 101, 4, 2, 3, 63, 600 },
+	{ 102, 4, 2, 3, 63, 600 },
+	{ 103, 5, 2, 3, 63, 600 },
+	{ 104, 5, 2, 3, 63, 600 },
+	{ 105, 5, 2, 3, 63, 600 },
+	{ 106, 5, 2, 3, 63, 600 },
+	{ 107, 3, 4, 3, 63, 600 },
+	{ 108, 3, 4, 3, 63, 600 },
+	{ 109, 3, 4, 3, 63, 600 },
+	{ 110, 3, 4, 3, 63, 600 },
+	{ 111, 3, 4, 3, 63, 600 },
+	{ 112, 3, 4, 3, 63, 600 },
+	{ 113, 3, 4, 3, 63, 600 },
+	{ 114, 3, 4, 3, 63, 600 },
+	{ 115, 3, 4, 3, 63, 600 },
+	{ 116, 3, 4, 3, 63, 600 },
+	{ 117, 3, 4, 3, 63, 600 },
+	{ 118, 3, 4, 3, 63, 600 },
+	{ 119, 3, 4, 3, 63, 600 },
+	{ 120, 3, 4, 3, 63, 600 },
+	{ 121, 3, 4, 3, 63, 600 },
+	{ 122, 3, 4, 3, 63, 600 },
+	{ 123, 3, 4, 3, 63, 600 },
+	{ 124, 3, 4, 3, 63, 600 },
+	{ 125, 3, 4, 3, 63, 600 },
+};
+
+/**
+ * xvcu_read - Read from the VCU register space
+ * @iomem:	vcu reg space base address
+ * @offset:	vcu reg offset from base
+ *
+ * Return:	Returns 32bit value from VCU register specified
+ *
+ */
+static inline u32 xvcu_read(void __iomem *iomem, u32 offset)
+{
+	return ioread32(iomem + offset);
+}
+
+/**
+ * xvcu_write - Write to the VCU register space
+ * @iomem:	vcu reg space base address
+ * @offset:	vcu reg offset from base
+ * @value:	Value to write
+ */
+static inline void xvcu_write(void __iomem *iomem, u32 offset, u32 value)
+{
+	iowrite32(value, iomem + offset);
+}
+
+/**
+ * xvcu_write_field_reg - Write to the vcu reg field
+ * @iomem:	vcu reg space base address
+ * @offset:	vcu reg offset from base
+ * @field:	vcu reg field to write to
+ * @mask:	vcu reg mask
+ * @shift:	vcu reg number of bits to shift the bitfield
+ */
+static void xvcu_write_field_reg(void __iomem *iomem, int offset,
+				u32 field, u32 mask, int shift)
+{
+	u32 val = xvcu_read(iomem, offset);
+
+	val &= ~(mask << shift);
+	val |= (field & mask) << shift;
+
+	xvcu_write(iomem, offset, val);
+}
+
+/**
+ * xvcu_set_vcu_pll_info - Set the VCU PLL info
+ * @xvcu:	Pointer to the xvcu_device structure
+ *
+ * Programming the VCU PLL based on the user configuration
+ * (ref clock freq, core clock freq, mcu clock freq).
+ * Core clock frequency has higher priority than mcu clock frequency
+ * Errors in following cases
+ *    - When mcu or clock clock get from logicoreIP is 0
+ *    - When VCU PLL DIV related bits value other than 1
+ *    - When proper data not found for given data
+ *    - When sis570_1 clocksource related operation failed
+ *
+ * Return:	Returns status, either success or error+reason
+ */
+static int xvcu_set_vcu_pll_info(struct xvcu_device *xvcu)
+{
+	u32 refclk, coreclk, mcuclk, inte, deci;
+	u32 divisor_mcu, divisor_core, fvco;
+	u32 clkoutdiv, vcu_pll_ctrl, pll_clk;
+	u32 cfg_val, mod, ctrl;
+	int ret;
+	unsigned int i;
+	const struct xvcu_pll_cfg *found = NULL;
+
+	inte = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK);
+	deci = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK_DEC);
+	coreclk = xvcu_read(xvcu->logicore_reg_ba, VCU_CORE_CLK) * MHZ;
+	mcuclk = xvcu_read(xvcu->logicore_reg_ba, VCU_MCU_CLK) * MHZ;
+	if (!mcuclk || !coreclk) {
+		dev_err(xvcu->dev, "Invalid mcu and core clock data\n");
+		return -EINVAL;
+	}
+
+	refclk = (inte * MHZ) + (deci * (MHZ / FRAC));
+	dev_dbg(xvcu->dev, "Ref clock from logicoreIP is %uHz\n", refclk);
+	dev_dbg(xvcu->dev, "Core clock from logicoreIP is %uHz\n", coreclk);
+	dev_dbg(xvcu->dev, "Mcu clock from logicoreIP is %uHz\n", mcuclk);
+
+	clk_disable_unprepare(xvcu->pll_ref);
+	ret = clk_set_rate(xvcu->pll_ref, refclk);
+	if (ret)
+		dev_warn(xvcu->dev, "failed to set logicoreIP refclk rate\n");
+
+	ret = clk_prepare_enable(xvcu->pll_ref);
+	if (ret) {
+		dev_err(xvcu->dev, "failed to enable pll_ref clock source\n");
+		return ret;
+	}
+
+	refclk = clk_get_rate(xvcu->pll_ref);
+
+	/*
+	 * The divide-by-2 should be always enabled (==1)
+	 * to meet the timing in the design.
+	 * Otherwise, it's an error
+	 */
+	vcu_pll_ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_PLL_CTRL);
+	clkoutdiv = vcu_pll_ctrl >> VCU_PLL_CTRL_CLKOUTDIV_SHIFT;
+	clkoutdiv = clkoutdiv && VCU_PLL_CTRL_CLKOUTDIV_MASK;
+	if (clkoutdiv != 1) {
+		dev_err(xvcu->dev, "clkoutdiv value is invalid\n");
+		return -EINVAL;
+	}
+
+	for (i = ARRAY_SIZE(xvcu_pll_cfg) - 1; i > 0; i--) {
+		const struct xvcu_pll_cfg *cfg = &xvcu_pll_cfg[i];
+
+		fvco = cfg->fbdiv * refclk;
+		if (fvco >= FVCO_MIN && fvco <= FVCO_MAX) {
+			pll_clk = fvco / VCU_PLL_DIV2;
+			if (fvco % VCU_PLL_DIV2 != 0)
+				pll_clk++;
+			mod = pll_clk % coreclk;
+			if (mod < LIMIT) {
+				divisor_core = pll_clk / coreclk;
+			} else if (coreclk - mod < LIMIT) {
+				divisor_core = pll_clk / coreclk;
+				divisor_core++;
+			} else {
+				continue;
+			}
+			if (divisor_core >= DIVISOR_MIN &&
+			    divisor_core <= DIVISOR_MAX) {
+				found = cfg;
+				divisor_mcu = pll_clk / mcuclk;
+				mod = pll_clk % mcuclk;
+				if (mcuclk - mod < LIMIT)
+					divisor_mcu++;
+				break;
+			}
+		}
+	}
+
+	if (!found) {
+		dev_err(xvcu->dev, "Invalid clock combination.\n");
+		return -EINVAL;
+	}
+
+	xvcu->coreclk = pll_clk / divisor_core;
+	mcuclk = pll_clk / divisor_mcu;
+	dev_dbg(xvcu->dev, "Actual Ref clock freq is %uHz\n", refclk);
+	dev_dbg(xvcu->dev, "Actual Core clock freq is %uHz\n", xvcu->coreclk);
+	dev_dbg(xvcu->dev, "Actual Mcu clock freq is %uHz\n", mcuclk);
+
+	vcu_pll_ctrl &= ~(VCU_PLL_CTRL_FBDIV_MASK << VCU_PLL_CTRL_FBDIV_SHIFT);
+	vcu_pll_ctrl |= (found->fbdiv & VCU_PLL_CTRL_FBDIV_MASK) <<
+			 VCU_PLL_CTRL_FBDIV_SHIFT;
+	vcu_pll_ctrl &= ~(VCU_PLL_CTRL_POR_IN_MASK <<
+			  VCU_PLL_CTRL_POR_IN_SHIFT);
+	vcu_pll_ctrl |= (VCU_PLL_CTRL_DEFAULT & VCU_PLL_CTRL_POR_IN_MASK) <<
+			 VCU_PLL_CTRL_POR_IN_SHIFT;
+	vcu_pll_ctrl &= ~(VCU_PLL_CTRL_PWR_POR_MASK <<
+			  VCU_PLL_CTRL_PWR_POR_SHIFT);
+	vcu_pll_ctrl |= (VCU_PLL_CTRL_DEFAULT & VCU_PLL_CTRL_PWR_POR_MASK) <<
+			 VCU_PLL_CTRL_PWR_POR_SHIFT;
+	xvcu_write(xvcu->vcu_slcr_ba, VCU_PLL_CTRL, vcu_pll_ctrl);
+
+	/* Set divisor for the core and mcu clock */
+	ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_ENC_CORE_CTRL);
+	ctrl &= ~(VCU_PLL_DIVISOR_MASK << VCU_PLL_DIVISOR_SHIFT);
+	ctrl |= (divisor_core & VCU_PLL_DIVISOR_MASK) <<
+		 VCU_PLL_DIVISOR_SHIFT;
+	ctrl &= ~(VCU_SRCSEL_MASK << VCU_SRCSEL_SHIFT);
+	ctrl |= (VCU_SRCSEL_PLL & VCU_SRCSEL_MASK) << VCU_SRCSEL_SHIFT;
+	xvcu_write(xvcu->vcu_slcr_ba, VCU_ENC_CORE_CTRL, ctrl);
+
+	ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_DEC_CORE_CTRL);
+	ctrl &= ~(VCU_PLL_DIVISOR_MASK << VCU_PLL_DIVISOR_SHIFT);
+	ctrl |= (divisor_core & VCU_PLL_DIVISOR_MASK) <<
+		 VCU_PLL_DIVISOR_SHIFT;
+	ctrl &= ~(VCU_SRCSEL_MASK << VCU_SRCSEL_SHIFT);
+	ctrl |= (VCU_SRCSEL_PLL & VCU_SRCSEL_MASK) << VCU_SRCSEL_SHIFT;
+	xvcu_write(xvcu->vcu_slcr_ba, VCU_DEC_CORE_CTRL, ctrl);
+
+	ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_ENC_MCU_CTRL);
+	ctrl &= ~(VCU_PLL_DIVISOR_MASK << VCU_PLL_DIVISOR_SHIFT);
+	ctrl |= (divisor_mcu & VCU_PLL_DIVISOR_MASK) << VCU_PLL_DIVISOR_SHIFT;
+	ctrl &= ~(VCU_SRCSEL_MASK << VCU_SRCSEL_SHIFT);
+	ctrl |= (VCU_SRCSEL_PLL & VCU_SRCSEL_MASK) << VCU_SRCSEL_SHIFT;
+	xvcu_write(xvcu->vcu_slcr_ba, VCU_ENC_MCU_CTRL, ctrl);
+
+	ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_DEC_MCU_CTRL);
+	ctrl &= ~(VCU_PLL_DIVISOR_MASK << VCU_PLL_DIVISOR_SHIFT);
+	ctrl |= (divisor_mcu & VCU_PLL_DIVISOR_MASK) << VCU_PLL_DIVISOR_SHIFT;
+	ctrl &= ~(VCU_SRCSEL_MASK << VCU_SRCSEL_SHIFT);
+	ctrl |= (VCU_SRCSEL_PLL & VCU_SRCSEL_MASK) << VCU_SRCSEL_SHIFT;
+	xvcu_write(xvcu->vcu_slcr_ba, VCU_DEC_MCU_CTRL, ctrl);
+
+	/* Set RES, CP, LFHF, LOCK_CNT and LOCK_DLY cfg values */
+	cfg_val = (found->res << VCU_PLL_CFG_RES_SHIFT) |
+		   (found->cp << VCU_PLL_CFG_CP_SHIFT) |
+		   (found->lfhf << VCU_PLL_CFG_LFHF_SHIFT) |
+		   (found->lock_cnt << VCU_PLL_CFG_LOCK_CNT_SHIFT) |
+		   (found->lock_dly << VCU_PLL_CFG_LOCK_DLY_SHIFT);
+	xvcu_write(xvcu->vcu_slcr_ba, VCU_PLL_CFG, cfg_val);
+
+	return 0;
+}
+
+/**
+ * xvcu_set_pll - PLL init sequence
+ * @xvcu:	Pointer to the xvcu_device structure
+ *
+ * Call the api to set the PLL info and once that is done then
+ * init the PLL sequence to make the PLL stable.
+ *
+ * Return:	Returns status, either success or error+reason
+ */
+static int xvcu_set_pll(struct xvcu_device *xvcu)
+{
+	u32 lock_status;
+	unsigned long timeout;
+	int ret;
+
+	ret = xvcu_set_vcu_pll_info(xvcu);
+	if (ret) {
+		dev_err(xvcu->dev, "failed to set pll info\n");
+		return ret;
+	}
+
+	xvcu_write_field_reg(xvcu->vcu_slcr_ba, VCU_PLL_CTRL,
+			     1, VCU_PLL_CTRL_BYPASS_MASK,
+			     VCU_PLL_CTRL_BYPASS_SHIFT);
+	xvcu_write_field_reg(xvcu->vcu_slcr_ba, VCU_PLL_CTRL,
+			     1, VCU_PLL_CTRL_RESET_MASK,
+			     VCU_PLL_CTRL_RESET_SHIFT);
+	xvcu_write_field_reg(xvcu->vcu_slcr_ba, VCU_PLL_CTRL,
+			     0, VCU_PLL_CTRL_RESET_MASK,
+			     VCU_PLL_CTRL_RESET_SHIFT);
+	/*
+	 * Defined the timeout for the max time to wait the
+	 * PLL_STATUS to be locked.
+	 */
+	timeout = jiffies + msecs_to_jiffies(2000);
+	do {
+		lock_status = xvcu_read(xvcu->vcu_slcr_ba, VCU_PLL_STATUS);
+		if (lock_status & VCU_PLL_STATUS_LOCK_STATUS_MASK) {
+			xvcu_write_field_reg(xvcu->vcu_slcr_ba, VCU_PLL_CTRL,
+					     0, VCU_PLL_CTRL_BYPASS_MASK,
+					     VCU_PLL_CTRL_BYPASS_SHIFT);
+			return 0;
+		}
+	} while (!time_after(jiffies, timeout));
+
+	/* PLL is not locked even after the timeout of the 2sec */
+	dev_err(xvcu->dev, "PLL is not locked\n");
+	return -ETIMEDOUT;
+}
+
+/**
+ * xvcu_probe - Probe existence of the logicoreIP
+ *			and initialize PLL
+ *
+ * @pdev:	Pointer to the platform_device structure
+ *
+ * Return:	Returns 0 on success
+ *		Negative error code otherwise
+ */
+static int xvcu_probe(struct platform_device *pdev)
+{
+	struct resource *res;
+	struct xvcu_device *xvcu;
+	int ret;
+
+	xvcu = devm_kzalloc(&pdev->dev, sizeof(*xvcu), GFP_KERNEL);
+	if (!xvcu)
+		return -ENOMEM;
+
+	xvcu->dev = &pdev->dev;
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vcu_slcr");
+	if (!res) {
+		dev_err(&pdev->dev, "get vcu_slcr memory resource failed.\n");
+		return -ENODEV;
+	}
+
+	xvcu->vcu_slcr_ba = devm_ioremap_nocache(&pdev->dev,
+			res->start, resource_size(res));
+	if (!xvcu->vcu_slcr_ba) {
+		dev_err(&pdev->dev, "vcu_slcr register mapping failed.\n");
+		return -ENOMEM;
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "logicore");
+	if (!res) {
+		dev_err(&pdev->dev, "get logicore memory resource failed.\n");
+		return -ENODEV;
+	}
+
+	xvcu->logicore_reg_ba = devm_ioremap_nocache(&pdev->dev,
+			res->start, resource_size(res));
+	if (!xvcu->logicore_reg_ba) {
+		dev_err(&pdev->dev, "logicore register mapping failed.\n");
+		return -ENOMEM;
+	}
+
+	xvcu->aclk = devm_clk_get(&pdev->dev, "aclk");
+	if (IS_ERR(xvcu->aclk)) {
+		dev_err(&pdev->dev, "Could not get aclk clock\n");
+		return PTR_ERR(xvcu->aclk);
+	}
+
+	xvcu->pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
+	if (IS_ERR(xvcu->pll_ref)) {
+		dev_err(&pdev->dev, "Could not get pll_ref clock\n");
+		return PTR_ERR(xvcu->pll_ref);
+	}
+
+	ret = clk_prepare_enable(xvcu->aclk);
+	if (ret) {
+		dev_err(&pdev->dev, "aclk clock enable failed\n");
+		return ret;
+	}
+
+	ret = clk_prepare_enable(xvcu->pll_ref);
+	if (ret) {
+		dev_err(&pdev->dev, "pll_ref clock enable failed\n");
+		goto error_aclk;
+	}
+
+	/*
+	 * Do the Gasket isolation and put the VCU out of reset
+	 * Bit 0 : Gasket isolation
+	 * Bit 1 : put VCU out of reset
+	 */
+	xvcu_write(xvcu->logicore_reg_ba, VCU_GASKET_INIT, VCU_GASKET_VALUE);
+
+	/* Do the PLL Settings based on the ref clk,core and mcu clk freq */
+	ret = xvcu_set_pll(xvcu);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to set the pll\n");
+		goto error_pll_ref;
+	}
+
+	dev_set_drvdata(&pdev->dev, xvcu);
+
+	dev_info(&pdev->dev, "%s: Probed successfully\n", __func__);
+
+	return 0;
+
+error_pll_ref:
+	clk_disable_unprepare(xvcu->pll_ref);
+error_aclk:
+	clk_disable_unprepare(xvcu->aclk);
+	return ret;
+}
+
+/**
+ * xvcu_remove - Insert gasket isolation
+ *			and disable the clock
+ * @pdev:	Pointer to the platform_device structure
+ *
+ * Return:	Returns 0 on success
+ *		Negative error code otherwise
+ */
+static int xvcu_remove(struct platform_device *pdev)
+{
+	struct xvcu_device *xvcu;
+
+	xvcu = platform_get_drvdata(pdev);
+	if (!xvcu)
+		return -ENODEV;
+
+	/* Add the the Gasket isolation and put the VCU in reset. */
+	xvcu_write(xvcu->logicore_reg_ba, VCU_GASKET_INIT, 0);
+
+	clk_disable_unprepare(xvcu->pll_ref);
+	clk_disable_unprepare(xvcu->aclk);
+
+	return 0;
+}
+
+static const struct of_device_id xvcu_of_id_table[] = {
+	{ .compatible = "xlnx,vcu" },
+	{ .compatible = "xlnx,vcu-logicoreip-1.0" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, xvcu_of_id_table);
+
+static struct platform_driver xvcu_driver = {
+	.driver = {
+		.name           = "xilinx-vcu",
+		.of_match_table = xvcu_of_id_table,
+	},
+	.probe                  = xvcu_probe,
+	.remove                 = xvcu_remove,
+};
+
+module_platform_driver(xvcu_driver);
+
+MODULE_AUTHOR("Dhaval Shah <dshah@xilinx.com>");
+MODULE_DESCRIPTION("Xilinx VCU init Driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

^ permalink raw reply related

* [PATCH v4 1/2] dt-bindings: misc: Add DT bindings to xlnx_vcu driver
From: Dhaval Shah @ 2017-12-15  7:24 UTC (permalink / raw)
  To: arnd-r2nGTMty4D4, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	rdunlap-wEGCiKHe2LqWVfeAwA7xHQ
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	michal.simek-gjFFaj9aHVfQT0dZR+AlfA, hyunk-gjFFaj9aHVfQT0dZR+AlfA,
	Dhaval Shah, Dhaval Shah
In-Reply-To: <1513322656-4571-1-git-send-email-dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>

From: Dhaval Shah <dhaval.shah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>

Add Device Tree binding document for logicoreIP. This logicoreIP
provides the isolation between the processing system and
programmable logic. Also provides the clock related information.

Signed-off-by: Dhaval Shah <dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
---
Chnages since v3:
 No Changes.	
Chnages since v3:
 * Use "dt-bindings: misc: ..." for the subject.
Changes since v2:
 * Describe the h/w
 * compatible string is updated to make it more specific
   based on the logicoreIP version.
 * Removed that encoder and decoder child nodes and relatd properties as that
   will be a separate driver and dts nodes. other team is working on that.
 * Updated to use as a single driver.

 .../devicetree/bindings/misc/xlnx,vcu.txt          | 31 ++++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,vcu.txt

diff --git a/Documentation/devicetree/bindings/misc/xlnx,vcu.txt b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
new file mode 100644
index 0000000..6786d67
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
@@ -0,0 +1,31 @@
+LogicoreIP designed compatible with Xilinx ZYNQ family.
+-------------------------------------------------------
+
+General concept
+---------------
+
+LogicoreIP design to provide the isolation between processing system
+and programmable logic. Also provides the list of register set to configure
+the frequency.
+
+Required properties:
+- compatible: shall be one of:
+	"xlnx,vcu"
+	"xlnx,vcu-logicoreip-1.0"
+- reg, reg-names: There are two sets of registers need to provide.
+	1. vcu slcr
+	2. Logicore
+	reg-names should contain name for the each register sequence.
+- clocks: phandle for aclk and pll_ref clocksource
+- clock-names: The identification string, "aclk", is always required for
+   the axi clock. "pll_ref" is required for pll.
+Example:
+
+	xlnx_vcu: vcu@a0040000 {
+		compatible = "xlnx,vcu-logicoreip-1.0";
+		reg = <0x0 0xa0040000 0x0 0x1000>,
+			 <0x0 0xa0041000 0x0 0x1000>;
+		reg-names = "vcu_slcr", "logicore";
+		clocks = <&si570_1>, <&clkc 71>;
+		clock-names = "pll_ref", "aclk";
+	};
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH v4 0/2] Documentation and driver of logicoreIP
From: Dhaval Shah @ 2017-12-15  7:24 UTC (permalink / raw)
  To: arnd-r2nGTMty4D4, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	rdunlap-wEGCiKHe2LqWVfeAwA7xHQ
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	michal.simek-gjFFaj9aHVfQT0dZR+AlfA, hyunk-gjFFaj9aHVfQT0dZR+AlfA,
	Dhaval Shah
In-Reply-To: <29198c0a-783e-8aa0-00e4-44b1fa1acef7-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

1st patch provide Device Tree binding document for logicoreIP
2nd patch provide the xlnx_vcu logicoreIP driver, Kconfig changes
and Makefile changes for the driver.

Dhaval Shah (2):
  Documentation: devicetree: Add DT bindings to xlnx_vcu driver
  misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver

 .../devicetree/bindings/misc/xlnx,vcu.txt          |  31 +
 drivers/misc/Kconfig                               |  15 +
 drivers/misc/Makefile                              |   1 +
 drivers/misc/xlnx_vcu.c                            | 631 +++++++++++++++++++++
 4 files changed, 678 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,vcu.txt
 create mode 100644 drivers/misc/xlnx_vcu.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: DT dtc warnings
From: Krzysztof Kozlowski @ 2017-12-15  7:23 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Rob Herring, Barry Song, Kukjin Kim, Maxime Ripard, Chen-Yu Tsai,
	Nicolas Ferre, Alexandre Belloni, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Mathieu Malaterre
In-Reply-To: <CAOMZO5CKPhQwdkYBeu74k=RYBxGhVf13nnrzHXUhq8LWk8yBSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
>> Thanks for reply!
>>
>> Isn't this property of a SoC? The registers used by
>> syscon-poweroff/reboot are part of SoC power management unit. It does
>> not refer to any externals. Why then it should be put outside of soc?
>
> If these nodes have registers, then they should have a unit address
> and reg property.

That's the point - they do not have unit address.

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

^ permalink raw reply

* Re: [PATCH v2 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC
From: Ulf Hansson @ 2017-12-15  7:11 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: sean.wang-NuS5LvNUpcJWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <86e53802-9bb4-35eb-66e1-f9a401e31863-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On 14 December 2017 at 12:16, Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Ulf,
>
> On 12/07/2017 07:43 AM, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
>> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>
>> Add the devicetree binding for MT7623 SoC using MT2701 as the fallback.
>>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
>> index 72d2a73..9b80176 100644
>> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
>> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
>> @@ -12,6 +12,8 @@ Required properties:
>>       "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
>>       "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
>>       "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
>> +     "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
>> +
>>  - reg: physical base address of the controller and length
>>  - interrupts: Should contain MSDC interrupt number
>>  - clocks: Should contain phandle for the clock feeding the MMC controller
>>
>
> Are you fine to take this patch through your branch, or shall I take it through
> mine?

I have pick it up, thanks!

>
> @Sean it seems you forgot to send this patch to Ulf as well. In the future
> please take care to send the patch to all relevant people and mailinglist.

Yeah, thanks for looping me in this time!

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox