[PATCH] usb: phy: samsung: Add support to set pmu isolation
Adding support to parse device node data in order to get
required properties to set pmu isolation for usb-phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v5:
- Using a global spin_lock member in 'samsung_usbphy' structure to be
used in samsung_usbphy_init() and samsung_usbphy_shutdown()
to take care of all register initialization sequence.
- Addressing few nits:
- Using devphy_reg_offset instead of 'pmureg_devphy_offset'
- Using if else block instead of ternary conditional statement
in samsung_usbphy_set_isolation()
- Using 'bool' type instead of 'int' for 'on' argument in
samsung_usbphy_set_isolation()
- Amending few comments.
.../devicetree/bindings/usb/samsung-usbphy.txt | 36 +
drivers/usb/phy/samsung-usbphy.c | 161 +---
2 files changed, 175 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 7b26e2d..22d06cf 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -9,3 +9,39 @@ Required properties:
- compatible : should be samsung,exynos4210-usbphy
- reg : base physical address of the phy registers and length of memory mapped
region.
+
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- ranges: allows valid translation between child's address space and parent's
+ address space.
+
+- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
+ interface for usb-phy. It should provide the following information required
by
+ usb-phy controller to control phy.
+ - reg : base physical address of PHY_CONTROL registers.
+ The size of this register is the total sum of size of all PHY_CONTROL
+ registers that the SoC has. For example, the size will be
+ '0x4' in case we have only one PHY_CONTROL register (e.g.
+ OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
+ and, '0x8' in case we have two PHY_CONTROL registers (e.g.
+ USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
+ and so on.
+
+Example:
+ - Exynos4210
+
+ usbphy@125B {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = samsung,exynos4210-usbphy;
+ reg = 0x125B 0x100;
+ ranges;
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = 0x10020704 0x8;
+ };
+ };
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 5c5e1bb5..7eec7c3 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -24,6 +24,7 @@
#include linux/err.h
#include linux/io.h
#include linux/of.h
+#include linux/of_address.h
#include linux/usb/otg.h
#include linux/platform_data/samsung-usbphy.h
@@ -60,20 +61,46 @@
#define MHZ (1000*1000)
#endif
+#define S3C64XX_USBPHY_ENABLE (0x1 16)
+#define EXYNOS_USBPHY_ENABLE (0x1 0)
+
enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
};
/*
+ * struct samsung_usbphy_drvdata - driver data for various SoC variants
+ * @cpu_type: machine identifier
+ * @devphy_en_mask: device phy enable mask for PHY CONTROL register
+ * @devphy_reg_offset: offset to DEVICE PHY CONTROL register from
+ *mapped address of system controller.
+ *
+ * Here we have a separate mask for device type phy.
+ * Having different masks for host and device type phy helps
+ * in setting independent masks in case of SoCs like S5PV210,
+ * in which PHY0 and PHY1 enable bits belong to same register
+ * placed at position 0 and 1 respectively.
+ * Although for newer SoCs like exynos these bits belong to
+ * different registers altogether placed at position 0.
+ */
+struct samsung_usbphy_drvdata {
+ int cpu_type;
+ int devphy_en_mask;
+ u32 devphy_reg_offset;
+};
+
+/*
* struct samsung_usbphy - transceiver driver state
* @phy: transceiver structure
* @plat: platform data
* @dev: The parent device supplied to the probe function
* @clk: usb phy clock
- * @regs: usb phy register memory base
+ * @regs: usb phy controller registers memory base
+ * @pmuregs: USB device PHY_CONTROL register memory base
* @ref_clk_freq: reference clock frequency selection
- * @cpu_type: machine identifier
+ * @drv_data: driver data available for different SoCs
+ * @lock: lock for phy operations
*/
struct samsung_usbphy {
struct usb_phy phy;
@@ -81,12 +108,64 @@ struct
[patch] tg3: missing break statement in tg3_get_5720_nvram_info()
There is a missing break statement so FLASH_5762_EEPROM_HD gets treated
like FLASH_5762_EEPROM_LD.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Only needed in linux-next.
diff --git a/drivers/net/ethernet/broadcom/tg3.c
b/drivers/net/ethernet/broadcom/tg3.c
index bc4d989..642764e 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -13726,8 +13726,10 @@ static void tg3_get_5720_nvram_info(struct tg3 *tp)
switch (nvmpinstrp) {
case FLASH_5762_EEPROM_HD:
nvmpinstrp = FLASH_5720_EEPROM_HD;
+ break;
case FLASH_5762_EEPROM_LD:
nvmpinstrp = FLASH_5720_EEPROM_LD;
+ break;
}
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 0/4] pm: Add power off control
On Wed, Jan 2, 2013 at 2:15 AM, AnilKumar, Chimata anilku...@ti.com wrote: On Fri, Dec 14, 2012 at 11:33:13, AnilKumar, Chimata wrote: Add PM power_off control to rtc driver and PMIC status is set to STATUS_OFF to shutdown PMIC if PWR_EN is toggled by RTC module. System power off sequence:- * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low * Enable PMIC_POWER_EN in rtc module * Set rtc ALARM2 time * Enable ALARM2 interrupt These patches were tested on am335x-bone (BeagleBone). These patchs are based on linux-next. Hi All, Happy New Year Gentle ping to this series I personally like the series, it certainly adds needed functionality. I just wish there was a way to get it without a possible 4 second delay. Thanks AnilKumar Changes from v3: - TPS65217 mfd driver changes are accepted so dropped from this series. - With recent changes in the kernel, reboot_mutex held BUG() is not seen so removed while(1); from rtc_power_off. - Removed spinlock before while(1); which is not necessary. Changes from v2: - Incorporated Kevin's comment on v2 * Enabled RTC in ompa2plus_defconfig Changes from v1: - Incorporated Vaibhav's comments on v1 * Changed the time rollover logic with the help of rtc-lib APIs AnilKumar Ch (3): ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone ARM: dts: AM33XX: Enable system power off control in am335x-bone ARM: OMAP2+: omap2plus_defconfig: Enable RTC support Colin Foe-Parker (1): rtc: OMAP: Add system pm_power_off to rtc driver Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++ arch/arm/boot/dts/am335x-bone.dts |6 ++ arch/arm/configs/omap2plus_defconfig |1 + drivers/rtc/rtc-omap.c | 74 +++- 4 files changed, 85 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] usb: phy: samsung: Add support to set pmu isolation
On 01/11/2013 09:08 AM, Vivek Gautam wrote: Adding support to parse device node data in order to get required properties to set pmu isolation for usb-phy. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Thanks for addressing my all comments, Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v4 1/4] rtc: OMAP: Add system pm_power_off to rtc driver
On Fri, Jan 11, 2013 at 14:24:46, Russ Dill wrote:
On Fri, Jan 11, 2013 at 12:08 AM, Russ Dill russ.d...@gmail.com wrote:
On Thu, Dec 13, 2012 at 10:03 PM, AnilKumar Ch anilku...@ti.com wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
Looks good
Reviewed-by: Russ Dill russ.d...@ti.com
Acked-by: Russ Dill russ.d...@ti.com
Sorry, actually, small follow up. Is there any reason this uses
readl/writel in some places rather than rtc_read/rtc_write?
Hi Russ Dill,
Thanks for the review
At OMAP_RTC_PMIC_POWER_EN_EN, 32-bit value needs to modified so
readl/writel are used. While enabling the INTERRUPTS we can change
it to rtc_read/rtc_write but I am not seeing any advantage if we
do that apart from consistency.
Thanks
AnilKumar
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 74
+++-
2 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..e6d4878 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG0x84
+#define OMAP_RTC_ALARM2_HOURS_REG 0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG 0x94
+#define OMAP_RTC_PMIC_REG 0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -93,15 +101,21 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC 2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +304,56 @@ static int omap_rtc_set_alarm(struct device *dev,
struct rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ unsigned long time;
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base +
OMAP_RTC_PMIC_REG);
+
+ /* Read rtc time */
+ omap_rtc_read_time(NULL, tm);
+
+ /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
+ rtc_tm_to_time(tm, time);
+
+ /* Add shutdown time to the current value */
+ time += SHUTDOWN_TIME_SEC;
+
+ /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
+ rtc_time_to_tm(time, tm);
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /*
+* pmic_pwr_enable is controlled by means of ALARM2 event. So here
+
RE: [PATCH v4 1/4] rtc: OMAP: Add system pm_power_off to rtc driver
On Fri, Jan 11, 2013 at 15:00:03, AnilKumar, Chimata wrote:
On Fri, Jan 11, 2013 at 14:24:46, Russ Dill wrote:
On Fri, Jan 11, 2013 at 12:08 AM, Russ Dill russ.d...@gmail.com wrote:
On Thu, Dec 13, 2012 at 10:03 PM, AnilKumar Ch anilku...@ti.com wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
Looks good
Reviewed-by: Russ Dill russ.d...@ti.com
Acked-by: Russ Dill russ.d...@ti.com
Sorry, actually, small follow up. Is there any reason this uses
readl/writel in some places rather than rtc_read/rtc_write?
Hi Russ Dill,
Thanks for the review
At OMAP_RTC_PMIC_POWER_EN_EN, 32-bit value needs to modified so
readl/writel are used. While enabling the INTERRUPTS we can change
it to rtc_read/rtc_write but I am not seeing any advantage if we
do that apart from consistency.
And driver has to clean-up properly to make use of rtc_read/write
APIs with proper read/write's based on the memory type. Ideally
rtc_readb/w/l and rtc_writeb/w/l should go way from the driver.
This clean-up can be done while converting the driver with platform
specific rtc_read/write.
Thanks
AnilKumar
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 74
+++-
2 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..e6d4878 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG0x84
+#define OMAP_RTC_ALARM2_HOURS_REG 0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG 0x94
+#define OMAP_RTC_PMIC_REG 0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -93,15 +101,21 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC 2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +304,56 @@ static int omap_rtc_set_alarm(struct device *dev,
struct rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ unsigned long time;
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base +
OMAP_RTC_PMIC_REG);
+
+ /* Read rtc time */
+ omap_rtc_read_time(NULL, tm);
+
+ /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
+ rtc_tm_to_time(tm, time);
+
+ /* Add
Re: [PATCH] usb: phy: samsung: Add support to set pmu isolation
Hi Sylwester, On Fri, Jan 11, 2013 at 2:51 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 01/11/2013 09:08 AM, Vivek Gautam wrote: Adding support to parse device node data in order to get required properties to set pmu isolation for usb-phy. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Thanks for addressing my all comments, Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Thanks for the review and help. :-) -- Thanks Regards Vivek ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: DT cpu map validity check helper function
On Thu, Jan 10, 2013 at 04:43:03PM +, Rob Herring wrote:
On 01/10/2013 05:48 AM, Lorenzo Pieralisi wrote:
Since the introduction of /cpu nodes bindings for ARM and the
corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
and the number of possible CPUs are set according to the DT /cpu
nodes entries. Currently most of the existing ARM SMP platforms detect the
number of cores through HW probing in their .smp_init_cpus functions and set
the possible CPU mask accordingly.
This method should be upgraded so that the CPU counting mechanism will be
based on DT, keeping legacy HW probing mechanism as a fall back solution.
In order to implement this fall back solution mechanism, the ARM DT code
should provide a helper function to platforms to check if the cpu map
has been properly initialized through DT. If the check fails the
platform will resort to legacy HW based cores counting mechanism.
This patch implements a trivial flag and a helper function that platform
can call to check whether DT based cpu map initialization and cores count
were completed successfully.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/include/asm/prom.h | 10 ++
arch/arm/kernel/devtree.c | 5 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index a219227..487614a 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -18,6 +18,15 @@
extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
extern void __init arm_dt_init_cpu_maps(void);
+/*
+ * Return true if cpu map initialization has been
+ * carried out correctly from DT
+ */
+static inline bool __init arm_dt_cpu_map_valid(void)
+{
+ extern bool valid_dt_cpu_map;
+ return valid_dt_cpu_map;
+}
#else /* CONFIG_OF */
@@ -28,6 +37,7 @@ static inline struct machine_desc
*setup_machine_fdt(unsigned int dt_phys)
static inline void arm_dt_memblock_reserve(void) { }
static inline void arm_dt_init_cpu_maps(void) { }
+static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..c82af3b 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -62,6 +62,10 @@ void __init arm_dt_memblock_reserve(void)
memblock_reserve(base, size);
}
}
+/*
+ * Export DT cpu map validity flag to platforms
+ */
+bool valid_dt_cpu_map __initdata;
/*
* arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
@@ -158,6 +162,7 @@ void __init arm_dt_init_cpu_maps(void)
* a reg property, the DT CPU list can be considered valid and the
* logical map created in smp_setup_processor_id() can be overridden
*/
+ valid_dt_cpu_map = true;
for (i = 0; i cpuidx; i++) {
set_cpu_possible(i, true);
I don't see why we need another variable. Doesn't cpu_possible mask
being set here imply that the DT map is valid.
Yes, that's correct I can use cpu_possible mask to check that, but I still
want to do it through a function/macro, I do not want platform code to
check possible mask explicitly, they have to do it through a helper function.
I will remove the variable.
We should start requiring valid /cpus nodes and the legacy fall-back
should be temporary.
I could not agree more.
Thanks,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: DT cpu map validity check helper function
On Thu, Jan 10, 2013 at 04:16:43PM +, Nicolas Pitre wrote:
On Thu, 10 Jan 2013, Lorenzo Pieralisi wrote:
On Thu, Jan 10, 2013 at 12:15:14PM +, Dave Martin wrote:
On Thu, Jan 10, 2013 at 11:48:27AM +, Lorenzo Pieralisi wrote:
Since the introduction of /cpu nodes bindings for ARM and the
corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
and the number of possible CPUs are set according to the DT /cpu
nodes entries. Currently most of the existing ARM SMP platforms detect
the
number of cores through HW probing in their .smp_init_cpus functions
and set
the possible CPU mask accordingly.
This method should be upgraded so that the CPU counting mechanism will
be
based on DT, keeping legacy HW probing mechanism as a fall back
solution.
In order to implement this fall back solution mechanism, the ARM DT code
should provide a helper function to platforms to check if the cpu map
has been properly initialized through DT. If the check fails the
platform will resort to legacy HW based cores counting mechanism.
This patch implements a trivial flag and a helper function that platform
can call to check whether DT based cpu map initialization and cores
count
were completed successfully.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/include/asm/prom.h | 10 ++
arch/arm/kernel/devtree.c | 5 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index a219227..487614a 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -18,6 +18,15 @@
extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
extern void __init arm_dt_init_cpu_maps(void);
+/*
+ * Return true if cpu map initialization has been
+ * carried out correctly from DT
+ */
+static inline bool __init arm_dt_cpu_map_valid(void)
+{
+ extern bool valid_dt_cpu_map;
+ return valid_dt_cpu_map;
+}
#else /* CONFIG_OF */
@@ -28,6 +37,7 @@ static inline struct machine_desc
*setup_machine_fdt(unsigned int dt_phys)
static inline void arm_dt_memblock_reserve(void) { }
static inline void arm_dt_init_cpu_maps(void) { }
+static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..c82af3b 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -62,6 +62,10 @@ void __init arm_dt_memblock_reserve(void)
memblock_reserve(base, size);
}
}
+/*
+ * Export DT cpu map validity flag to platforms
+ */
+bool valid_dt_cpu_map __initdata;
Is there any possibility of this being useful after boot?
Hopefully not, but maybe there's something I haven't considered.
I do not think so, at least for the use cases I have envisaged at the
moment,
but it is certainly something I should consider.
Let's simply adjust the code in the future if that ever becomes the
case.
I will check against cpu_possible_mask, that will solve the problem and
avoid this niggle.
Thanks,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] serial/arc-uart: switch to devicetree based probing
On Friday 11 January 2013, Vineet Gupta wrote: * DT binding for arc-uart * With alll the bits in place we can now use DT probing. Note that there's a bit of kludge right now because earlyprintk portion of driver can't use the DT infrastrcuture to get resoures/plat_data. This requires some infrastructre changes to of_flat_ framework Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Arnd Bergmann a...@arndb.de Cc: linux-ser...@vger.kernel.org Cc: Alan Cox a...@linux.intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: devicetree-discuss@lists.ozlabs.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: linux-ser...@vger.kernel.org Acked-by: Arnd Bergmann a...@arndb.de Quick question about the name though: is this UART only used on ARC, or is it something that synopsys licenses to other parties as well? If the latter is true, we might want to add a more generic compatible value for those that use it on another architecture. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 00/14] DMA Engine support for AM33XX
On Friday 11 January 2013, Matt Porter wrote: The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx only boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. I think this looks very good. What I wonder is whether we should make the non-DT parts of the dmaengine driver compile-time conditional on CONFIG_ATAGS though, so the slave drivers don't have a link-time dependency on the dmaengine driver's omap_dma_filter_fn symbol when building without ATAGS support. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Hi Doug, Sorry!! for the delayed response. On Thu, Dec 20, 2012 at 4:31 AM, Doug Anderson diand...@chromium.org wrote: Vivek, I don't really have a good 1 foot view about how all of the USB bits fit together, but a few detail-oriented comments below. On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote: This patch adds host phy support to samsung-usbphy.c and further adds support for samsung's exynos5250 usb-phy. Signed-off-by: Praveen Paneri p.pan...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- .../devicetree/bindings/usb/samsung-usbphy.txt | 25 +- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 465 ++-- include/linux/usb/samsung_usb_phy.h| 13 + 4 files changed, 454 insertions(+), 51 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt index a7b28b2..2ec5400 100644 --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -1,23 +1,38 @@ * Samsung's usb phy transceiver -The Samsung's phy transceiver is used for controlling usb otg phy for -s3c-hsotg usb device controller. +The Samsung's phy transceiver is used for controlling usb phy for +s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers +across Samsung SOCs. TODO: Adding the PHY binding with controller(s) according to the under developement generic PHY driver. Required properties: + +Exynos4210: - compatible : should be samsung,exynos4210-usbphy - reg : base physical address of the phy registers and length of memory mapped region. +Exynos5250: +- compatible : should be samsung,exynos5250-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. + Optional properties: - samsung,usb-phyhandle : should point to usb-phyhandle sub-node which provides binding data to enable/disable device PHY handled by - PMU register. + PMU register; or to configure usb2.0 phy handled by + SYSREG. Required properties: - compatible : should be samsung,usbdev-phyctrl for - DEVICE type phy. + DEVICE type phy; or + should be samsung,usbhost-phyctrl for + HOST type phy; or + should be samsung,usb-phycfg for + USB2.0 PHY_CFG. - samsung,phyhandle-reg: base physical address of - PHY_CONTROL register in PMU. +PHY_CONTROL register in PMU; +or USB2.0 PHY_CFG register +in SYSREG. - samsung,enable-mask : should be '1' diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 17ad743..13c0eaf 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -47,7 +47,7 @@ config USB_RCAR_PHY config SAMSUNG_USBPHY bool Samsung USB PHY controller Driver - depends on USB_S3C_HSOTG + depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS select USB_OTG_UTILS help Enable this to support Samsung USB phy controller for samsung diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c index 4ceabe3..621348a 100644 --- a/drivers/usb/phy/samsung-usbphy.c +++ b/drivers/usb/phy/samsung-usbphy.c @@ -5,7 +5,8 @@ * * Author: Praveen Paneri p.pan...@samsung.com * - * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * Samsung USB-PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and + * OHCI-EXYNOS controllers. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -24,7 +25,7 @@ #include linux/err.h #include linux/io.h #include linux/of.h -#include linux/usb/otg.h +#include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h /* Register definitions */ @@ -56,6 +57,103 @@ #define RSTCON_HLINK_SWRST (0x1 1) #define RSTCON_SWRST (0x1 0) +/* EXYNOS5 */ +#define EXYNOS5_PHY_HOST_CTRL0 (0x00) + +#define HOST_CTRL0_PHYSWRSTALL (0x1 31) + +#define HOST_CTRL0_REFCLKSEL_MASK (0x3) +#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19) +#define HOST_CTRL0_REFCLKSEL_EXTL
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Hi, On Fri, Jan 11, 2013 at 06:10:48PM +0530, Vivek Gautam wrote: Hi Doug, Sorry!! for the delayed response. On Thu, Dec 20, 2012 at 4:31 AM, Doug Anderson diand...@chromium.org wrote: Vivek, I don't really have a good 1 foot view about how all of the USB bits fit together, but a few detail-oriented comments below. On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote: This patch adds host phy support to samsung-usbphy.c and further adds support for samsung's exynos5250 usb-phy. Signed-off-by: Praveen Paneri p.pan...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- .../devicetree/bindings/usb/samsung-usbphy.txt | 25 +- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 465 ++-- include/linux/usb/samsung_usb_phy.h| 13 + 4 files changed, 454 insertions(+), 51 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt index a7b28b2..2ec5400 100644 --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -1,23 +1,38 @@ * Samsung's usb phy transceiver -The Samsung's phy transceiver is used for controlling usb otg phy for -s3c-hsotg usb device controller. +The Samsung's phy transceiver is used for controlling usb phy for +s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers +across Samsung SOCs. TODO: Adding the PHY binding with controller(s) according to the under developement generic PHY driver. Required properties: + +Exynos4210: - compatible : should be samsung,exynos4210-usbphy - reg : base physical address of the phy registers and length of memory mapped region. +Exynos5250: +- compatible : should be samsung,exynos5250-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. + Optional properties: - samsung,usb-phyhandle : should point to usb-phyhandle sub-node which provides binding data to enable/disable device PHY handled by - PMU register. + PMU register; or to configure usb2.0 phy handled by + SYSREG. Required properties: - compatible : should be samsung,usbdev-phyctrl for - DEVICE type phy. + DEVICE type phy; or + should be samsung,usbhost-phyctrl for + HOST type phy; or + should be samsung,usb-phycfg for + USB2.0 PHY_CFG. - samsung,phyhandle-reg: base physical address of - PHY_CONTROL register in PMU. +PHY_CONTROL register in PMU; +or USB2.0 PHY_CFG register +in SYSREG. - samsung,enable-mask : should be '1' diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 17ad743..13c0eaf 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -47,7 +47,7 @@ config USB_RCAR_PHY config SAMSUNG_USBPHY bool Samsung USB PHY controller Driver - depends on USB_S3C_HSOTG + depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS select USB_OTG_UTILS help Enable this to support Samsung USB phy controller for samsung diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c index 4ceabe3..621348a 100644 --- a/drivers/usb/phy/samsung-usbphy.c +++ b/drivers/usb/phy/samsung-usbphy.c @@ -5,7 +5,8 @@ * * Author: Praveen Paneri p.pan...@samsung.com * - * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * Samsung USB-PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and + * OHCI-EXYNOS controllers. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -24,7 +25,7 @@ #include linux/err.h #include linux/io.h #include linux/of.h -#include linux/usb/otg.h +#include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h /* Register definitions */ @@ -56,6 +57,103 @@ #define RSTCON_HLINK_SWRST (0x1 1) #define RSTCON_SWRST (0x1 0) +/* EXYNOS5 */ +#define EXYNOS5_PHY_HOST_CTRL0 (0x00) + +#define
Re: [PATCH V2 2/2] ARM: dts: OMAP2+: Add PMU nodes
Hi Jon,
On 12/17/2012 06:49 PM, Jon Hunter wrote:
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter jon-hun...@ti.com
I've just applied this patch in my for_3.9/dts branch.
I'm wondering if there is any dependency with the previous patch? If
Tony ack it I can take it as well.
Regards,
Benoit
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
4 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = arm,arm1136-pmu;
+ interrupts = 3;
+ };
+
soc {
compatible = ti,omap-infra;
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6c63118 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = arm,cortex-a8-pmu;
+ interrupts = 3;
+ ti,hwmods = debugss;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ omap4-panda.dts
+/include/ omap4460.dtsi
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..0a1d38b
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupts = 0 54 0x4,
+ 0 55 0x4;
+ ti,hwmods = debugss;
+ };
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Hi Felipe, On Fri, Jan 11, 2013 at 6:28 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Jan 11, 2013 at 06:10:48PM +0530, Vivek Gautam wrote: Hi Doug, Sorry!! for the delayed response. On Thu, Dec 20, 2012 at 4:31 AM, Doug Anderson diand...@chromium.org wrote: Vivek, I don't really have a good 1 foot view about how all of the USB bits fit together, but a few detail-oriented comments below. On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote: This patch adds host phy support to samsung-usbphy.c and further adds support for samsung's exynos5250 usb-phy. Signed-off-by: Praveen Paneri p.pan...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- .../devicetree/bindings/usb/samsung-usbphy.txt | 25 +- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 465 ++-- include/linux/usb/samsung_usb_phy.h| 13 + 4 files changed, 454 insertions(+), 51 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt index a7b28b2..2ec5400 100644 --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -1,23 +1,38 @@ * Samsung's usb phy transceiver -The Samsung's phy transceiver is used for controlling usb otg phy for -s3c-hsotg usb device controller. +The Samsung's phy transceiver is used for controlling usb phy for +s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers +across Samsung SOCs. TODO: Adding the PHY binding with controller(s) according to the under developement generic PHY driver. Required properties: + +Exynos4210: - compatible : should be samsung,exynos4210-usbphy - reg : base physical address of the phy registers and length of memory mapped region. +Exynos5250: +- compatible : should be samsung,exynos5250-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. + Optional properties: - samsung,usb-phyhandle : should point to usb-phyhandle sub-node which provides binding data to enable/disable device PHY handled by - PMU register. + PMU register; or to configure usb2.0 phy handled by + SYSREG. Required properties: - compatible : should be samsung,usbdev-phyctrl for - DEVICE type phy. + DEVICE type phy; or + should be samsung,usbhost-phyctrl for + HOST type phy; or + should be samsung,usb-phycfg for + USB2.0 PHY_CFG. - samsung,phyhandle-reg: base physical address of - PHY_CONTROL register in PMU. +PHY_CONTROL register in PMU; +or USB2.0 PHY_CFG register +in SYSREG. - samsung,enable-mask : should be '1' diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 17ad743..13c0eaf 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -47,7 +47,7 @@ config USB_RCAR_PHY config SAMSUNG_USBPHY bool Samsung USB PHY controller Driver - depends on USB_S3C_HSOTG + depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS select USB_OTG_UTILS help Enable this to support Samsung USB phy controller for samsung diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c index 4ceabe3..621348a 100644 --- a/drivers/usb/phy/samsung-usbphy.c +++ b/drivers/usb/phy/samsung-usbphy.c @@ -5,7 +5,8 @@ * * Author: Praveen Paneri p.pan...@samsung.com * - * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * Samsung USB-PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and + * OHCI-EXYNOS controllers. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -24,7 +25,7 @@ #include linux/err.h #include linux/io.h #include linux/of.h -#include linux/usb/otg.h +#include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h /* Register definitions */ @@ -56,6 +57,103 @@ #define RSTCON_HLINK_SWRST (0x1 1) #define RSTCON_SWRST (0x1 0) +/*
Re: [PATCH V2 2/2] ARM: dts: OMAP2+: Add PMU nodes
Hi Benoit, On 01/11/2013 07:23 AM, Benoit Cousson wrote: Hi Jon, On 12/17/2012 06:49 PM, Jon Hunter wrote: Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices. Please note that the node for OMAP4460 has been placed in a separate header file for OMAP4460, because the node is not compatible with OMAP4430. The node for OMAP4430 is not included because PMU is not currently supported on OMAP4430 due to the absence of a cross-trigger interface driver. Signed-off-by: Jon Hunter jon-hun...@ti.com I've just applied this patch in my for_3.9/dts branch. I'm wondering if there is any dependency with the previous patch? If Tony ack it I can take it as well. I have been thinking about the best way to handle that. May be best for you to take both if Tony can ack the first. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 01/14] ARM: davinci: move private EDMA API to arm/common
On Fri, Jan 11, 2013 at 06:15:06AM +, Hebbar, Gururaja wrote:
On Fri, Jan 11, 2013 at 11:18:37, Porter, Matt wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API and enables it to build on OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c = common/edma.c} |2 +-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|7 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
arch/arm/mach-davinci/include/mach/edma.h | 267
arch/arm/plat-omap/Kconfig |1 +
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
include/linux/platform_data/edma.h | 182
Headers file are just moved here. So git mv file1 flie2; and the git
format-patch -C on commit should just generate few lines of patch.
Ok, good catch.
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |6 +-
25 files changed, 212 insertions(+), 288 deletions(-)
rename arch/arm/{mach-davinci/dma.c = common/edma.c} (99%)
delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h
create mode 100644 include/linux/platform_data/edma.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..4411087 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include linux/io.h
#include linux/slab.h
-#include mach/edma.h
+#include linux/platform_data/edma.h
/* Offsets matching struct edmacc_param */
#define PARM_OPT 0x00
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..493a36b 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o psc.o \
- dma.o usb.o common.o sram.o aemif.o
+ usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index be30997..86f55ba 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
+#include linux/platform_data/edma.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include mach/irqs.h
-#include mach/edma.h
#include mach/mux.h
#include mach/cp_intc.h
#include mach/tnetv107x.h
diff --git a/arch/arm/mach-davinci/davinci.h
b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
---
Re: [PATCH v4 05/14] dmaengine: edma: Add TI EDMA device tree binding
On Fri, Jan 11, 2013 at 07:54:05AM +, Hebbar, Gururaja wrote:
On Fri, Jan 11, 2013 at 11:18:41, Porter, Matt wrote:
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 51
+
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..3344345
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,51 @@
+TI EDMA
+
+Required properties:
+- compatible : ti,edma3
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ #address-cells = 1;
+ #size-cells = 0;
address-cells size-cells are only required when current node is a parent
node it has sibling/child nodes (that too if the child node uses reg
property).
Yes, agreed. I addressed this in the actual dts but failed to update the
binding itself. Will update.
+ reg = 0x4900 0x1;
+ interrupt-parent = intc;
+ interrupts = 12 13 14;
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ ti,edma-reserved-channels = 0 2
+14 2
+26 6
+48 4
+56 8;
+ ti,edma-reserved-slots = 0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127;
+ ti,edma-queue-tc-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-queue-priority-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-default-queue = 0;
+ ti,edma-xbar-event-map = 1 12
+ 2 13;
+};
--
1.7.9.5
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Regards,
Gururaja
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 0/4] Adding usb2.0 host-phy support for exynos5250
Changes from v5: - Rebased on top of latest patches: usb: phy: samsung: Introducing usb phy driver for hsotg (v9) usb: phy: samsung: Add support to set pmu isolation (v6) As a result adding hostphy enable mask and hostphy register offsets to driver data in order to access the HOSTPHY CONTROL register. - Adding member 'otg' to struct samsung-usbphy so that its consumers can call otg-set_host so as to make 'phy' aware of the consumer type: HOST/DEVICE - Adding 'otg' to 'struct s5p_ehci_hcd' and 'struct exynos_ohci_hcd' which keeps track of 'otg' of the controllers' phy. This then sets the host. - Moved samsung_usbphy_set_type() calls from ehci-s5p and ohci-exynos to phy driver itself where based on phy_type it is called. - Added separate macro definition for USB20PHY_CFG register to select between host/device type usb link. - Removing unnecessary argument 'phy_type' from samsung_usbphy_set_type() and samsung_usbphy_cfg_sel(). - Addressed few nits: -- added macro for 'KHZ' -- removing useless 'if' from samsung_usbphy_cfg_sel() -- keeping the place of clk_get intact and requesting driver data before that. Vivek Gautam (4): ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/host/ehci-s5p.c| 81 +++- drivers/usb/host/ohci-exynos.c | 85 +++- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 512 ++-- include/linux/usb/samsung_usb_phy.h| 16 + 6 files changed, 635 insertions(+), 73 deletions(-) create mode 100644 include/linux/usb/samsung_usb_phy.h -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 1/4] ARM: EXYNOS: Update move usb-phy types to generic include layer
Updating the names of usb-phy types to more generic names:
USB_PHY_TYPE_DEIVCE USB_PHY_TYPE_HOST; and further update
its dependencies.
Signed-off-by: Praveen Paneri p.pan...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v5:
- None
drivers/usb/host/ehci-s5p.c |9 +
drivers/usb/host/ohci-exynos.c |9 +
include/linux/usb/samsung_usb_phy.h | 16
3 files changed, 26 insertions(+), 8 deletions(-)
create mode 100644 include/linux/usb/samsung_usb_phy.h
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 319dcfa..46ca5ef 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -17,6 +17,7 @@
#include linux/platform_device.h
#include linux/of_gpio.h
#include linux/platform_data/usb-ehci-s5p.h
+#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
#define EHCI_INSNREG00(base) (base + 0x90)
@@ -164,7 +165,7 @@ static int s5p_ehci_probe(struct platform_device *pdev)
}
if (pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ehci = hcd_to_ehci(hcd);
ehci-caps = hcd-regs;
@@ -198,7 +199,7 @@ static int s5p_ehci_remove(struct platform_device *pdev)
usb_remove_hcd(hcd);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(s5p_ehci-clk);
@@ -229,7 +230,7 @@ static int s5p_ehci_suspend(struct device *dev)
rc = ehci_suspend(hcd, do_wakeup);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(s5p_ehci-clk);
@@ -246,7 +247,7 @@ static int s5p_ehci_resume(struct device *dev)
clk_prepare_enable(s5p_ehci-clk);
if (pdata pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
/* DMA burst Enable */
writel(EHCI_INSNREG00_ENABLE_DMA_BURST, EHCI_INSNREG00(hcd-regs));
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index aa3b884..804fb62 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -15,6 +15,7 @@
#include linux/of.h
#include linux/platform_device.h
#include linux/platform_data/usb-exynos.h
+#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
struct exynos_ohci_hcd {
@@ -153,7 +154,7 @@ static int exynos_ohci_probe(struct platform_device *pdev)
}
if (pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
@@ -184,7 +185,7 @@ static int exynos_ohci_remove(struct platform_device *pdev)
usb_remove_hcd(hcd);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(exynos_ohci-clk);
@@ -229,7 +230,7 @@ static int exynos_ohci_suspend(struct device *dev)
clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(exynos_ohci-clk);
@@ -249,7 +250,7 @@ static int exynos_ohci_resume(struct device *dev)
clk_prepare_enable(exynos_ohci-clk);
if (pdata pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ohci_resume(hcd, false);
diff --git a/include/linux/usb/samsung_usb_phy.h
b/include/linux/usb/samsung_usb_phy.h
new file mode 100644
index 000..9167826
--- /dev/null
+++ b/include/linux/usb/samsung_usb_phy.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * http://www.samsung.com/
+ *
+ * Defines phy types for samsung usb phy controllers - HOST or DEIVCE.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+enum samsung_usb_phy_type {
+ USB_PHY_TYPE_DEVICE,
+ USB_PHY_TYPE_HOST,
+};
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
This patch adds host phy support to samsung-usbphy driver and further adds support for samsung's exynos5250 usb-phy. Signed-off-by: Praveen Paneri p.pan...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 512 ++-- 3 files changed, 495 insertions(+), 31 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt index 22d06cf..0331949 100644 --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -1,15 +1,23 @@ * Samsung's usb phy transceiver -The Samsung's phy transceiver is used for controlling usb otg phy for -s3c-hsotg usb device controller. +The Samsung's phy transceiver is used for controlling usb phy for +s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers +across Samsung SOCs. TODO: Adding the PHY binding with controller(s) according to the under developement generic PHY driver. Required properties: + +Exynos4210: - compatible : should be samsung,exynos4210-usbphy - reg : base physical address of the phy registers and length of memory mapped region. +Exynos5250: +- compatible : should be samsung,exynos5250-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. + Optional properties: - #address-cells: should be '1' when usbphy node has a child node with 'reg' property. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 36a85b6..fae4d08 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -48,7 +48,7 @@ config USB_RCAR_PHY config SAMSUNG_USBPHY bool Samsung USB PHY controller Driver - depends on USB_S3C_HSOTG + depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS select USB_OTG_UTILS help Enable this to support Samsung USB phy controller for samsung diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c index 7eec7c3..d2b6642 100644 --- a/drivers/usb/phy/samsung-usbphy.c +++ b/drivers/usb/phy/samsung-usbphy.c @@ -5,7 +5,8 @@ * * Author: Praveen Paneri p.pan...@samsung.com * - * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * Samsung USB2.0 PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and + * OHCI-EXYNOS controllers. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -21,11 +22,13 @@ #include linux/platform_device.h #include linux/clk.h #include linux/delay.h +#include linux/device.h #include linux/err.h #include linux/io.h #include linux/of.h #include linux/of_address.h #include linux/usb/otg.h +#include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h /* Register definitions */ @@ -57,24 +60,131 @@ #define RSTCON_HLINK_SWRST (0x1 1) #define RSTCON_SWRST (0x1 0) +/* EXYNOS5 */ +#define EXYNOS5_PHY_HOST_CTRL0 (0x00) + +#define HOST_CTRL0_PHYSWRSTALL (0x1 31) + +#define HOST_CTRL0_REFCLKSEL_MASK (0x3) +#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19) +#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 19) +#define HOST_CTRL0_REFCLKSEL_CLKCORE (0x2 19) + +#define HOST_CTRL0_FSEL_MASK (0x7 16) +#define HOST_CTRL0_FSEL(_x)((_x) 16) +#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7) +#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5) +#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4) +#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3) +#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2) +#define HOST_CTRL0_FSEL_CLKSEL_10M (0x1) +#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0) + +#define HOST_CTRL0_TESTBURNIN (0x1 11) +#define HOST_CTRL0_RETENABLE (0x1 10) +#define HOST_CTRL0_COMMONON_N (0x1 9) +#define HOST_CTRL0_SIDDQ (0x1 6) +#define HOST_CTRL0_FORCESLEEP (0x1 5) +#define HOST_CTRL0_FORCESUSPEND(0x1 4) +#define HOST_CTRL0_WORDINTERFACE (0x1 3) +#define HOST_CTRL0_UTMISWRST (0x1 2) +#define HOST_CTRL0_LINKSWRST (0x1 1) +#define HOST_CTRL0_PHYSWRST(0x1 0) + +#define EXYNOS5_PHY_HOST_TUNE0 (0x04) + +#define EXYNOS5_PHY_HSIC_CTRL1 (0x10) + +#define EXYNOS5_PHY_HSIC_TUNE1 (0x14) + +#define EXYNOS5_PHY_HSIC_CTRL2 (0x20) + +#define EXYNOS5_PHY_HSIC_TUNE2 (0x24) + +#define HSIC_CTRL_REFCLKSEL_MASK
[PATCH v6 3/4] USB: ehci-s5p: Add phy driver support
Adding the phy driver to ehci-s5p. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/ehci-s5p.c | 80 +++---
1 files changed, 59 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 46ca5ef..d603e6e 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -17,6 +17,7 @@
#include linux/platform_device.h
#include linux/of_gpio.h
#include linux/platform_data/usb-ehci-s5p.h
+#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
@@ -33,6 +34,9 @@ struct s5p_ehci_hcd {
struct device *dev;
struct usb_hcd *hcd;
struct clk *clk;
+ struct usb_phy *phy;
+ struct usb_otg *otg;
+ struct s5p_ehci_platdata *pdata;
};
static const struct hc_driver s5p_ehci_hc_driver = {
@@ -66,6 +70,26 @@ static const struct hc_driver s5p_ehci_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static void s5p_ehci_phy_enable(struct s5p_ehci_hcd *s5p_ehci)
+{
+ struct platform_device *pdev = to_platform_device(s5p_ehci-dev);
+
+ if (s5p_ehci-phy)
+ usb_phy_init(s5p_ehci-phy);
+ else if (s5p_ehci-pdata-phy_init)
+ s5p_ehci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
+}
+
+static void s5p_ehci_phy_disable(struct s5p_ehci_hcd *s5p_ehci)
+{
+ struct platform_device *pdev = to_platform_device(s5p_ehci-dev);
+
+ if (s5p_ehci-phy)
+ usb_phy_shutdown(s5p_ehci-phy);
+ else if (s5p_ehci-pdata-phy_exit)
+ s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
+}
+
static void s5p_setup_vbus_gpio(struct platform_device *pdev)
{
int err;
@@ -88,20 +112,15 @@ static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
static int s5p_ehci_probe(struct platform_device *pdev)
{
- struct s5p_ehci_platdata *pdata;
+ struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci;
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
+ struct usb_phy *phy;
int irq;
int err;
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(pdev-dev, No platform data defined\n);
- return -EINVAL;
- }
-
/*
* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
@@ -119,6 +138,20 @@ static int s5p_ehci_probe(struct platform_device *pdev)
if (!s5p_ehci)
return -ENOMEM;
+ phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR_OR_NULL(phy)) {
+ /* Fallback to pdata */
+ if (!pdata) {
+ dev_warn(pdev-dev, no platform data or transceiver
defined\n);
+ return -EPROBE_DEFER;
+ } else {
+ s5p_ehci-pdata = pdata;
+ }
+ } else {
+ s5p_ehci-phy = phy;
+ s5p_ehci-otg = phy-otg;
+ }
+
s5p_ehci-dev = pdev-dev;
hcd = usb_create_hcd(s5p_ehci_hc_driver, pdev-dev,
@@ -164,8 +197,10 @@ static int s5p_ehci_probe(struct platform_device *pdev)
goto fail_io;
}
- if (pdata-phy_init)
- pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
+ if (s5p_ehci-otg)
+ s5p_ehci-otg-set_host(s5p_ehci-otg, s5p_ehci-hcd-self);
+
+ s5p_ehci_phy_enable(s5p_ehci);
ehci = hcd_to_ehci(hcd);
ehci-caps = hcd-regs;
@@ -176,13 +211,15 @@ static int s5p_ehci_probe(struct platform_device *pdev)
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
dev_err(pdev-dev, Failed to add USB HCD\n);
- goto fail_io;
+ goto fail_add_hcd;
}
platform_set_drvdata(pdev, s5p_ehci);
return 0;
+fail_add_hcd:
+ s5p_ehci_phy_disable(s5p_ehci);
fail_io:
clk_disable_unprepare(s5p_ehci-clk);
fail_clk:
@@ -192,14 +229,15 @@ fail_clk:
static int s5p_ehci_remove(struct platform_device *pdev)
{
- struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci = platform_get_drvdata(pdev);
struct usb_hcd *hcd = s5p_ehci-hcd;
usb_remove_hcd(hcd);
- if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
+ if (s5p_ehci-otg)
+ s5p_ehci-otg-set_host(s5p_ehci-otg, s5p_ehci-hcd-self);
+
+ s5p_ehci_phy_disable(s5p_ehci);
clk_disable_unprepare(s5p_ehci-clk);
@@ -223,14 +261,14 @@ static int s5p_ehci_suspend(struct device *dev)
struct s5p_ehci_hcd *s5p_ehci = dev_get_drvdata(dev);
[PATCH v6 4/4] USB: ohci-exynos: Add phy driver support
Adding the phy-driver to ohci-exynos. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/ohci-exynos.c | 84 ++--
1 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 804fb62..1b38409 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -15,6 +15,7 @@
#include linux/of.h
#include linux/platform_device.h
#include linux/platform_data/usb-exynos.h
+#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
@@ -22,8 +23,31 @@ struct exynos_ohci_hcd {
struct device *dev;
struct usb_hcd *hcd;
struct clk *clk;
+ struct usb_phy *phy;
+ struct usb_otg *otg;
+ struct exynos4_ohci_platdata *pdata;
};
+static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct platform_device *pdev = to_platform_device(exynos_ohci-dev);
+
+ if (exynos_ohci-phy)
+ usb_phy_init(exynos_ohci-phy);
+ else if (exynos_ohci-pdata-phy_init)
+ exynos_ohci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
+}
+
+static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct platform_device *pdev = to_platform_device(exynos_ohci-dev);
+
+ if (exynos_ohci-phy)
+ usb_phy_shutdown(exynos_ohci-phy);
+ else if (exynos_ohci-pdata-phy_exit)
+ exynos_ohci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
+}
+
static int ohci_exynos_reset(struct usb_hcd *hcd)
{
return ohci_init(hcd_to_ohci(hcd));
@@ -79,20 +103,15 @@ static u64 ohci_exynos_dma_mask = DMA_BIT_MASK(32);
static int exynos_ohci_probe(struct platform_device *pdev)
{
- struct exynos4_ohci_platdata *pdata;
+ struct exynos4_ohci_platdata *pdata = pdev-dev.platform_data;
struct exynos_ohci_hcd *exynos_ohci;
struct usb_hcd *hcd;
struct ohci_hcd *ohci;
struct resource *res;
+ struct usb_phy *phy;
int irq;
int err;
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(pdev-dev, No platform data defined\n);
- return -EINVAL;
- }
-
/*
* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
@@ -108,6 +127,20 @@ static int exynos_ohci_probe(struct platform_device *pdev)
if (!exynos_ohci)
return -ENOMEM;
+ phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR_OR_NULL(phy)) {
+ /* Fallback to pdata */
+ if (!pdata) {
+ dev_warn(pdev-dev, no platform data or transceiver
defined\n);
+ return -EPROBE_DEFER;
+ } else {
+ exynos_ohci-pdata = pdata;
+ }
+ } else {
+ exynos_ohci-phy = phy;
+ exynos_ohci-otg = phy-otg;
+ }
+
exynos_ohci-dev = pdev-dev;
hcd = usb_create_hcd(exynos_ohci_hc_driver, pdev-dev,
@@ -153,8 +186,11 @@ static int exynos_ohci_probe(struct platform_device *pdev)
goto fail_io;
}
- if (pdata-phy_init)
- pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
+ if (exynos_ohci-otg)
+ exynos_ohci-otg-set_host(exynos_ohci-otg,
+ exynos_ohci-hcd-self);
+
+ exynos_ohci_phy_enable(exynos_ohci);
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
@@ -162,13 +198,15 @@ static int exynos_ohci_probe(struct platform_device *pdev)
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
dev_err(pdev-dev, Failed to add USB HCD\n);
- goto fail_io;
+ goto fail_add_hcd;
}
platform_set_drvdata(pdev, exynos_ohci);
return 0;
+fail_add_hcd:
+ exynos_ohci_phy_disable(exynos_ohci);
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
@@ -178,14 +216,16 @@ fail_clk:
static int exynos_ohci_remove(struct platform_device *pdev)
{
- struct exynos4_ohci_platdata *pdata = pdev-dev.platform_data;
struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
struct usb_hcd *hcd = exynos_ohci-hcd;
usb_remove_hcd(hcd);
- if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
+ if (exynos_ohci-otg)
+ exynos_ohci-otg-set_host(exynos_ohci-otg,
+ exynos_ohci-hcd-self);
+
+ exynos_ohci_phy_disable(exynos_ohci);
clk_disable_unprepare(exynos_ohci-clk);
@@ -209,8 +249,6 @@ static int exynos_ohci_suspend(struct device *dev)
[PATCH 1/2] ARM: DT: tegra: Add Tegra30 Beaver board support
This patch adds support for Tegra30 Beaver board in upstream kernel.
Beaver board is a Tegra30 SoC based development board, it has
following features:
- T30 or T33 SoC (Qual core ARM Cortex A9)
- 2 GB DDR3L
- 16 GB EMMC
- 1 SD slot
- 1 USB Standart A port and 1 USB micro AB port
- PCI-E Gig Ethernet
- Audio input/output
- SATA port
- HDMI output
- UART and JTAG
Signed-off-by: Bryan Wu pe...@nvidia.com
---
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/tegra30-beaver.dts | 374 ++
2 files changed, 376 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/tegra30-beaver.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d077ef8..a71025c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -144,7 +144,8 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra20-ventana.dtb \
tegra20-whistler.dtb \
tegra30-cardhu-a02.dtb \
- tegra30-cardhu-a04.dtb
+ tegra30-cardhu-a04.dtb \
+ tegra30-beaver.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
vexpress-v2p-ca9.dtb \
vexpress-v2p-ca15-tc1.dtb \
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts
b/arch/arm/boot/dts/tegra30-beaver.dts
new file mode 100644
index 000..0f296a4
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -0,0 +1,374 @@
+/dts-v1/;
+
+/include/ tegra30.dtsi
+
+/ {
+ model = NVIDIA Tegra30 Beaver evaluation board;
+ compatible = nvidia,beaver, nvidia,tegra30;
+
+ memory {
+ reg = 0x8000 0x8000;
+ };
+
+ pinmux {
+ pinctrl-names = default;
+ pinctrl-0 = state_default;
+
+ state_default: pinmux {
+ sdmmc1_clk_pz0 {
+ nvidia,pins = sdmmc1_clk_pz0;
+ nvidia,function = sdmmc1;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc1_cmd_pz1 {
+ nvidia,pins = sdmmc1_cmd_pz1,
+ sdmmc1_dat0_py7,
+ sdmmc1_dat1_py6,
+ sdmmc1_dat2_py5,
+ sdmmc1_dat3_py4;
+ nvidia,function = sdmmc1;
+ nvidia,pull = 2;
+ nvidia,tristate = 0;
+ };
+ sdmmc3_clk_pa6 {
+ nvidia,pins = sdmmc3_clk_pa6;
+ nvidia,function = sdmmc3;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc3_cmd_pa7 {
+ nvidia,pins = sdmmc3_cmd_pa7,
+ sdmmc3_dat0_pb7,
+ sdmmc3_dat1_pb6,
+ sdmmc3_dat2_pb5,
+ sdmmc3_dat3_pb4;
+ nvidia,function = sdmmc3;
+ nvidia,pull = 2;
+ nvidia,tristate = 0;
+ };
+ sdmmc4_clk_pcc4 {
+ nvidia,pins = sdmmc4_clk_pcc4,
+ sdmmc4_rst_n_pcc3;
+ nvidia,function = sdmmc4;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc4_dat0_paa0 {
+ nvidia,pins = sdmmc4_dat0_paa0,
+ sdmmc4_dat1_paa1,
+ sdmmc4_dat2_paa2,
+ sdmmc4_dat3_paa3,
+ sdmmc4_dat4_paa4,
+ sdmmc4_dat5_paa5,
+ sdmmc4_dat6_paa6,
+ sdmmc4_dat7_paa7;
+ nvidia,function = sdmmc4;
+ nvidia,pull = 2;
+ nvidia,tristate = 0;
+ };
+ dap2_fs_pa2 {
+ nvidia,pins = dap2_fs_pa2,
+ dap2_sclk_pa3,
+ dap2_din_pa4,
+ dap2_dout_pa5;
+ nvidia,function = i2s1;
+ nvidia,pull = 0;
+
RE: [PATCH 1/4] ARM: dts: mxs-phy: Change mxs phy clock usage
On Thu, Jan 10, 2013 at 04:35:51PM +0800, Peter Chen wrote: For mxs-phy user i.mx6q, the PHY's clock is controlled by hardware automatically, the software only needs to enable it at probe, this clock should be used like below: - Enable at mxs-phy's probe, and disable at mxs-phy's remove, so The clk framework doesn't need to know it. But other mxs-phy user mx28/mx23 may need it, so we give mxs-phy a dummy clock for imx6q. - During the runtime, we don't need to control it. Turning it into a dummy clock, you will have no way to maintain the use count. It could possibly cause parent clock be turned off while usbphy is in use. Let's try to find some other way. I will keep the phyclk unchanged, but just let it control a reserved bit In that case, the clk framework will know USB is using PLL. Meanwhile, the real USB PHY clk gate will only be open one time at phy driver's probe. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] ARM: DT: tegra: Unify the description of Tegra20 boards
Use engineering name 'Tegra20' instead of 'Tegra2'
Signed-off-by: Bryan Wu pe...@nvidia.com
---
arch/arm/boot/dts/tegra20-harmony.dts |2 +-
arch/arm/boot/dts/tegra20-ventana.dts |2 +-
arch/arm/boot/dts/tegra20-whistler.dts |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts
b/arch/arm/boot/dts/tegra20-harmony.dts
index 43eb72a..b506de9 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -3,7 +3,7 @@
/include/ tegra20.dtsi
/ {
- model = NVIDIA Tegra2 Harmony evaluation board;
+ model = NVIDIA Tegra20 Harmony evaluation board;
compatible = nvidia,harmony, nvidia,tegra20;
memory {
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
b/arch/arm/boot/dts/tegra20-ventana.dts
index adc4754..0392dea 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -3,7 +3,7 @@
/include/ tegra20.dtsi
/ {
- model = NVIDIA Tegra2 Ventana evaluation board;
+ model = NVIDIA Tegra20 Ventana evaluation board;
compatible = nvidia,ventana, nvidia,tegra20;
memory {
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts
b/arch/arm/boot/dts/tegra20-whistler.dts
index 20d576e..5836ad6 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -3,7 +3,7 @@
/include/ tegra20.dtsi
/ {
- model = NVIDIA Tegra2 Whistler evaluation board;
+ model = NVIDIA Tegra20 Whistler evaluation board;
compatible = nvidia,whistler, nvidia,tegra20;
memory {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: Initial support for Tegra 114 SoC.
On 12/20/2012 05:43 PM, Hiroshi Doyu wrote: Hi, This patchset adds initial support for the NVIDIA's new Tegra 114 SoC (T114) based on the ARM Cortex-A15 MP. It has the minimal support to allow the kernel to boot up into shell console. This can be used as a basis for adding other device drivers for this SoC. Currently there are 2 evaluation boards available, Dalmore and Pluto. This patchset is against Stephen Warren's linux-next_common branch: git://nv-tegra.nvidia.com/user/swarren/linux-2.6 linux-next_common For those who want to try: $ make ARCH=arm tegra_defconfig $ scripts/config -e ARCH_TEGRA_114_SOC -d DRM -d SUSPEND \ -d PM_RUNTIME -d CPU_FREQ -d CPU_IDLE $ make ARCH=arm menuconfig # if needed to configure more I think we also need to enable: CONFIG_ARM_APPENDED_DTB CONFIG_ARM_ATAG_DTB_COMPAT because currently we append the dtb to the kernel image(will not do this after u-boot supports dalmore and we can load the dtb in u-boot cmd), so we need to make kernel being aware of this. My experience is after I enabled these 2 configs, kernel starts up normally. Mark $ make ARCH=arm all -j9 Verified that this single image booted up with Dalmore(T114), Pluto(T114) and Cardhu(T30). For Cardhu(T30) with this single image, SPI driver doesn't seem to afford the above configuration , it hangs at boot-up. With SPI disabled, it's ok. Hiroshi Doyu (9): ARM: tegra: fuse: Add chipid TEGRA114 0x35 HACK: ARM: tegra: Use CLK_IGNORE_UNUSED for Tegra 114 SoC ARM: tegra: # of CPU cores detection w/ w/o HAVE_ARM_SCU clocksource: tegra: Reorganize funcs by clock functionarities clocksource: tegra: Enable ARM arch_timer with TSC ARM: dt: tegra114: Add new SoC base, Tegra 114 SoC ARM: dt: tegra114: Add new board, Dalmore ARM: dt: tegra114: Add new board, Pluto ARM: tegra: Add initial support for Tegra 114 SoC. .../bindings/arm/tegra/nvidia,tegra114-tsc.txt | 11 + arch/arm/boot/dts/Makefile |4 +- arch/arm/boot/dts/tegra114-dalmore.dts | 21 ++ arch/arm/boot/dts/tegra114-pluto.dts | 21 ++ arch/arm/boot/dts/tegra114.dtsi| 89 arch/arm/mach-tegra/Kconfig| 10 + arch/arm/mach-tegra/Makefile |1 + arch/arm/mach-tegra/board-dt-tegra114.c| 48 + arch/arm/mach-tegra/common.c |1 + arch/arm/mach-tegra/fuse.h |1 + arch/arm/mach-tegra/platsmp.c | 31 ++- arch/arm/mach-tegra/tegra30_clocks_data.c |2 + drivers/clocksource/tegra20_timer.c| 222 +--- 13 files changed, 384 insertions(+), 78 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra114-tsc.txt create mode 100644 arch/arm/boot/dts/tegra114-dalmore.dts create mode 100644 arch/arm/boot/dts/tegra114-pluto.dts create mode 100644 arch/arm/boot/dts/tegra114.dtsi create mode 100644 arch/arm/mach-tegra/board-dt-tegra114.c ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] cpuidle: kirkwood: Move out of mach directory, add DT.
Hello Andrew,
Le 12/28/12 13:47, Andrew Lunn a écrit :
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into drivers/cpuidle. Convert the driver into a platform driver and
add a device tree binding. Add a DT node to instantiate the driver for
boards converted to DT, and a platform data for old style boards.
Signed-off-by: Andrew Lunn and...@lunn.ch
---
[snip]
+/*
+ * CPU idle
+ /
+static struct resource kirkwood_cpuidle_resource[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ .start = DDR_OPERATION_BASE,
+ .end= 3,
Should not this be DDR_OPERATION_BASE + 3?
--
Florian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: dts: omap3-igep: Add fixed always-on regulators to common dtsi file
These regulators are common to igep0020 and igep0030 boards
and are needed by smsc911x controller.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index dd01c46..91a42ce 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -24,6 +24,18 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+vddvario: regulator-vddvario {
+compatible = regulator-fixed;
+regulator-name = vddvario;
+regulator-always-on;
+};
+
+vdd33a: regulator-vdd33a {
+compatible = regulator-fixed;
+regulator-name = vdd33a;
+regulator-always-on;
+};
};
omap3_pmx_core {
--
1.7.8.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] USB: misc: Add USB3503 High-Speed Hub Controller
This patch adds new driver of SMSC USB3503 USB 2.0 hub controller with HSIC
upstream connectivity and three USB 2.0 downstream ports. The specification
can be found from 'http://www.smsc.com/index.php?tid=295pid=325'.
The current version have been tested very basic features switching the modes,
HUB-MODE and STANDBY-MODE.
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
drivers/usb/misc/Kconfig |6 +
drivers/usb/misc/Makefile |1 +
drivers/usb/misc/usb3503.c| 323 +
include/linux/platform_data/usb3503.h | 17 ++
4 files changed, 347 insertions(+)
create mode 100644 drivers/usb/misc/usb3503.c
create mode 100644 include/linux/platform_data/usb3503.h
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index fecde69..3b1a3f4 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -250,3 +250,9 @@ config USB_EZUSB_FX2
help
Say Y here if you need EZUSB device support.
(Cypress FX/FX2/FX2LP microcontrollers)
+
+config USB_HSIC_USB3503
+ tristate USB3503 HSIC to USB20 Driver
+ depends on I2C
+ help
+ This option enables support for SMSC USB3503 HSIC to USB 2.0 Driver.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 3e99a64..3e1bd70 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_USB_TRANCEVIBRATOR) += trancevibrator.o
obj-$(CONFIG_USB_USS720) += uss720.o
obj-$(CONFIG_USB_SEVSEG) += usbsevseg.o
obj-$(CONFIG_USB_YUREX)+= yurex.o
+obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
new file mode 100644
index 000..f21fca9
--- /dev/null
+++ b/drivers/usb/misc/usb3503.c
@@ -0,0 +1,323 @@
+/*
+ * Driver for SMSC USB3503 USB 2.0 hub controller driver
+ *
+ * Copyright (c) 2012 Dongjin Kim (tobet...@gmail.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/platform_data/usb3503.h
+
+#define USB3503_VIDL 0x00
+#define USB3503_VIDM 0x01
+#define USB3503_PIDL 0x02
+#define USB3503_PIDM 0x03
+#define USB3503_DIDL 0x04
+#define USB3503_DIDM 0x05
+
+#define USB3503_CFG1 0x06
+#define USB3503_SELF_BUS_PWR (1 7)
+
+#define USB3503_CFG2 0x07
+#define USB3503_CFG3 0x08
+#define USB3503_NRD0x09
+
+#define USB3503_PDS0x0a
+#define USB3503_PORT1 (1 1)
+#define USB3503_PORT2 (1 2)
+#define USB3503_PORT3 (1 3)
+
+#define USB3503_SP_ILOCK 0xe7
+#define USB3503_SPILOCK_CONNECT(1 1)
+#define USB3503_SPILOCK_CONFIG (1 0)
+
+#define USB3503_CFGP 0xee
+#define USB3503_CLKSUSP(1 7)
+
+struct usb3503 {
+ enum usb3503_mode mode;
+ struct i2c_client *client;
+ int gpio_intn;
+ int gpio_reset;
+ int gpio_connect;
+};
+
+static int usb3503_write_register(struct i2c_client *client,
+ char reg, char data)
+{
+ return i2c_smbus_write_byte_data(client, reg, data);
+}
+
+static int usb3503_read_register(struct i2c_client *client, char reg)
+{
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int usb3503_set_bits(struct i2c_client *client, char reg, char req)
+{
+ int err;
+
+ err = usb3503_read_register(client, reg);
+ if (err 0)
+ return err;
+
+ err = usb3503_write_register(client, reg, err | req);
+ if (err 0)
+ return err;
+
+ return 0;
+}
+
+static int usb3503_clear_bits(struct i2c_client *client, char reg, char req)
+{
+ int err;
+
+ err = usb3503_read_register(client, reg);
+ if (err 0)
+ return err;
+
+ err = usb3503_write_register(client, reg, err ~req);
+ if (err 0)
+ return err;
+
+ return 0;
+}
+
+static int usb3503_reset(int gpio_reset, int
Re: [PATCH] USB: misc: Add USB3503 High-Speed Hub Controller
Hi Greg, Thanks for your reviewing. The mode switching is required for power management, and actually it is not tested properly yet. Therefore suspend/resume functions are missing in the current patch but kept the switching function for the future. Thanks again. Dongjin. On Mon, Dec 31, 2012 at 12:22 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Dec 31, 2012 at 11:50:54AM +0900, Dongjin Kim wrote: This patch adds new driver of SMSC USB3503 USB 2.0 hub controller with HSIC upstream connectivity and three USB 2.0 downstream ports. The specification can be found from 'http://www.smsc.com/index.php?tid=295pid=325'. The current version have been tested very basic features switching the modes, HUB-MODE and STANDBY-MODE. What causes the modes to be switched? From reading the driver, that only seems possible to do at boot/load time when the driver reads the platform data, right? After that, nothing happens to the device from what I can tell. Is something going to cause the state of the device to change in the future? + hub-mode = mode; + dev_info(i2c-dev, switched to HUB mode\n); Can you please switch all of the dev_info() calls to dev_dbg()? There's no need to tell the world what is going on in this driver, no one really cares. And if they do, they can dynamically enable debugging and get the information then :) thanks, greg k-h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: omap3-igep: Add fixed always-on regulators to common dtsi file
On Sat, Dec 29, 2012 at 10:04 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
These regulators are common to igep0020 and igep0030 boards
and are needed by smsc911x controller.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index dd01c46..91a42ce 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -24,6 +24,18 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+vddvario: regulator-vddvario {
+compatible = regulator-fixed;
+regulator-name = vddvario;
+regulator-always-on;
+};
+
+vdd33a: regulator-vdd33a {
+compatible = regulator-fixed;
+regulator-name = vdd33a;
+regulator-always-on;
+};
};
omap3_pmx_core {
Hi Ezequiel,
This shouldn't be defined on the generic omap3-igep.dtsi but on
omap3-igep0020.dts since the IGEP COM Module doesn't have the LAN
SMSC9221 chip which is the one using these regulators.
Otherwise, the patch looks good to me and I think it has to be part of
the series that add SMSC9221 support for IGEPv2.
Thanks a lot and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 05/12] iommu/exynos: support for device tree
On Tuesday, January 1, 2013, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
On 12/26/2012 02:53 AM, Cho KyongHo wrote:
This commit adds device tree support for System MMU.
Signed-off-by: KyongHo Chopullip@samsung.com
Cc: devicetree-discuss@lists.ozlabs.org
Please note any patches adding new device tree bindings should be sent
to this mailing list. I have few comments, please see below.
Ok. I got it. thank you.
---
drivers/iommu/Kconfig| 2 +-
drivers/iommu/exynos-iommu.c | 282
++-
2 files changed, 174 insertions(+), 110 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index e39f9db..64586f1 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -168,7 +168,7 @@ config TEGRA_IOMMU_SMMU
config EXYNOS_IOMMU
bool Exynos IOMMU Support
- depends on ARCH_EXYNOS EXYNOS_DEV_SYSMMU
+ depends on ARCH_EXYNOS
select IOMMU_API
help
Support for the IOMMU(System MMU) of Samsung Exynos application
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 5847508..5b35820 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1,6 +1,6 @@
-/* linux/drivers/iommu/exynos_iommu.c
+/* linux/drivers/iommu/exynos-iommu.c
*
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
* http://www.samsung.com
*
* This program is free software; you can redistribute it and/or modify
@@ -12,6 +12,7 @@
#define DEBUG
#endif
+#includelinux/kernel.h
#includelinux/io.h
#includelinux/interrupt.h
#includelinux/platform_device.h
@@ -25,11 +26,10 @@
#includelinux/list.h
#includelinux/memblock.h
#includelinux/export.h
+#includelinux/of.h
+#includelinux/of_platform.h
#includeasm/cacheflush.h
-#includeasm/pgtable.h
-
-#includemach/sysmmu.h
/* We does not consider super section mapping (16MB) */
#define SECT_ORDER 20
@@ -161,14 +161,13 @@ struct sysmmu_drvdata {
struct list_head node; /* entry of exynos_iommu_domain.clients */
struct device *sysmmu; /* System MMU's device descriptor */
struct device *dev; /* Owner of system MMU */
- char *dbgname;
int nsfrs;
- void __iomem **sfrbases;
- struct clk *clk[2];
+ struct clk *clk;
int activations;
spinlock_t lock;
struct iommu_domain *domain;
unsigned long pgtable;
+ void __iomem *sfrbases[0];
};
static bool set_sysmmu_active(struct sysmmu_drvdata *data)
@@ -373,10 +372,8 @@ static bool __exynos_sysmmu_disable(struct
sysmmu_drvdata *data)
for (i = 0; i data-nsfrs; i++)
__raw_writel(CTRL_DISABLE, data-sfrbases[i] +
REG_MMU_CTRL);
- if (data-clk[1])
- clk_disable(data-clk[1]);
- if (data-clk[0])
- clk_disable(data-clk[0]);
+ if (data-clk)
+ clk_disable(data-clk);
disabled = true;
data-pgtable = 0;
@@ -385,10 +382,10 @@ finish:
spin_unlock_irqrestore(data-lock, flags);
if (disabled)
- dev_dbg(data-sysmmu, (%s) Disabled\n, data-dbgname);
+ dev_dbg(data-sysmmu, Disabled\n);
else
- dev_dbg(data-sysmmu, (%s) %d times left to be
disabled\n,
- data-dbgname, data-activations);
+ dev_dbg(data-sysmmu, %d times left to be disabled\n,
+ data-activations);
return disabled;
}
@@ -415,14 +412,12 @@ static int __exynos_sysmmu_enable(struct
sysmmu_drvdata *data,
ret = 1;
}
- dev_dbg(data-sysmmu, (%s) Already enabled\n,
data-dbgname);
+ dev_dbg(data-sysmmu, Already enabled\n);
goto finish;
}
- if (data-clk[0])
- clk_enable(data-clk[0]);
- if (data-clk[1])
- clk_enable(data-clk[1]);
+ if (data-clk)
+ clk_enable(data-clk);
data-pgtable = pgtable;
@@ -442,7 +437,7 @@ static int __exynos_sysmmu_enable(struct
sysmmu_drvdata *data,
data-domain = domain;
- dev_dbg(data-sysmmu, (%s) Enabled\n, data-dbgname);
+ dev_dbg(data-sysmmu, Enabled\n);
finish:
spin_unlock_irqrestore(data-lock, flags);
@@ -458,7 +453,7 @@ int exynos_sysmmu_enable(struct device *dev,
unsigned long pgtable)
ret = pm_runtime_get_sync(data-sysmmu);
if (ret 0) {
- dev_dbg(data-sysmmu, (%s) Failed to enable\n,
data-dbgname);
+ dev_dbg(data-sysmmu, Failed to enable\n);
return ret;
}
@@ -466,8 +461,8 @@ int exynos_sysmmu_enable(struct device *dev,
unsigned long pgtable)
if (WARN_ON(ret 0)) {
pm_runtime_put(data-sysmmu);
dev_err(data-sysmmu,
- (%s) Already enabled with page table %#lx\n,
[PATCH 1/4] ARM: EXYNOS: Update MFC DT binding documentation
Added an example for bindings for illustration and clarity.
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Arun Kumar K arun...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
.../devicetree/bindings/media/s5p-mfc.txt | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 67ec3d4..261c9dc 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -21,3 +21,16 @@ Required properties:
- samsung,mfc-l : Base address of the second memory bank used by MFC
for DMA contiguous memory allocation and its size.
+
+Example:
+
+mfc: codec@1340 {
+ compatible = samsung,mfc-v5;
+ reg = 0x1340 0x1;
+ interrupts = 0 94 0;
+};
+
+codec@1340 {
+ samsung,mfc-r = 0x4300 0x80;
+ samsung,mfc-l = 0x5100 0x80;
+};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] Added device tree binding for TDM and TDM phy
This controller is available on many Freescale SOCs like MPC8315, P1020, P1010
and P1022
Signed-off-by: Sandeep Singh sand...@freescale.com
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/fsl-tdm.txt| 63
.../devicetree/bindings/powerpc/fsl/tdm-phy.txt| 38
2 files changed, 101 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
b/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
new file mode 100644
index 000..ceb2ef1
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
@@ -0,0 +1,63 @@
+TDM Device Tree Binding
+
+NOTE: The bindings described in this document are preliminary
+and subject to change.
+
+TDM (Time Division Multiplexing)
+
+Description:
+
+The TDM is full duplex serial port designed to allow various devices including
+digital signal processors (DSPs) to communicate with a variety of serial
devices
+including industry standard framers, codecs, other DSPs and microprocessors.
+
+The below properties describe the device tree bindings for Freescale TDM
+controller. This TDM controller is available on various Freescale Processors
+like MPC8315, P1020, P1022 and P1010.
+
+Required properties:
+
+- compatible
+Value type: string
+Definition: Should contain fsl,tdm1.0.
+
+- reg
+Definition: A standard property. The first reg specifier describes the TDM
+registers, and the second describes the TDM DMAC registers.
+
+- tdm_tx_clk
+Value type: u32 or u64
+Definition: This specifies the value of transmit clock. It should not
+exceed 50Mhz.
+
+- tdm_rx_clk
+Value type: u32 or u64
+Definition: This specifies the value of receive clock. Its value could be
+zero, in which case tdm will operate in shared mode. Its value should not
+exceed 50Mhz.
+
+- interrupts
+Definition: Two interrupt specifiers. The first is TDM error, and the
+second is TDM DMAC.
+
+- phy-handle
+Value type: phandle
+Definition: Phandle of the line controller node or framer node eg. SLIC,
+E1/T1 etc. (Refer
Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt)
+
+- fsl,max-time-slots
+Value type: u32
+Definition: Maximum number of 8-bit time slots in one TDM frame. This is
+the maximum number which TDM hardware supports.
+
+Example:
+
+ tdm@16000 {
+ compatible = fsl,tdm1.0;
+ reg = 0x16000 0x200 0x2c000 0x2000;
+ tdm_tx_clk = 2048000;
+ tdm_rx_clk = 0;
+ interrupts = 16 8 62 8;
+ phy-handle = tdm-phy;
+ fsl,max-time-slots = 128;
+ };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
b/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
new file mode 100644
index 000..2563934
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
@@ -0,0 +1,38 @@
+TDM PHY Device Tree Binding
+
+NOTE: The bindings described in this document are preliminary
+and subject to change.
+
+Description:
+TDM PHY is the terminal interface of TDM subsystem. It is typically a line
+control device like E1/T1 framer or SLIC. A TDM device can have multiple TDM
+PHYs.
+
+Required properties:
+
+- compatible
+Value type: string
+Definition: Should contain generic compatibility like tdm-phy-slic or
+tdm-phy-e1 or tdm-phy-t1.
+
+- max-num-ports
+Value type: u32
+Definition: Defines the maximum number of ports supported by the SLIC
+device. Only required if the device is SLIC. For E1/T1 devices the number
+of ports are predefined i.e. (24 in case of T1 and 32 in case of E1).
+
+Apart from the above, there may be other properties required because of the
+bus/interface this device is connected on. It could be SPI/local bus, etc.
+
+Example:
+
+ tdm-phy@0 {
+ compatible = zarlink,le88266,tdm-phy-slic;
+ reg = 0;
+ max-num-ports = 4;
+ spi-max-frequency = 800;
+ };
+
+In the above example properties reg and spi-max-frequency are SPI specific
+as the SLIC device is connected on SPI interface. These properties might vary
+depending on the specific interface the device is using.
--
1.7.6.GIT
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: DT: tegra: Add Tegra30 Beaver board support
On 12/28/2012 08:43 PM, Olof Johansson wrote:
On Fri, Dec 28, 2012 at 3:54 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/28/2012 09:22 AM, Rob Herring wrote:
On 12/20/2012 01:41 PM, Bryan Wu wrote:
This patch adds support for Tegra30 Beaver board in upstream kernel.
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts
b/arch/arm/boot/dts/tegra30-beaver.dts
+/ {
+model = NVIDIA Tegra30 Beaver evaluation board;
+compatible = nvidia,beaver, nvidia,tegra30;
nvidia,beaver needs to be documented.
Hmmm. I guess we've managed not to document /any/ of the Tegra
board-level compatible values. Bryan, could you make a separate patch to
add all the existing board compatible values to
Documentation/devicetree/bindings/arm/tegra.txt. The Beaver addition to
that file can still be part of the Beaver-specific patch though.
Does it need to be documented? Then the support a new platform only
through DTS update is no longer true. :)
In the past, I don't think we've strictly documented all derivative
platform compatible values, just some of the reference ones?
-Olof
Actually in every Tegra board dts file, there is a model string to
describe this machine as well as a compatible board string, just like
the nvidia,beaver. So do we still need put this duplicated information
in a document file? Or if this is the requirement of DeviceTree. I will
do that. I think we have 12 boards need to add such document currently.
Thanks and happy new year.
-Bryan
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] ARM: DT: tegra: Add board leaver compatible properties
Signed-off-by: Bryan Wu pe...@nvidia.com --- Documentation/devicetree/bindings/arm/tegra.txt | 51 --- 1 file changed, 45 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt index 6e69d2e..ff9199a 100644 --- a/Documentation/devicetree/bindings/arm/tegra.txt +++ b/Documentation/devicetree/bindings/arm/tegra.txt @@ -1,14 +1,53 @@ NVIDIA Tegra device tree bindings --- -Boards with the tegra20 SoC shall have the following properties: +- Boards with the tegra20 SoC shall have the following properties: + Required root node property: + compatible = nvidia,tegra20; -Required root node property: +- Boards with the tegra30 SoC shall have the following properties: + Required root node property: + compatible = nvidia,tegra30; -compatible = nvidia,tegra20; +Boards +--- + +- NVIDIA Tegra20 Harmony evaluation board: + compatible = nvidia,harmony, nvidia,tegra20; + +- Avionic Design Medcom-Wide board: + compatible = ad,medcom-wide, ad,tamonten, nvidia,tegra20; + +- Toshiba AC100 / Dynabook AZ; + compatible = compal,paz00, nvidia,tegra20; + +- Avionic Design Plutux board: + compatible = ad,plutux, ad,tamonten, nvidia,tegra20; + +- NVIDIA Seaboard: + compatible = nvidia,seaboard, nvidia,tegra20; + +- Avionic Design Tamonten SOM: + compatible = ad,tamonten, nvidia,tegra20; + +- Avionic Design Tamonten Evaluation Carrier: + compatible = ad,tec, ad,tamonten, nvidia,tegra20; + +- Compulab TrimSlice board: + compatible = compulab,trimslice, nvidia,tegra20; + +- NVIDIA Tegra20 Ventana evaluation board: + compatible = nvidia,ventana, nvidia,tegra20; + +- NVIDIA Tegra20 Whistler evaluation board: + compatible = nvidia,whistler, nvidia,tegra20; + +- NVIDIA Tegra30 Cardhu evaluation board: + compatible = nvidia,cardhu, nvidia,tegra30; -Boards with the tegra30 SoC shall have the following properties: +- NVIDIA Tegra30 Cardhu A02 evaluation board: + compatible = nvidia,cardhu-a02, nvidia,cardhu, nvidia,tegra30; -Required root node property: +- NVIDIA Tegra30 Cardhu A04 (A05, A06, A07) evaluation board: + compatible = nvidia,cardhu-a04, nvidia,cardhu, nvidia,tegra30; -compatible = nvidia,tegra30; -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] ARM: DT: tegra: Add Tegra30 Beaver board support
This patch adds support for Tegra30 Beaver board in upstream kernel.
Beaver board is a Tegra30 SoC based development board, it has
following features:
- T30 or T33 SoC (Qual core ARM Cortex A9)
- 2 GB DDR3L
- 16 GB EMMC
- 1 SD slot
- 1 USB Standart A port and 1 USB micro AB port
- PCI-E Gig Ethernet
- Audio input/output
- SATA port
- HDMI output
- UART and JTAG
Signed-off-by: Bryan Wu pe...@nvidia.com
---
Documentation/devicetree/bindings/arm/tegra.txt |2 +
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/tegra30-beaver.dts| 374 +++
3 files changed, 378 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/tegra30-beaver.dts
diff --git a/Documentation/devicetree/bindings/arm/tegra.txt
b/Documentation/devicetree/bindings/arm/tegra.txt
index ff9199a..d733d53 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -51,3 +51,5 @@ Boards
- NVIDIA Tegra30 Cardhu A04 (A05, A06, A07) evaluation board:
compatible = nvidia,cardhu-a04, nvidia,cardhu, nvidia,tegra30;
+- NVIDIA Tegra30 Beaver evaluation board:
+ compatible = nvidia,beaver, nvidia,tegra30;
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..5c13de2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -143,7 +143,8 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra20-ventana.dtb \
tegra20-whistler.dtb \
tegra30-cardhu-a02.dtb \
- tegra30-cardhu-a04.dtb
+ tegra30-cardhu-a04.dtb \
+ tegra30-beaver.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
vexpress-v2p-ca9.dtb \
vexpress-v2p-ca15-tc1.dtb \
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts
b/arch/arm/boot/dts/tegra30-beaver.dts
new file mode 100644
index 000..0f296a4
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -0,0 +1,374 @@
+/dts-v1/;
+
+/include/ tegra30.dtsi
+
+/ {
+ model = NVIDIA Tegra30 Beaver evaluation board;
+ compatible = nvidia,beaver, nvidia,tegra30;
+
+ memory {
+ reg = 0x8000 0x8000;
+ };
+
+ pinmux {
+ pinctrl-names = default;
+ pinctrl-0 = state_default;
+
+ state_default: pinmux {
+ sdmmc1_clk_pz0 {
+ nvidia,pins = sdmmc1_clk_pz0;
+ nvidia,function = sdmmc1;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc1_cmd_pz1 {
+ nvidia,pins = sdmmc1_cmd_pz1,
+ sdmmc1_dat0_py7,
+ sdmmc1_dat1_py6,
+ sdmmc1_dat2_py5,
+ sdmmc1_dat3_py4;
+ nvidia,function = sdmmc1;
+ nvidia,pull = 2;
+ nvidia,tristate = 0;
+ };
+ sdmmc3_clk_pa6 {
+ nvidia,pins = sdmmc3_clk_pa6;
+ nvidia,function = sdmmc3;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc3_cmd_pa7 {
+ nvidia,pins = sdmmc3_cmd_pa7,
+ sdmmc3_dat0_pb7,
+ sdmmc3_dat1_pb6,
+ sdmmc3_dat2_pb5,
+ sdmmc3_dat3_pb4;
+ nvidia,function = sdmmc3;
+ nvidia,pull = 2;
+ nvidia,tristate = 0;
+ };
+ sdmmc4_clk_pcc4 {
+ nvidia,pins = sdmmc4_clk_pcc4,
+ sdmmc4_rst_n_pcc3;
+ nvidia,function = sdmmc4;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc4_dat0_paa0 {
+ nvidia,pins = sdmmc4_dat0_paa0,
+ sdmmc4_dat1_paa1,
+ sdmmc4_dat2_paa2,
+ sdmmc4_dat3_paa3,
+ sdmmc4_dat4_paa4,
+ sdmmc4_dat5_paa5,
+ sdmmc4_dat6_paa6,
+ sdmmc4_dat7_paa7;
+
[PATCH 2/2] ARM: DT: tegra: Add Tegra30 Beaver board support
This patch adds support for Tegra30 Beaver board in upstream kernel.
Beaver board is a Tegra30 SoC based development board, it has
following features:
- T30 or T33 SoC (Qual core ARM Cortex A9)
- 2 GB DDR3L
- 16 GB EMMC
- 1 SD slot
- 1 USB Standart A port and 1 USB micro AB port
- PCI-E Gig Ethernet
- Audio input/output
- SATA port
- HDMI output
- UART and JTAG
Signed-off-by: Bryan Wu pe...@nvidia.com
---
Documentation/devicetree/bindings/arm/tegra.txt |1 +
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/tegra30-beaver.dts| 374 +++
3 files changed, 377 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/tegra30-beaver.dts
diff --git a/Documentation/devicetree/bindings/arm/tegra.txt
b/Documentation/devicetree/bindings/arm/tegra.txt
index 665c54d..a5d3353 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -22,6 +22,7 @@ board-specific compatible values:
ad,tec
compal,paz00
compulab,trimslice
+ nvidia,beaver
nvidia,cardhu
nvidia,cardhu-a02
nvidia,cardhu-a04
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..5c13de2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -143,7 +143,8 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra20-ventana.dtb \
tegra20-whistler.dtb \
tegra30-cardhu-a02.dtb \
- tegra30-cardhu-a04.dtb
+ tegra30-cardhu-a04.dtb \
+ tegra30-beaver.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
vexpress-v2p-ca9.dtb \
vexpress-v2p-ca15-tc1.dtb \
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts
b/arch/arm/boot/dts/tegra30-beaver.dts
new file mode 100644
index 000..0f296a4
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -0,0 +1,374 @@
+/dts-v1/;
+
+/include/ tegra30.dtsi
+
+/ {
+ model = NVIDIA Tegra30 Beaver evaluation board;
+ compatible = nvidia,beaver, nvidia,tegra30;
+
+ memory {
+ reg = 0x8000 0x8000;
+ };
+
+ pinmux {
+ pinctrl-names = default;
+ pinctrl-0 = state_default;
+
+ state_default: pinmux {
+ sdmmc1_clk_pz0 {
+ nvidia,pins = sdmmc1_clk_pz0;
+ nvidia,function = sdmmc1;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc1_cmd_pz1 {
+ nvidia,pins = sdmmc1_cmd_pz1,
+ sdmmc1_dat0_py7,
+ sdmmc1_dat1_py6,
+ sdmmc1_dat2_py5,
+ sdmmc1_dat3_py4;
+ nvidia,function = sdmmc1;
+ nvidia,pull = 2;
+ nvidia,tristate = 0;
+ };
+ sdmmc3_clk_pa6 {
+ nvidia,pins = sdmmc3_clk_pa6;
+ nvidia,function = sdmmc3;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc3_cmd_pa7 {
+ nvidia,pins = sdmmc3_cmd_pa7,
+ sdmmc3_dat0_pb7,
+ sdmmc3_dat1_pb6,
+ sdmmc3_dat2_pb5,
+ sdmmc3_dat3_pb4;
+ nvidia,function = sdmmc3;
+ nvidia,pull = 2;
+ nvidia,tristate = 0;
+ };
+ sdmmc4_clk_pcc4 {
+ nvidia,pins = sdmmc4_clk_pcc4,
+ sdmmc4_rst_n_pcc3;
+ nvidia,function = sdmmc4;
+ nvidia,pull = 0;
+ nvidia,tristate = 0;
+ };
+ sdmmc4_dat0_paa0 {
+ nvidia,pins = sdmmc4_dat0_paa0,
+ sdmmc4_dat1_paa1,
+ sdmmc4_dat2_paa2,
+ sdmmc4_dat3_paa3,
+ sdmmc4_dat4_paa4,
+ sdmmc4_dat5_paa5,
+ sdmmc4_dat6_paa6,
+ sdmmc4_dat7_paa7;
+ nvidia,function = sdmmc4;
+ nvidia,pull =
Re: [PATCH 1/2] ARM: DT: tegra: Add board level compatible properties
On 01/02/2013 04:05 PM, Stephen Warren wrote: On 01/02/2013 04:53 PM, Bryan Wu wrote: The compatible properties of Tegra SoC based boards or machines need to be documented. This patch adds these board levle compatible My bad, Stephen could you please help me to fix this typo when you merging this patch 'levle' - 'level' properties into device tree binding document. This series looks reasonable now. I'll apply it tomorrow. It should be easy enough to add HDMI support; the driver is there. OK, cool. I will take a look at this as long as driver is ready Do you have any idea when SATA support could be added? Oh, do you have SATA driver merged into upstream yet? Thanks, -Bryan ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: DT: tegra: Add board level compatible properties
On 01/02/2013 04:13 PM, Stephen Warren wrote: Do you have any idea when SATA support could be added? Oh, do you have SATA driver merged into upstream yet? The driver isn't there yet, but it'd be great to add it. SATA looks like share some code like clock with PCI-E, I think we are working on upstream PCI-E driver. Anyway, I will look at this. Thanks, -Bryan ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] drm/exynos: Add device tree based discovery support for Exynos G2D
Hi Olof,
On Sun, Dec 30, 2012 at 11:57 AM, Olof Johansson o...@lixom.net wrote:
Hi,
On Thu, Dec 27, 2012 at 8:00 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
This patch adds device tree match table for Exynos G2D controller.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 6ffa076..aa3d2e4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -19,6 +19,7 @@
#include linux/workqueue.h
#include linux/dma-mapping.h
#include linux/dma-attrs.h
+#include linux/of.h
#include drm/drmP.h
#include drm/exynos_drm.h
@@ -1240,6 +1241,14 @@ static int g2d_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_g2d_match[] = {
+ { .compatible = samsung,exynos-g2d-41 },
What does -41 signify here?
This driver only supports G2D 4.1 version and not any lower versions of G2D!
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_g2d_match);
+#endif
+
struct platform_driver g2d_driver = {
.probe = g2d_probe,
.remove = __devexit_p(g2d_remove),
@@ -1247,5 +1256,6 @@ struct platform_driver g2d_driver = {
.name = s5p-g2d,
.owner = THIS_MODULE,
.pm = g2d_pm_ops,
+ .of_match_table = of_match_ptr(exynos_g2d_match),
Please provide bindings update, and cc devicetree-discuss for these
kind of patches.
Ok. I will update with the Documentation for bindings, soon.
-Olof
Thanks and Regards,
Ajay
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] exynos_g2d: Add Bindings for exynos G2D driver
Add documentation for the DT bindings in exynos G2D driver.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/drm/exynos/g2d.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/exynos/g2d.txt
diff --git a/Documentation/devicetree/bindings/drm/exynos/g2d.txt
b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
new file mode 100644
index 000..1eb124d
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
@@ -0,0 +1,22 @@
+Samsung 2D Graphic Accelerator using DRM frame work
+
+Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
+We set the drawing-context registers for configuring rendering parameters and
+then start rendering.
+This driver is for SOCs which contain G2D IPs with version 4.1.
+
+Required properties:
+ -compatible:
+ should be samsung,exynos-g2d-41.
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+
+Example:
+ g2d {
+ compatible = samsung,exynos-g2d-41;
+ reg = 0x1085 0x1000;
+ interrupts = 0 91 0;
+ };
--
1.8.0
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Early kernel hang with big DTB appended
-Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- kernel-boun...@lists.infradead.org] On Behalf Of Tomasz Figa Sent: Thursday, January 03, 2013 10:55 AM To: devicetree-discuss@lists.ozlabs.org Cc: linux-samsung-...@vger.kernel.org; li...@arm.linux.org.uk; n...@linaro.org; kgene@samsung.com; thomas.abra...@linaro.org; bo...@secretlab.ca; linux-arm-ker...@lists.infradead.org Subject: Early kernel hang with big DTB appended Hi, I'm observing strange behavior when booting 3.8-rc1 and -rc2 with appended DTB. The kernel hangs very early when the DTB is bigger than some threshold somewhere around 24 KiB. With fullest possible low level UART debugging (and printk patched to use printascii) I'm receiving following output: Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0xa00 Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu Jan 3 15:37:35 CET 2013 CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache I tested on two Exynos-based boards (exynos4210-trats and one internal exynos4412-based board) and same happens on both. Do you have any ideas? Tomasz, Sounds to me like the DTB is not being fully written to memory or that it isn't being fully read from memory. I've had similar problems when I placed the DTB too close to the end of flash and not all of the DTB was written to flash. If you load a debug build of U-Boot, I believe there are a number of debug messages related to loading the device tree that U-Boot prints. Then you can at least verify that U-Boot is loading the entire device tree. Regards, Bryan Best regards, -- Tomasz Figa Samsung Poland RD Center SW Solution Development, Linux Platform ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] drm/exynos: Get HDMI version from device tree
Am Montag, den 07.01.2013, 16:12 -0500 schrieb Sean Paul: On Mon, Jan 7, 2013 at 3:54 PM, Mitch Bradley w...@firmworks.com wrote: On 1/7/2013 10:43 AM, Sean Paul wrote: Add a property to the hdmi node so we can specify the HDMI version in the device tree instead of just defaulting to v1.4 with the existence of the dt node. Signed-off-by: Sean Paul seanp...@chromium.org --- .../devicetree/bindings/drm/exynos/hdmi.txt|3 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 19 ++- 2 files changed, 13 insertions(+), 9 deletions(-) diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt index 589edee..d1c7d91 100644 --- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt +++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt @@ -11,6 +11,8 @@ Required properties: c) pin function mode. d) optional flags and pull up/down. e) drive strength. +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4 +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3 a) This seems pretty generic, not at all samsung-specific, as the HDMI version numbering space is well-defined by the HDMI spec. b) It would be better to make it an integer property whose value encodes the version number, thus eliminating the need to add new properties as new HDMI versions appear. Thanks for the quick review, Mitch. How about: - hdmi-version: 0=v1.3, 1=v1.4 Why bother obfuscating the real version number? Why not just 13=v1.3, 14=v1.4? Regards, Lucas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] Added device tree binding for TDM and TDM phy
A gentle reminder.
Any comments are appreciated.
Regards,
Sandeep
-Original Message-
From: Singh Sandeep-B37400
Sent: Wednesday, January 02, 2013 6:55 PM
To: devicetree-discuss@lists.ozlabs.org; linuxppc-...@ozlabs.org
Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812
Subject: [PATCH] Added device tree binding for TDM and TDM phy
This controller is available on many Freescale SOCs like MPC8315, P1020,
P1010 and P1022
Signed-off-by: Sandeep Singh sand...@freescale.com
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/fsl-tdm.txt| 63
.../devicetree/bindings/powerpc/fsl/tdm-phy.txt| 38
2 files changed, 101 insertions(+), 0 deletions(-) create mode 100644
Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/tdm-
phy.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
b/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
new file mode 100644
index 000..ceb2ef1
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
@@ -0,0 +1,63 @@
+TDM Device Tree Binding
+
+NOTE: The bindings described in this document are preliminary and
+subject to change.
+
+TDM (Time Division Multiplexing)
+
+Description:
+
+The TDM is full duplex serial port designed to allow various devices
+including digital signal processors (DSPs) to communicate with a
+variety of serial devices including industry standard framers, codecs,
other DSPs and microprocessors.
+
+The below properties describe the device tree bindings for Freescale
+TDM controller. This TDM controller is available on various Freescale
+Processors like MPC8315, P1020, P1022 and P1010.
+
+Required properties:
+
+- compatible
+Value type: string
+Definition: Should contain fsl,tdm1.0.
+
+- reg
+Definition: A standard property. The first reg specifier describes
the TDM
+registers, and the second describes the TDM DMAC registers.
+
+- tdm_tx_clk
+Value type: u32 or u64
+Definition: This specifies the value of transmit clock. It should
not
+exceed 50Mhz.
+
+- tdm_rx_clk
+Value type: u32 or u64
+Definition: This specifies the value of receive clock. Its value
could be
+zero, in which case tdm will operate in shared mode. Its value
should not
+exceed 50Mhz.
+
+- interrupts
+Definition: Two interrupt specifiers. The first is TDM error, and
the
+second is TDM DMAC.
+
+- phy-handle
+Value type: phandle
+Definition: Phandle of the line controller node or framer node eg.
SLIC,
+E1/T1 etc. (Refer
+Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt)
+
+- fsl,max-time-slots
+Value type: u32
+Definition: Maximum number of 8-bit time slots in one TDM frame.
This is
+the maximum number which TDM hardware supports.
+
+Example:
+
+ tdm@16000 {
+ compatible = fsl,tdm1.0;
+ reg = 0x16000 0x200 0x2c000 0x2000;
+ tdm_tx_clk = 2048000;
+ tdm_rx_clk = 0;
+ interrupts = 16 8 62 8;
+ phy-handle = tdm-phy;
+ fsl,max-time-slots = 128;
+ };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
b/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
new file mode 100644
index 000..2563934
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
@@ -0,0 +1,38 @@
+TDM PHY Device Tree Binding
+
+NOTE: The bindings described in this document are preliminary and
+subject to change.
+
+Description:
+TDM PHY is the terminal interface of TDM subsystem. It is typically a
+line control device like E1/T1 framer or SLIC. A TDM device can have
+multiple TDM PHYs.
+
+Required properties:
+
+- compatible
+Value type: string
+Definition: Should contain generic compatibility like tdm-phy-slic
or
+tdm-phy-e1 or tdm-phy-t1.
+
+- max-num-ports
+Value type: u32
+Definition: Defines the maximum number of ports supported by the
SLIC
+device. Only required if the device is SLIC. For E1/T1 devices the
number
+of ports are predefined i.e. (24 in case of T1 and 32 in case of
E1).
+
+Apart from the above, there may be other properties required because of
+the bus/interface this device is connected on. It could be SPI/local
bus, etc.
+
+Example:
+
+ tdm-phy@0 {
+ compatible = zarlink,le88266,tdm-phy-slic;
+ reg = 0;
+ max-num-ports = 4;
+ spi-max-frequency = 800;
+ };
+
+In the above example properties reg and spi-max-frequency are SPI
+specific as the SLIC device is connected on SPI interface. These
+properties might vary depending on the specific interface the device is
using.
--
1.7.6.GIT
___
Re: [PATCH V2 0/4] add RTC support for Armada 370 and Armada XP
On Wednesday 12 December 2012 10:10:00 Gregory CLEMENT wrote: On 12/12/2012 10:06 AM, Gregory CLEMENT wrote: Hello, This small patch set adds RTC support for Armada 370 and Armada XP. It was successfully tested on the evaluation board. The third patch add the lacking documentation for the device tree binding and was already taken by Grant Likely, I keep this one in the series for coherency. The only differences with the previous patch set was the add of the Acked-by from Andrew Lunn and a new small patch to update of the mvebu_configuration. I also split the patch wich add the RTC support in two part, one for the RTC subsytem and on for mach-mvebu. This series is 3.9 material. Tested-by: Florian Fainelli flor...@openwrt.org on RD-A370-A1 -- Florian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/8] ARM: shmobile: Add support OF of INTC for sh7372
Hi Mark,
Thanks for your feedback!
On Wed, Jan 9, 2013 at 8:17 PM, Mark Rutland mark.rutl...@arm.com wrote:
On Wed, Jan 09, 2013 at 06:30:02AM +, Simon Horman wrote:
From: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
This CPU has four interrupt controllers (INTCA, pins-High and pins-Low).
This supports these.
Note: This supports DT of INTCA only.
Cc: Magnus Damm d...@opensource.se
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Signed-off-by: Simon Horman horms+rene...@verge.net.au
---
v9
* Update compatible string to use '-' instead of '_'
---
arch/arm/mach-shmobile/include/mach/common.h |1 +
arch/arm/mach-shmobile/intc-sh7372.c | 113
--
2 files changed, 89 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-shmobile/include/mach/common.h
b/arch/arm/mach-shmobile/include/mach/common.h
index d0a5790..223250b 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -18,6 +18,7 @@ extern int shmobile_enter_wfi(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index);
extern void shmobile_cpuidle_set_driver(struct cpuidle_driver *drv);
+extern void sh7372_init_irq_of(void);
extern void sh7372_init_irq(void);
extern void sh7372_map_io(void);
extern void sh7372_add_early_devices(void);
diff --git a/arch/arm/mach-shmobile/intc-sh7372.c
b/arch/arm/mach-shmobile/intc-sh7372.c
index a91caad..bbde18d 100644
--- a/arch/arm/mach-shmobile/intc-sh7372.c
+++ b/arch/arm/mach-shmobile/intc-sh7372.c
@@ -16,6 +16,8 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
USA
*/
+#define pr_fmt(fmt) intc: fmt
+
#include linux/kernel.h
#include linux/init.h
#include linux/interrupt.h
@@ -551,23 +553,28 @@ static void intcs_demux(unsigned int irq, struct
irq_desc *desc)
static void __iomem *intcs_ffd2;
static void __iomem *intcs_ffd5;
-
-void __init sh7372_init_irq(void)
+static void __iomem *intca_e694;
+static void __iomem *intca_e695;
+
+static void __init sh7372_init_intc(resource_size_t intca0_start,
+ resource_size_t intca1_start,
+ resource_size_t intcs0_start,
+ resource_size_t intcs1_start,
+ unsigned short vect)
{
void __iomem *intevtsa;
int n;
- intcs_ffd2 = ioremap_nocache(0xffd2, PAGE_SIZE);
- intevtsa = intcs_ffd2 + 0x100;
- intcs_ffd5 = ioremap_nocache(0xffd5, PAGE_SIZE);
+ intca_e694 = IOMEM(intca0_start);
+ intca_e695 = IOMEM(intca1_start);
- register_intc_controller(intca_desc);
- register_intc_controller(intca_irq_pins_lo_desc);
- register_intc_controller(intca_irq_pins_hi_desc);
- register_intc_controller(intcs_desc);
+ intcs_ffd2 = ioremap_nocache(intcs0_start, PAGE_SIZE);
+ intevtsa = intcs_ffd2 + 0x100;
+ intcs_ffd5 = ioremap_nocache(intcs1_start, PAGE_SIZE);
I think you need to check the return value of ioremap_nocache (it looks like
it
could return NULL), but I'm not certain of its semantics.
I guess we could, but I suppose it is somewhat unclear how we shall
proceed in the case of failure.
But regardless, this is not really changing any logic in the current code.
/* setup dummy cascade chip for INTCS */
- n = evt2irq(0xf80);
+ n = evt2irq(vect);
+
irq_alloc_desc_at(n, numa_node_id());
irq_set_chip_and_handler_name(n, dummy_irq_chip,
handle_level_irq, level);
@@ -581,6 +588,65 @@ void __init sh7372_init_irq(void)
iowrite16(0, intcs_ffd2 + 0x104);
}
+#ifdef CONFIG_OF
+static unsigned short intevtsa_vect;
+
+#define INTC_RES_MAX 2
+static struct {
+ struct intc_desc intc_desc;
+ struct resource intc_res[INTC_RES_MAX];
+} intc_data __initdata;
+
+static int __init intc_of_init(struct device_node *np,
+struct device_node *parent)
+{
+ int ret, i;
+
+ memset(intc_data, 0, sizeof(intc_data));
+
+ for (i = 0; i INTC_RES_MAX; i++) {
+ ret = of_address_to_resource(np, i, intc_data.intc_res[i]);
+ if (ret 0)
+ break;
+ }
+
+ intc_data.intc_desc.name = (char *)of_node_full_name(np);
+ intc_data.intc_desc.resource = intc_data.intc_res;
+ intc_data.intc_desc.num_resources = i;
+
+ ret = of_sh_intc_get_intc(np, intc_data.intc_desc);
+ if (ret)
+ return ret;
+
+ of_sh_intc_get_intevtsa_vect(np, intevtsa_vect);
+
+ register_intc_controller(intc_data.intc_desc);
+ return 0;
+}
You seem to have the same code for r8a7740. They should be consolidated.
The plan is to consolidate part of this code. There is also a chained
Re: [PATCH 1/8] SH: intc: Add support OF for INTC
Hi Mark, On Wed, Jan 9, 2013 at 8:53 PM, Mark Rutland mark.rutl...@arm.com wrote: Hi, Thanks for updating the text, this is far easier to read than previously. However, I'm still concerned by how complex the binding seems. As I don't have any familiarity with the device, I don't know whether that's just an artifact of the hardware or something that can be cleared up. Iwamatsu-san wrote this binding based on our C version of the INTC tables. And I wrote the original INTC table code based on perhaps 30+ data sheet. They code was initially designed to allow people to input data straight off the data sheet - this so we could support a wide range of slightly different interrupt controllers. I think the approach used by the binding needs some serious review before this should be merged. It seems far more complex than any existing interrupt controller binding. Without a dts example for a complete board (complete with devices wired up to the interrupt controller), it's difficult to judge how this will work in practice. Feel free to review the code, but I am not sure why anyone would case about this Renesas specific legacy interrupt controller. If I were to chose how cycles should be spent then I think it is better to try to come up with power domain DT bindings for all SoC vendors. Also, there are the DT board code queued up that makes use of this controller. Thanks, / magnus ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] Added device tree binding for TDM and TDM phy
-Original Message- From: Wood Scott-B07421 Sent: Thursday, January 10, 2013 5:37 AM To: Singh Sandeep-B37400 Cc: devicetree-discuss@lists.ozlabs.org; linuxppc-...@ozlabs.org; Aggrwal Poonam-B10812 Subject: Re: [PATCH] Added device tree binding for TDM and TDM phy On 01/09/2013 01:10:24 AM, Singh Sandeep-B37400 wrote: A gentle reminder. Any comments are appreciated. Regards, Sandeep -Original Message- From: Singh Sandeep-B37400 Sent: Wednesday, January 02, 2013 6:55 PM To: devicetree-discuss@lists.ozlabs.org; linuxppc-...@ozlabs.org Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812 Subject: [PATCH] Added device tree binding for TDM and TDM phy This controller is available on many Freescale SOCs like MPC8315, P1020, P1010 and P1022 Signed-off-by: Sandeep Singh sand...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com --- .../devicetree/bindings/powerpc/fsl/fsl-tdm.txt| 63 .../devicetree/bindings/powerpc/fsl/tdm-phy.txt| 38 2 files changed, 101 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/tdm- phy.txt diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt b/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt new file mode 100644 index 000..ceb2ef1 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt @@ -0,0 +1,63 @@ +TDM Device Tree Binding + +NOTE: The bindings described in this document are preliminary and +subject to change. + +TDM (Time Division Multiplexing) + +Description: + +The TDM is full duplex serial port designed to allow various devices +including digital signal processors (DSPs) to communicate with a +variety of serial devices including industry standard framers, codecs, other DSPs and microprocessors. + +The below properties describe the device tree bindings for Freescale +TDM controller. This TDM controller is available on various Freescale +Processors like MPC8315, P1020, P1022 and P1010. + +Required properties: + +- compatible +Value type: string +Definition: Should contain fsl,tdm1.0. + +- reg +Definition: A standard property. The first reg specifier describes the TDM +registers, and the second describes the TDM DMAC registers. + +- tdm_tx_clk +Value type: u32 or u64 +Definition: This specifies the value of transmit clock. It should not +exceed 50Mhz. + +- tdm_rx_clk +Value type: u32 or u64 +Definition: This specifies the value of receive clock. Its value could be +zero, in which case tdm will operate in shared mode. Its value should not +exceed 50Mhz. Please don't use underscores in property names, and use the vendor prefix: fsl,tdm-tx-clk and fsl,tdm-rx-clk. Ok. diff --git a/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt b/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt new file mode 100644 index 000..2563934 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt @@ -0,0 +1,38 @@ +TDM PHY Device Tree Binding + +NOTE: The bindings described in this document are preliminary and +subject to change. + +Description: +TDM PHY is the terminal interface of TDM subsystem. It is typically a +line control device like E1/T1 framer or SLIC. A TDM device can have +multiple TDM PHYs. + +Required properties: + +- compatible +Value type: string +Definition: Should contain generic compatibility like tdm-phy-slic or +tdm-phy-e1 or tdm-phy-t1. Does this generic string (plus the other properties) tell you all you need to know about the device? If there are other possible generic compatibles, they should be listed or else different people will make up different strings for the same thing. This property will describe the type of device, and will help TDM framework to know if it is E1/T1/SLIC device. Further details can be extracted from other compatible strings. There are only three generic compatibles field types, which are already mentioned in definition. Do I need to make this thing more clear. -Scott ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] Added device tree binding for TDM and TDM phy
-Original Message- From: Wood Scott-B07421 Sent: Friday, January 11, 2013 1:19 AM To: Singh Sandeep-B37400 Cc: Wood Scott-B07421; devicetree-discuss@lists.ozlabs.org; linuxppc- d...@ozlabs.org; Aggrwal Poonam-B10812 Subject: Re: [PATCH] Added device tree binding for TDM and TDM phy On 01/10/2013 03:24:21 AM, Singh Sandeep-B37400 wrote: +- compatible +Value type: string +Definition: Should contain generic compatibility like tdm-phy-slic or +tdm-phy-e1 or tdm-phy-t1. Does this generic string (plus the other properties) tell you all you need to know about the device? If there are other possible generic compatibles, they should be listed or else different people will make up different strings for the same thing. This property will describe the type of device, and will help TDM framework to know if it is E1/T1/SLIC device. Further details can be extracted from other compatible strings. There are only three generic compatibles field types, which are already mentioned in definition. Do I need to make this thing more clear. The word like suggests that there are other possibilites. It would be clearer as: Definition: One of tdm-phy-slic, tdm-phy-e1, or tdm-phy-t1. -Scott Ok, thanks for your comments. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/4] serial/arc-uart: switch to devicetree based probing
* DT binding for arc-uart
* With alll the bits in place we can now use DT probing.
Note that there's a bit of kludge right now because earlyprintk portion
of driver can't use the DT infrastrcuture to get resoures/plat_data.
This requires some infrastructre changes to of_flat_ framework
Signed-off-by: Vineet Gupta vgu...@synopsys.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Arnd Bergmann a...@arndb.de
Cc: linux-ser...@vger.kernel.org
Cc: Alan Cox a...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: linux-ser...@vger.kernel.org
---
.../devicetree/bindings/tty/serial/arc-uart.txt| 26
drivers/tty/serial/arc_uart.c | 43 ++-
2 files changed, 66 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tty/serial/arc-uart.txt
diff --git a/Documentation/devicetree/bindings/tty/serial/arc-uart.txt
b/Documentation/devicetree/bindings/tty/serial/arc-uart.txt
new file mode 100644
index 000..c3bd8f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/arc-uart.txt
@@ -0,0 +1,26 @@
+* Synopsys ARC UART : Non standard UART used in some of the ARC FPGA boards
+
+Required properties:
+- compatible : snps,arc-uart
+- reg : offset and length of the register set for the device.
+- interrupts : device interrupt
+- clock-frequency : the input clock frequency for the UART
+- baud : baud rate for UART
+
+e.g.
+
+arcuart0: serial@c0fc1000 {
+ compatible = snps,arc-uart;
+ reg = 0xc0fc1000 0x100;
+ interrupts = 5;
+ clock-frequency = 8000;
+ baud = 115200;
+ status = okay;
+};
+
+Note: Each port should have an alias correctly numbered in aliases node.
+
+e.g.
+aliases {
+ serial0 = arcuart0;
+};
diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c
index 2db6410..b468601 100644
--- a/drivers/tty/serial/arc_uart.c
+++ b/drivers/tty/serial/arc_uart.c
@@ -37,6 +37,8 @@
#include linux/tty_flip.h
#include linux/serial_core.h
#include linux/io.h
+#include linux/of.h
+#include linux/of_platform.h
/*
* ARC UART Hardware Specs
@@ -537,8 +539,26 @@ arc_uart_init_one(struct platform_device *pdev, int dev_id)
return -ENODEV;
uart-is_emulated = !!plat_data[0]; /* workaround ISS bug */
- uart-port.uartclk = plat_data[1];
- uart-baud = plat_data[2];
+
+ if (is_early_platform_device(pdev)) {
+ uart-port.uartclk = plat_data[1];
+ uart-baud = plat_data[2];
+ } else {
+ struct device_node *np = pdev-dev.of_node;
+ u32 val;
+
+ if (of_property_read_u32(np, clock-frequency, val)) {
+ dev_err(pdev-dev, clock-frequency property
NOTset\n);
+ return -EINVAL;
+ }
+ uart-port.uartclk = val;
+
+ if (of_property_read_u32(np, baud, val)) {
+ dev_err(pdev-dev, baud property NOT set\n);
+ return -EINVAL;
+ }
+ uart-baud = val;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
@@ -673,8 +693,18 @@ static int __init arc_serial_probe_earlyprintk(struct
platform_device *pdev)
static int arc_serial_probe(struct platform_device *pdev)
{
int rc, dev_id;
+ struct device_node *np = pdev-dev.of_node;
+
+ /* no device tree device */
+ if (!np)
+ return -ENODEV;
+
+ dev_id = of_alias_get_id(np, serial);
+ if (dev_id 0) {
+ dev_err(pdev-dev, failed to get alias id: %d\n, dev_id);
+ return dev_id;
+ }
- dev_id = pdev-id 0 ? 0 : pdev-id;
rc = arc_uart_init_one(pdev, dev_id);
if (rc)
return rc;
@@ -689,12 +719,19 @@ static int arc_serial_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id arc_uart_dt_ids[] = {
+ { .compatible = snps,arc-uart },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, arc_uart_dt_ids);
+
static struct platform_driver arc_platform_driver = {
.probe = arc_serial_probe,
.remove = arc_serial_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+ .of_match_table = arc_uart_dt_ids,
},
};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/4] ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone
On Thu, Dec 13, 2012 at 10:03 PM, AnilKumar Ch anilku...@ti.com wrote:
Set ti,pmic-shutdown-controller for BeagleBone in am335x-bone.dts
file, this flag is used by the driver to set tps65217 PMIC status
to OFF when PWR_EN toggle.
Signed-off-by: AnilKumar Ch anilku...@ti.com
Looks good
Reviewed-by: Russ Dill russ.d...@ti.com
Acked-by: Russ Dill russ.d...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5302f79..e7dff9d 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -88,6 +88,8 @@
/include/ tps65217.dtsi
tps {
+ ti,pmic-shutdown-controller;
+
regulators {
dcdc1_reg: regulator@0 {
regulator-always-on;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 4/4] ARM: OMAP2+: omap2plus_defconfig: Enable RTC support
On Thu, Dec 13, 2012 at 10:03 PM, AnilKumar Ch anilku...@ti.com wrote: AM33XX family of devices use RTC module, one has to manually enable this support to use RTC features. So this patch enable RTC driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com Looks good Reviewed-by: Russ Dill russ.d...@ti.com Acked-by: Russ Dill russ.d...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 0ce6771..e58afc5 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -216,6 +216,7 @@ CONFIG_LEDS_TRIGGER_CPU=y CONFIG_LEDS_TRIGGER_GPIO=y CONFIG_LEDS_TRIGGER_DEFAULT_ON=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_OMAP=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y CONFIG_DMADEVICES=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 3/4] ARM: dts: AM33XX: Enable system power off control in am335x-bone
On Thu, Dec 13, 2012 at 10:03 PM, AnilKumar Ch anilku...@ti.com wrote:
Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.
Signed-off-by: AnilKumar Ch anilku...@ti.com
Looks good
Reviewed-by: Russ Dill russ.d...@ti.com
Acked-by: Russ Dill russ.d...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index e7dff9d..febbe2f 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -52,6 +52,10 @@
};
};
+
+ rtc@44e3e000 {
+ ti,system-power-controller;
+ };
};
leds {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/4] rtc: OMAP: Add system pm_power_off to rtc driver
On Thu, Dec 13, 2012 at 10:03 PM, AnilKumar Ch anilku...@ti.com wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
Looks good
Reviewed-by: Russ Dill russ.d...@ti.com
Acked-by: Russ Dill russ.d...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 74
+++-
2 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..e6d4878 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG0x84
+#define OMAP_RTC_ALARM2_HOURS_REG 0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG 0x94
+#define OMAP_RTC_PMIC_REG 0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -93,15 +101,21 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC 2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +304,56 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ unsigned long time;
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
+
+ /* Read rtc time */
+ omap_rtc_read_time(NULL, tm);
+
+ /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
+ rtc_tm_to_time(tm, time);
+
+ /* Add shutdown time to the current value */
+ time += SHUTDOWN_TIME_SEC;
+
+ /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
+ rtc_time_to_tm(time, tm);
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /*
+* pmic_pwr_enable is controlled by means of ALARM2 event. So here
+* programming alarm2 expiry time and enabling alarm2 interrupt
+*/
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+ rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+ rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+ rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
+ /* Enable alarm2 interrupt */
+ val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
+ writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
+ rtc_base + OMAP_RTC_INTERRUPTS_REG);
+}
+
static
Re: [PATCH v4 1/4] rtc: OMAP: Add system pm_power_off to rtc driver
On Fri, Jan 11, 2013 at 12:08 AM, Russ Dill russ.d...@gmail.com wrote:
On Thu, Dec 13, 2012 at 10:03 PM, AnilKumar Ch anilku...@ti.com wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
Looks good
Reviewed-by: Russ Dill russ.d...@ti.com
Acked-by: Russ Dill russ.d...@ti.com
Sorry, actually, small follow up. Is there any reason this uses
readl/writel in some places rather than rtc_read/rtc_write?
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 74
+++-
2 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..e6d4878 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG0x84
+#define OMAP_RTC_ALARM2_HOURS_REG 0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG 0x94
+#define OMAP_RTC_PMIC_REG 0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -93,15 +101,21 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC 2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +304,56 @@ static int omap_rtc_set_alarm(struct device *dev,
struct rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ unsigned long time;
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base +
OMAP_RTC_PMIC_REG);
+
+ /* Read rtc time */
+ omap_rtc_read_time(NULL, tm);
+
+ /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
+ rtc_tm_to_time(tm, time);
+
+ /* Add shutdown time to the current value */
+ time += SHUTDOWN_TIME_SEC;
+
+ /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
+ rtc_time_to_tm(time, tm);
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /*
+* pmic_pwr_enable is controlled by means of ALARM2 event. So here
+* programming alarm2 expiry time and enabling alarm2 interrupt
+*/
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+ rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+ rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+ rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
+ /* Enable alarm2 interrupt */
Re: [PATCH 4/4] serial/arc-uart: switch to devicetree based probing
On Friday 11 January 2013 05:03 PM, Arnd Bergmann wrote: On Friday 11 January 2013, Vineet Gupta wrote: * DT binding for arc-uart * With alll the bits in place we can now use DT probing. Note that there's a bit of kludge right now because earlyprintk portion of driver can't use the DT infrastrcuture to get resoures/plat_data. This requires some infrastructre changes to of_flat_ framework Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Arnd Bergmann a...@arndb.de Cc: linux-ser...@vger.kernel.org Cc: Alan Cox a...@linux.intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: devicetree-discuss@lists.ozlabs.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: linux-ser...@vger.kernel.org Acked-by: Arnd Bergmann a...@arndb.de Quick question about the name though: is this UART only used on ARC, or is it something that synopsys licenses to other parties as well? If the latter is true, we might want to add a more generic compatible value for those that use it on another architecture. It's not licensed as standalone IP - since its not a standard 8250. It is only (but actively) used on the internal FPGA flows from ARC days. Thx, Vineet Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] cpsw: Add support to read cpu MAC address
Signed-off-by: Michal Bachraty michal.bachr...@streamunlimited.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 10 +-
arch/arm/boot/dts/am33xx.dtsi |5 +-
drivers/net/ethernet/ti/cpsw.c | 121 +---
include/linux/platform_data/cpsw.h |8 ++
4 files changed, 128 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index dcaabe9..432122c 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -4,7 +4,7 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
Required properties:
- compatible : Should be ti,cpsw
- reg : physical base address and size of the cpsw
- registers map
+ registers map and mac-address cpu config registers
- interrupts : property with a value describing the interrupt
number
- interrupt-parent : The parent interrupt controller
@@ -25,17 +25,23 @@ Required properties:
- slave_reg_ofs: Specifies slave register offset
- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
-- mac-address : Specifies slave MAC address
Optional properties:
- ti,hwmods: Must be cpgmac0
- no_bd_ram: Must be 0 or 1
+- mac-address-source : Specifies source of MAC address (user-defined-mac,
+ cpu-id0-mac, cpu-id01-mac, random-mac). If not
+ specified, cpu-id0-mac is selected
+- mac-address : Specifies slave MAC address for user-defined-mac
+ property value. When MAC address is not correct,
+ cpu-id01-mac is selected
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
+As default, MAC address is set from CPU (MAC_ID0 register)
Examples:
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 47fb059..f4845a3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -307,7 +307,8 @@
slaves = 1;
reg = 0x4a10 0x800
0x4a101200 0x100
- 0x4a101000 0x100;
+ 0x4a101000 0x100
+ 0x44e10630 0x0C;
#address-cells = 1;
#size-cells = 1;
interrupt-parent = intc;
@@ -317,7 +318,7 @@
cpsw_emac0: slave@0 {
slave_reg_ofs = 0x208;
sliver_reg_ofs = 0xd80;
- mac-address = [ 00 00 00 00 00 00 ];
+ mac-address-source = cpu-id0-mac;
};
davinci_mdio: mdio@4a101000 {
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index fb1a692..b777116 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -184,6 +184,13 @@ struct cpsw_sliver_regs {
u32 rx_pri_map;
};
+struct config_regs {
+ u32 mac_id0_lo;
+ u32 mac_id0_hi;
+ u32 mac_id1_lo;
+ u32 mac_id1_hi;
+};
+
struct cpsw_slave {
struct cpsw_slave_regs __iomem *regs;
struct cpsw_sliver_regs __iomem *sliver;
@@ -199,12 +206,14 @@ struct cpsw_priv {
struct net_device *ndev;
struct resource *cpsw_res;
struct resource *cpsw_ss_res;
+ struct resource *conf_res;
struct napi_struct napi;
struct device *dev;
struct cpsw_platform_data data;
struct cpsw_regs __iomem*regs;
struct cpsw_ss_regs __iomem *ss_regs;
struct cpsw_host_regs __iomem *host_port_regs;
+ struct config_regs __iomem *conf_regs;
u32 msg_enable;
struct net_device_stats stats;
int rx_packet_max;
@@ -363,6 +372,20 @@ static void cpsw_set_slave_mac(struct cpsw_slave *slave,
__raw_writel(mac_lo(priv-mac_addr), slave-regs-sa_lo);
}
+static void cpsw_get_cpu_id0_mac(struct cpsw_priv *priv)
+{
+ *((u32 *)priv-mac_addr) = __raw_readl(priv-conf_regs-mac_id0_hi);
+ *((u16 *)(priv-mac_addr + 4)) = __raw_readw(
+ priv-conf_regs-mac_id0_lo);
+}
+
+static void cpsw_get_cpu_id1_mac(struct cpsw_priv
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Friday 11 January 2013, Thierry Reding wrote:
Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
select PCI_MSI unconditionally. Once this is merged I was going to post
a patch that enables PCI_MSI in tegra_defconfig anyway. But it might be
better to keep it optional anyway since the remainder of the code copes
with it properly.
Actually, we need something better than that. You cannot define
arch_setup_msi_irq in a tegra specific pci host driver, because that
will seriously mess up other platforms in multiplatform configurations
by giving a link error when they also define this function, or with a
run-time error when they don't support it.
I think what we should do here is fix it the right way by adding
a pci host specific callback rather than an architecture specific
callback in drivers/pci/msi.c. There is already a default version
of arch_setup_msi_irqs (with s), and we can probably do the
same for arch_setup_msi_irq (without s) to fall back to the
arch version for most architectures.
Most architectures (at least powerpc, sparc, ia64 and x86) already
multiplex the msi handlers internally, but ARM does not because
there is only one implementation (iop33x) at the moment.
We can add a generix multiplex and then move architectures over to
use it.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Fri, Jan 11, 2013 at 03:36:14PM +, Arnd Bergmann wrote:
On Friday 11 January 2013, Thierry Reding wrote:
Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
select PCI_MSI unconditionally. Once this is merged I was going to post
a patch that enables PCI_MSI in tegra_defconfig anyway. But it might be
better to keep it optional anyway since the remainder of the code copes
with it properly.
Actually, we need something better than that. You cannot define
arch_setup_msi_irq in a tegra specific pci host driver, because that
will seriously mess up other platforms in multiplatform configurations
by giving a link error when they also define this function, or with a
run-time error when they don't support it.
I think what we should do here is fix it the right way by adding
a pci host specific callback rather than an architecture specific
callback in drivers/pci/msi.c. There is already a default version
of arch_setup_msi_irqs (with s), and we can probably do the
same for arch_setup_msi_irq (without s) to fall back to the
arch version for most architectures.
Most architectures (at least powerpc, sparc, ia64 and x86) already
multiplex the msi handlers internally, but ARM does not because
there is only one implementation (iop33x) at the moment.
We can add a generix multiplex and then move architectures over to
use it.
I already hinted at that in one of the other subthreads. Having such a
multiplex would also allow the driver to be built as a module. I had
already thought about this when I was working on an earlier version of
these patches. Basically these would be two ops attached to the host
bridge, and the generic arch_setup_msi_irq() could then look that up
given the struct pci_dev that is passed to it and call this new per-
host bridge .setup_msi_irq().
Thierry
pgpvQSQh2H9TU.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] cpsw: Add support to read cpu MAC address
On Fri, Jan 11, 2013 at 04:15:02PM +0100, Michal Bachraty wrote:
+ if (!request_mem_region(priv-conf_res-start,
+ resource_size(priv-conf_res), ndev-name)) {
+ dev_err(priv-dev, failed request i/o region\n);
+ ret = -ENXIO;
+ goto clean_clk_ret;
+ }
+
+ regs = ioremap(priv-conf_res-start,
+ resource_size(priv-conf_res));
+ if (!regs) {
+ dev_err(priv-dev, unable to map i/o region\n);
+ goto clean_configuration_iores_ret;
+ }
In this day and age where error paths don't get any testing, and are
frequently buggy, where we have alternative APIs which make those paths
more reliable, I think we should do everything to make use of that.
And, to prove the point, your error paths are buggy. Yes, you release
the mem region correctly (well done for picking the right interface for
that!) but the ioremap() is never cleaned up.
So, any chance of converting the above to devm_request_and_ioremap() ?
Thanks.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: kernel: DT cpu map validity check helper function
Since the introduction of /cpu nodes bindings for ARM and the
corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
and the number of possible CPUs are set according to the DT /cpu
nodes entries. Currently most of the existing ARM SMP platforms detect the
number of cores through HW probing in their .smp_init_cpus functions and set
the possible CPU mask accordingly.
This method should be upgraded so that the CPU counting mechanism will be
based on DT, keeping legacy HW probing mechanism as a fall back solution.
In order to implement this fall back solution mechanism, the ARM DT code
should provide a helper function to platforms to check if the cpu map
has been properly initialized through DT. If the check fails the
platform will resort to legacy HW based cores counting mechanism.
This patch implements a helper function that platforms can call to check
whether DT based cpu map initialization and cores count were completed
successfully.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/include/asm/prom.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index a219227..a913989 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -13,11 +13,21 @@
#define HAVE_ARCH_DEVTREE_FIXUPS
+#include linux/cpumask.h
+
#ifdef CONFIG_OF
extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
extern void __init arm_dt_init_cpu_maps(void);
+/*
+ * Return true if cpu map initialization has been
+ * carried out correctly from DT
+ */
+static inline bool __init arm_dt_cpu_map_valid(void)
+{
+ return !!(num_possible_cpus());
+}
#else /* CONFIG_OF */
@@ -28,6 +38,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned
int dt_phys)
static inline void arm_dt_memblock_reserve(void) { }
static inline void arm_dt_init_cpu_maps(void) { }
+static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: DT cpu map validity check helper function
On Fri, Jan 11, 2013 at 04:17:38PM +, Lorenzo Pieralisi wrote: This patch implements a helper function that platforms can call to check whether DT based cpu map initialization and cores count were completed successfully. Umm, are you sure this works? Two problems here: - the kernel boot marks the booting CPU (in our case, CPU0) as present, possible and online before arch code gets called. smp_init_cpus() will be called with the maps already initialized per that. - this really needs to be paired with a patch showing how you intend it to be used; merely adding the helper without any sign of it being used means it's just bloat which may not end up being used. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM and uses the TWL4030 power management IC.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 46
2 files changed, 47 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..5d6dff0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -104,6 +104,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
+ omap3430-sdp.dtb \
omap3-tobi.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
new file mode 100644
index 000..be0650d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI OMAP3430 SDP;
+ compatible = ti,omap3430-sdp, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Early kernel hang with big DTB appended
On Thu, Jan 03, 2013 at 04:55:00PM +0100, Tomasz Figa wrote: Hi, I'm observing strange behavior when booting 3.8-rc1 and -rc2 with appended DTB. The kernel hangs very early when the DTB is bigger than some threshold somewhere around 24 KiB. With fullest possible low level UART debugging (and printk patched to use printascii) I'm receiving following output: Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0xa00 Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu Jan 3 15:37:35 CET 2013 CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache I tested on two Exynos-based boards (exynos4210-trats and one internal exynos4412-based board) and same happens on both. Do you have any ideas? Another thing besides the things already mentioned is that the dtb may not cross a 1MiB boundary. The Kernel uses a single 1Mib section (aligned to 1Mib) to initially map the dtb. Once you cross that boundary parts of the dtb won't be accessible for the Kernel anymore. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 1/5] mmc: dw_mmc: Add disable-wp device tree property
The disable-wp property is used to specify that a given SD card slot
doesn't have a concept of write protect. This eliminates the need for
special case code for SD slots that should never be write protected
(like a micro SD slot or a dev board).
The dw_mmc driver is special in needing to specify disable-wp
because the lack of a wp-gpios property means to use the special
purpose write protect line. On some other mmc devices the lack of
wp-gpios means that write protect should be disabled.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Seungwon Jeon tgih@samsung.com
---
Changes in v4:
- Added a comment about the fact that a future patch will remove the
controller-level quirk; the comments and quirk will be removed in
the future change mmc: dw_mmc: Remove
DW_MCI_QUIRK_NO_WRITE_PROTECT. I split the patch up this way to
preserve bisectability and also to keep changes logically separated.
I will squash if desired.
Changes in v3:
- New for this version of the patch series. Chose disable-wp rather
than the discussed broken-internal-wp since it mapped more cleanly
to an existing quirk (and the only reason to specify that the
internal wp is broken is if you're disabling the write protect
anyway).
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt | 12 +-
drivers/mmc/host/dw_mmc.c | 41 +++-
include/linux/mmc/dw_mmc.h |9
3 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 06cd32d08..726fd21 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -26,8 +26,16 @@ Required Properties:
* bus-width: as documented in mmc core bindings.
* wp-gpios: specifies the write protect gpio line. The format of the
- gpio specifier depends on the gpio controller. If the write-protect
- line is not available, this property is optional.
+ gpio specifier depends on the gpio controller. If a GPIO is not used
+ for write-protect, this property is optional.
+
+ * disable-wp: If the wp-gpios property isn't present then (by default)
+ we'd assume that the write protect is hooked up directly to the
+ controller's special purpose write protect line (accessible via
+ the WRTPRT register). However, it's possible that we simply don't
+ want write protect. In that case specify 'disable-wp'.
+ NOTE: This property is not required for slots known to always
+ connect to eMMC or SDIO cards.
Optional properties:
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 323c502..90f7d99 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -74,6 +74,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @quirks: Slot-level quirks (DW_MCI_SLOT_QUIRK_XXX)
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +89,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int quirks;
+
u32 ctype;
struct mmc_request *mrq;
@@ -825,7 +828,13 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
struct dw_mci_board *brd = slot-host-pdata;
/* Use platform get_ro function, else try on board write protect */
- if (brd-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT)
+
+ /*
+* NOTE: DW_MCI_QUIRK_NO_WRITE_PROTECT will be removed in a future
+* patch in the series once reference to it is removed.
+*/
+ if ((brd-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) ||
+ (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (brd-get_ro)
read_only = brd-get_ro(slot-id);
@@ -1785,6 +1794,30 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
return NULL;
}
+static struct dw_mci_of_slot_quirks {
+ char *quirk;
+ int id;
+} of_slot_quirks[] = {
+ {
+ .quirk = disable-wp,
+ .id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+ },
+};
+
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int quirks = 0;
+ int idx;
+
+ /* get quirks */
+ for (idx = 0; idx ARRAY_SIZE(of_slot_quirks); idx++)
+ if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+ quirks |= of_slot_quirks[idx].id;
+
+ return quirks;
+}
+
/* find
Re: [PATCH v2] input: Extend matrix-keypad device tree binding
On 01/10/2013 06:41 PM, Simon Glass wrote: Some matrix keypad drivers can support different numbers of rows and columns. Add a generic binding for these. Implementation note: In order to implement this binding in the kernel, we will need to modify matrix_keypad_() to look up the number of rows and cols in the keymap. Perhaps this could be done by passing 0 for these parameters? Many of the parameters can already be set to NULL. Ick. Reviewed-by: Stephen Warren swar...@nvidia.com Note that the Tegra bindings are based on matrix-keypad.txt, and recently added the following properties: - nvidia,kbc-row-pins: The KBC pins which are configured as row. This is an array of pin numbers which is used as rows. - nvidia,kbc-col-pins: The KBC pins which are configured as column. This is an array of pin numbers which is used as column. Those both define the number of rows/columns (indirectly via the property lengths) *and* define which pins are used for the rows/columns. How will this influence/interact-with any changes you're planning to the core matrix keymap parsing code; would Tegra require your new keypad,num-rows/keypad,num-columns properties even though the information is redundant, or will the Tegra driver have some way of passing this information to the core? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] input: Extend matrix-keypad device tree binding
On Fri, Jan 11, 2013 at 10:09:19AM -0700, Stephen Warren wrote: On 01/10/2013 06:41 PM, Simon Glass wrote: Some matrix keypad drivers can support different numbers of rows and columns. Add a generic binding for these. Implementation note: In order to implement this binding in the kernel, we will need to modify matrix_keypad_() to look up the number of rows and cols in the keymap. Perhaps this could be done by passing 0 for these parameters? Many of the parameters can already be set to NULL. Ick. Reviewed-by: Stephen Warren swar...@nvidia.com Note that the Tegra bindings are based on matrix-keypad.txt, and recently added the following properties: - nvidia,kbc-row-pins: The KBC pins which are configured as row. This is an array of pin numbers which is used as rows. - nvidia,kbc-col-pins: The KBC pins which are configured as column. This is an array of pin numbers which is used as column. Those both define the number of rows/columns (indirectly via the property lengths) *and* define which pins are used for the rows/columns. How will this influence/interact-with any changes you're planning to the core matrix keymap parsing code; would Tegra require your new keypad,num-rows/keypad,num-columns properties even though the information is redundant, or will the Tegra driver have some way of passing this information to the core? Even if we decide to move lookup of keypad,num-rows/keypad,num-columns into matrix-keypad code we will still allow callers to override DT data, like we do with platform keymaps. Thanks. -- Dmitry ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: DT cpu map validity check helper function
On Fri, Jan 11, 2013 at 04:30:57PM +, Russell King - ARM Linux wrote: On Fri, Jan 11, 2013 at 04:17:38PM +, Lorenzo Pieralisi wrote: This patch implements a helper function that platforms can call to check whether DT based cpu map initialization and cores count were completed successfully. Umm, are you sure this works? Two problems here: - the kernel boot marks the booting CPU (in our case, CPU0) as present, possible and online before arch code gets called. smp_init_cpus() will be called with the maps already initialized per that. Gah, my bad, you are definitely right. - this really needs to be paired with a patch showing how you intend it to be used; merely adding the helper without any sign of it being used means it's just bloat which may not end up being used. Ok, that's a fair point, I will ask to get it merged with an implementation that relies on it, showing its usage. Thanks for the review, Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] hwmon: Driver for Maxim MAX6697 and compatibles
On Sun, Dec 16, 2012 at 09:33:09PM -0800, Guenter Roeck wrote:
Add support for MAX6581, MAX6602, MAX6622, MAX6636, MAX6689, MAX6693,
MAX6694, MAX6697, MAX6698, and MAX6699 temperature sensors
Signed-off-by: Guenter Roeck li...@roeck-us.net
I plan to line this driver up for 3.9. Only change from the code below is to
replace SENSORS_LIMIT with clamp_val. Any objections, make yourself heard.
Thanks,
Guenter
---
v2:
- Add suppport for platform data and devicetree based chip initialization
- Drop S_IRUGOWU macro: s/S_IRUGOWU/S_IRUGO | S_IWUSR/
Documentation/devicetree/bindings/i2c/max6697.txt | 45 ++
Documentation/hwmon/max6697 | 57 ++
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile|1 +
drivers/hwmon/max6697.c | 634
+
include/linux/platform_data/max6697.h | 25 +
6 files changed, 773 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/max6697.txt
create mode 100644 Documentation/hwmon/max6697
create mode 100644 drivers/hwmon/max6697.c
create mode 100644 include/linux/platform_data/max6697.h
diff --git a/Documentation/devicetree/bindings/i2c/max6697.txt
b/Documentation/devicetree/bindings/i2c/max6697.txt
new file mode 100644
index 000..3e867e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/max6697.txt
@@ -0,0 +1,45 @@
+max6697 properties
+
+Required properties:
+- compatible:
+ Should be one of
+ maxim,max6581
+ maxim,max6602
+ maxim,max6622
+ maxim,max6636
+ maxim,max6689
+ maxim,max6693
+ maxim,max6694
+ maxim,max6697
+ maxim,max6698
+ maxim,max6699
+- reg: I2C address
+
+Optional properties:
+- smbus-timeout-disable
+ Set to enable SMBus timeout
+- extended-range-enable
+ Only valid for MAX6581. Set to enable extended temperature range.
+- alert-mask
+ Alert bit mask. Alert disabled for bits set.
+- over-temperature-mask
+ Over temperature bit mask. Over temperature reporting disabled for
+ bits set.
+- resistance-cancellation
+ Boolean for all chips other than MAX6581. Enabled if set.
+ For MAX6581, resistance cancellation enabled for all channels if
+ specified as boolean, otherwise as per bit mask specified.
+- transistor-ideality
+ For MAX6581 only. Two values; first is bit mask, second is ideality
+ select value as per MAX6581 data sheet.
+
+Example:
+
+temp-sensor@1a {
+ compatible = maxim,max6697;
+ reg = 0x1a;
+ smbus-timeout-disable;
+ resistance-cancellation;
+ alert-mask = 0xff;
+ over-temperature-mask = 0xff;
+};
diff --git a/Documentation/hwmon/max6697 b/Documentation/hwmon/max6697
new file mode 100644
index 000..35fc2e9
--- /dev/null
+++ b/Documentation/hwmon/max6697
@@ -0,0 +1,57 @@
+Kernel driver max6697
+=
+
+Supported chips:
+ * Maxim MAX6581
+Prefix: 'max6581'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
+ * Maxim MAX6602
+Prefix: 'max6602'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6602.pdf
+ * Maxim MAX6622
+Prefix: 'max6622'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6622.pdf
+ * Maxim MAX6636
+Prefix: 'max6636'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6636.pdf
+ * Maxim MAX6689
+Prefix: 'max6689'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6689.pdf
+ * Maxim MAX6693
+Prefix: 'max6693'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6693.pdf
+ * Maxim MAX6694
+Prefix: 'max6694'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6694.pdf
+ * Maxim MAX6697
+Prefix: 'max6697'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6697.pdf
+ * Maxim MAX6698
+Prefix: 'max6698'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6698.pdf
+ * Maxim MAX6699
+Prefix: 'max6699'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6699.pdf
+
+Author:
+Guenter Roeck li...@roeck-us.net
+
+Description
+---
+
+This driver implements support for several MAX6697 compatible temperature
sensor
+chips. The chips support one local temperature sensor plus four or six remote
+temperature sensors. Remote temperature sensors are diode-connected thermal
+transitors, except for MAX6698 which supports three diode-connected thermal
+transistors plus three thermistors in addition to the local temperature
sensor.
+
+The driver provides the following sysfs attributes. temp1 is the local (chip)
+temperature, temp[2..n] are remote temperatures. The actually supported
+per-channel attributes are chip type and channel dependent.
+
+tempX_input ro remote
Re: [PATCH v4 07/14] dmaengine: add dma_request_slave_channel_compat()
* Matt Porter mpor...@ti.com [130110 21:47]:
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Cool, looks like the driver changes are quite minimal after this:
Acked-by: Tony Lindgren t...@atomide.com
Suggested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
include/linux/dmaengine.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9fd0c5b..64f9f69 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct
dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel((mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev-of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 08/14] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
* Matt Porter mpor...@ti.com [130110 21:47]:
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc58078..e79b12d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1915,14 +1915,20 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn, rx_req);
+ host-rx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ rx_req, pdev-dev, rx);
+
if (!host-rx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain RX DMA engine
channel %u\n, rx_req);
ret = -ENXIO;
goto err_irq;
}
- host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn, tx_req);
+ host-tx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ tx_req, pdev-dev, tx);
+
if (!host-tx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain TX DMA engine
channel %u\n, tx_req);
ret = -ENXIO;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 09/14] mmc: omap_hsmmc: set max_segs based on dma engine limitations
* Matt Porter mpor...@ti.com [130110 21:47]: The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. The DMA Engine API reports the maximum number of segments a channel can support via the optional dma_get_channel_caps() API. If the nr_segs capability is present, the value is used to configure mmc-max_segs appropriately. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Matt Porter mpor...@ti.com --- drivers/mmc/host/omap_hsmmc.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e79b12d..f74bd69 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1769,6 +1769,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev) const struct of_device_id *match; dma_cap_mask_t mask; unsigned tx_req, rx_req; + struct dmaengine_chan_caps *dma_chan_caps; struct pinctrl *pinctrl; match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev); @@ -1935,6 +1936,11 @@ static int omap_hsmmc_probe(struct platform_device *pdev) goto err_irq; } + /* Some DMA Engines only handle a limited number of SG segments */ + dma_chan_caps = dma_get_channel_caps(host-rx_chan, DMA_DEV_TO_MEM); + if (dma_chan_caps dma_chan_caps-seg_nr) + mmc-max_segs = dma_chan_caps-seg_nr; + /* Request IRQ for MMC operations */ ret = request_irq(host-irq, omap_hsmmc_irq, 0, mmc_hostname(mmc), host); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 10/14] mmc: omap_hsmmc: add generic DMA request support to the DT binding
* Matt Porter mpor...@ti.com [130110 21:47]:
The binding definition is based on the generic DMA request binding.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25
+++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..826cc51 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,28 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
+dmas: DMA controller phandle and DMA request value ordered pair
+One tx and one rx pair is required.
+dma-names: DMA request names. These strings correspond 1:1 with
+the ordered pairs in dmas. The RX request must be rx and the
+TX request must be tx.
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = ti,omap4-hsmmc;
+ reg = 0x4809c000 0x400;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ bus-width = 4;
+ vmmc-supply = vmmc; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = ti,omap4-hsmmc;
reg = 0x4809c000 0x400;
@@ -30,4 +50,7 @@ Example:
bus-width = 4;
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 11/14] ARM: dts: add AM33XX MMC support
* Matt Porter mpor...@ti.com [130110 21:47]:
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk..
This one should be queued separately by Benoit:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
@@ -136,3 +138,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e711ffb..278b75d 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -235,6 +235,34 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc3: mmc@4781 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ status = disabled;
+ };
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/2] ARM: OMAP2+: Prepare for device-tree PMU support
* Jon Hunter jon-hun...@ti.com [121217 09:51]:
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/pmu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..1a0799c 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include linux/of.h
+
#include asm/pmu.h
#include soc.h
@@ -64,6 +66,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -76,9 +87,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/2] ARM: dts: OMAP2+: Add PMU nodes
* Jon Hunter jon-hun...@ti.com [130111 06:02]: Hi Benoit, On 01/11/2013 07:23 AM, Benoit Cousson wrote: Hi Jon, On 12/17/2012 06:49 PM, Jon Hunter wrote: Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices. Please note that the node for OMAP4460 has been placed in a separate header file for OMAP4460, because the node is not compatible with OMAP4430. The node for OMAP4430 is not included because PMU is not currently supported on OMAP4430 due to the absence of a cross-trigger interface driver. Signed-off-by: Jon Hunter jon-hun...@ti.com I've just applied this patch in my for_3.9/dts branch. I'm wondering if there is any dependency with the previous patch? If Tony ack it I can take it as well. I have been thinking about the best way to handle that. May be best for you to take both if Tony can ack the first. Sounds good to me, I've acked it now. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 00/14] DMA Engine support for AM33XX
On Fri, Jan 11, 2013 at 11:40:41AM +, Arnd Bergmann wrote: On Friday 11 January 2013, Matt Porter wrote: The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx only boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. I think this looks very good. What I wonder is whether we should make the non-DT parts of the dmaengine driver compile-time conditional on CONFIG_ATAGS though, so the slave drivers don't have a link-time dependency on the dmaengine driver's omap_dma_filter_fn symbol when building without ATAGS support. We have tightly coupled the link-time dependency for omap_dma_filter_fn by going down the path of using dma_request_slave_channel_compat() as Tony suggested to avoid extra ifdefry. That dependency will go away naturally if all the legacy OMAP platforms were required to only boot from DT...just as a newly added SoCs are. Are you suggesting unwinding the _compat() approach? -Matt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 14/14] ARM: tegra: trimslice: Initialize PCIe from DT
On Thu, Jan 10, 2013 at 04:56:39PM -0700, Stephen Warren wrote:
On 01/09/2013 01:43 PM, Thierry Reding wrote:
With the device tree support in place, probe the PCIe controller from
the device tree and remove the corresponding workaround in the board
file.
Thierry, there are a couple things missing from this patch; I include a
fixup for you to squash in, but also see beyond that for a problem.
arch/arm/boot/dts/tegra20-trimslice.dts | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts
b/arch/arm/boot/dts/tegra20-trimslice.dts
index ebb4c17..41fc45b 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -303,12 +303,10 @@
pcie-controller {
status = okay;
+ pex-clk-supply = pci_clk_reg;
+ vdd-supply = pci_vdd_reg;
- pci@0 {
- status = okay;
- };
-
- pci@1 {
+ pci@1,0 {
status = okay;
};
};
@@ -366,6 +364,24 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+ pci_clk_reg: regulator@2 {
+ compatible = regulator-fixed;
+ reg = 2;
+ regulator-name = pci_clk;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ };
+
+ pci_vdd_reg: regulator@3 {
+ compatible = regulator-fixed;
+ reg = 3;
+ regulator-name = pci_vdd;
+ regulator-min-microvolt = 105;
+ regulator-max-microvolt = 105;
+ regulator-always-on;
+ };
};
sound {
--
1.7.10.4
However, PCIe still doesn't work on TrimSlice; the device enumeration
fails. The log is below:
[0.790425] tegra-pcie 80003000.pcie-controller: link 0 down, retrying
[0.801351] tegra-pcie 80003000.pcie-controller: PCI host bridge to bus
:00
[0.808945] pci_bus :00: root bus resource [io
0x8200-0x8200]
[0.816109] pci_bus :00: root bus resource [mem
0xa000-0xafff]
[0.823303] pci_bus :00: root bus resource [mem
0xb000-0xbfff pref]
[0.830893] pci_bus :00: root bus resource [bus 00-ff]
[0.836728] pci :00:01.0: [10de:0bf0] type 01 class 0x06
[0.843097] pci :00:01.0: PME# supported from D0 D1 D2 D3hot D3cold
[0.850047] PCI: bus0: Fast back to back transfers disabled
[0.855853] pci :00:01.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[0.864308] tegra-pcie 80003000.pcie-controller: AXI response decoding
error, signature: 10010001
[0.873489] tegra-pcie 80003000.pcie-controller: FPCI address:
fe1001
^^^ For some reason, the config register access fails.
[0.880760] PCI: bus1: Fast back to back transfers enabled
[0.886482] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[0.893381] pci :00:01.0: PCI bridge to [bus 01]
[0.898577] PCI: enabling device :00:01.0 (0140 - 0143)
[0.904535] pci :00:01.0: nv_msi_ht_cap_quirk didn't locate host
bridge
With plain next-20130109, the device enumeration succeeds.
That's very strange. I haven't seen that on my setup. Looks like I need
to dig out the TrimSlice again and debug this. It'll take me a while and
there are plenty of other requested changes already, so if I find a fix
I can roll it into the next version.
Thanks for testing,
Thierry
pgpqZnMzaFYsF.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 00/14] DMA Engine support for AM33XX
On Friday 11 January 2013, Matt Porter wrote: We have tightly coupled the link-time dependency for omap_dma_filter_fn by going down the path of using dma_request_slave_channel_compat() as Tony suggested to avoid extra ifdefry. That dependency will go away naturally if all the legacy OMAP platforms were required to only boot from DT...just as a newly added SoCs are. Are you suggesting unwinding the _compat() approach? No, I was thinking we could define omap_dma_filter_fn to NULL for the DT-only case. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] serial/arc-uart: switch to devicetree based probing
On Friday 11 January 2013, Vineet Gupta wrote: On Friday 11 January 2013 05:03 PM, Arnd Bergmann wrote: Quick question about the name though: is this UART only used on ARC, or is it something that synopsys licenses to other parties as well? If the latter is true, we might want to add a more generic compatible value for those that use it on another architecture. It's not licensed as standalone IP - since its not a standard 8250. It is only (but actively) used on the internal FPGA flows from ARC days. Ok, thanks for the confirmation. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On 01/10/2013 08:52 PM, Thierry Reding wrote:
On Thu, Jan 10, 2013 at 05:48:46PM -0700, Stephen Warren wrote:
On 01/09/2013 01:43 PM, Thierry Reding wrote:
Move the PCIe driver from arch/arm/mach-tegra into the
drivers/pci/host directory. The motivation is to collect
various host controller drivers in the same location in order
to facilitate refactoring.
The Tegra PCIe driver has been largely rewritten, both in order
to turn it into a proper platform driver and to add MSI (based
on code by Krishna Kishore kth...@nvidia.com) as well as
device tree support.
diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
b/arch/arm/mach-tegra/board-dt-tegra20.c
+static int tegra_pcie_enable_controller(struct tegra_pcie
*pcie) +{ + unsigned int timeout; + unsigned long value; + +/*
enable dual controller and both ports */ + value =
afi_readl(pcie, AFI_PCIE_CONFIG); + value =
~(AFI_PCIE_CONFIG_PCIEC0_DISABLE_DEVICE | +
AFI_PCIE_CONFIG_PCIEC1_DISABLE_DEVICE | +
AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK); +value |=
AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL; + afi_writel(pcie,
value, AFI_PCIE_CONFIG);
Eventually, we should probably derive the port enables from the
state of the root port DT nodes, so that we can disable some and
presumably save a little power. Also, I notice that the
nvidia,num-lanes property isn't implemented yet. Still, we can
probably take care of this later.
Yes, the plan was to eventually derive the disable bits from the
port status and setup the XBAR_CONFIG field based on the
combination of nvidia,num-lanes properties.
I assume we should simply fail if the configuration specified by
nvidia,num-lanes is invalid?
Makes sense to me.
+static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
+ pcie-vdd_supply = devm_regulator_get(pcie-dev, vdd); + if
(IS_ERR(pcie-vdd_supply)) +return
PTR_ERR(pcie-vdd_supply); + + pcie-pex_clk_supply =
devm_regulator_get(pcie-dev, pex-clk); + if
(IS_ERR(pcie-pex_clk_supply)) +return
PTR_ERR(pcie-pex_clk_supply);
Oh, I guess the regulator_get() calls are already strict.
Yeah, I think they can't return NULL, right? In that case I can
just drop the extra checks in tegra_pcie_power_{on,off}().
It looks like NULL can be returned if !CONFIG_REGULATOR. The comment
in the dummy implementation implies that drivers should treat a NULL
value as valid regulator in most cases.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On Mon, Dec 17, 2012 at 05:04:41PM -0500, Alan Stern wrote: On Mon, 17 Dec 2012, Stephen Warren wrote: On 12/13/2012 11:59 PM, Venu Byravarasu wrote: As Tegra USB host driver is using instance number for resetting PORT0 twice, adding a new DT property for handling this. Alan, Greg, Felip,e This series looks fine to me. I'd like to take all the Tegra-related USB patches through the Tegra tree for 3.9 if possible (so I'm looking for your acks here). I believe Venu plans to significantly clean up the EHCI/PHY driver split for Tegra, rework the drivers, and add support for Tegra30 in addition to Tegra20. Some of this requires changes to some Tegra board files and device trees to maintain git bisect I don't know for sure yet, but I believe that rework may also end up conflicting with other clock-related rework that will show up for Tegra in 3.9. Are you OK with this? I'll certainly look for your review/acks on the patches before picking them up though. Regarding the changes to drivers/usb/host/ehci-tegra.c: Acked-by: Alan Stern st...@rowland.harvard.edu That's fine with me as well, feel free to think that I have now dropped all tegra-related patches from my queue, you can take them all :) thanks, greg k-h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On 01/11/2013 05:14 PM, Greg KH wrote: On Mon, Dec 17, 2012 at 05:04:41PM -0500, Alan Stern wrote: On Mon, 17 Dec 2012, Stephen Warren wrote: On 12/13/2012 11:59 PM, Venu Byravarasu wrote: As Tegra USB host driver is using instance number for resetting PORT0 twice, adding a new DT property for handling this. Alan, Greg, Felip,e This series looks fine to me. I'd like to take all the Tegra-related USB patches through the Tegra tree for 3.9 if possible (so I'm looking for your acks here). I believe Venu plans to significantly clean up the EHCI/PHY driver split for Tegra, rework the drivers, and add support for Tegra30 in addition to Tegra20. Some of this requires changes to some Tegra board files and device trees to maintain git bisect I don't know for sure yet, but I believe that rework may also end up conflicting with other clock-related rework that will show up for Tegra in 3.9. Are you OK with this? I'll certainly look for your review/acks on the patches before picking them up though. Regarding the changes to drivers/usb/host/ehci-tegra.c: Acked-by: Alan Stern st...@rowland.harvard.edu That's fine with me as well, feel free to think that I have now dropped all tegra-related patches from my queue, you can take them all :) Thanks, applied to Tegra's for-3.9/usb branch. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Vivek,
On Fri, Jan 11, 2013 at 4:40 AM, Vivek Gautam gautamvivek1...@gmail.com wrote:
+#define HOST_CTRL0_REFCLKSEL_MASK (0x3)
+#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19)
+#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 19)
+#define HOST_CTRL0_REFCLKSEL_CLKCORE (0x2 19)
+
+#define HOST_CTRL0_FSEL_MASK (0x7 16)
+#define HOST_CTRL0_FSEL(_x)((_x) 16)
+#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7)
+#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5)
+#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4)
+#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3)
+#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2)
+#define HOST_CTRL0_FSEL_CLKSEL_10M (0x1)
+#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0)
Add the shifts to the #defines and remove HOST_CTRL0_FSEL(_x). That
makes it match the older phy more closely.
Wouldn't it hamper the readability when shifts are used ??
I mean if we have something like this -
phyhost |= HOST_CTRL0_FSEL(phyclk)
so, if we are using the shifts then
phyhost |= (HOST_CTRL0_FSEL_CLKSEL_24M HOST_CTRL0_FSEL_SHIFT)
I was actually suggesting modifying the #defines like this:
#define HOST_CTRL0_FSEL_SHIFT 16
#define HOST_CTRL0_FSEL_MASK (0x7 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_10M (0x1 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0 HOST_CTRL0_FSEL_SHIFT)
...then the code doesn't need to think about shifts, right?
if (IS_ERR(ref_clk)) {
dev_err(sphy-dev, Failed to get reference clock\n);
return PTR_ERR(ref_clk);
}
- switch (clk_get_rate(ref_clk)) {
- case 12 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_12M;
- break;
- case 24 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_24M;
- break;
- case 48 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_48M;
- break;
- default:
- if (sphy-cpu_type == TYPE_S3C64XX)
- refclk_freq = PHYCLK_CLKSEL_48M;
- else
+ if (sphy-cpu_type == TYPE_EXYNOS5250) {
+ /* set clock frequency for PLL */
+ switch (clk_get_rate(ref_clk)) {
+ case 96 * 10:
nit: change to 9600 * KHZ to match; below too.
sure.
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_9600K;
Why |= with 0?
kept this just to keep things look similar :-). will remove this line,
My comment was about keeping things similar. Right now the 5250 code
has the |= and the non-5250 code doesn't. I don't care which is
picked but the two sides of the if should be symmetric.
See parts of the patch below.
+ break;
+ case 10 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_10M;
+ break;
+ case 12 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_12M;
+ break;
+ case 192 * 10:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_19200K;
+ break;
+ case 20 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_20M;
+ break;
+ case 50 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_50M;
+ break;
+ case 24 * MHZ:
+ default:
+ /* default reference clock */
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_24M;
+ break;
+ }
+ } else {
+ switch (clk_get_rate(ref_clk)) {
+ case 12 * MHZ:
+ refclk_freq = PHYCLK_CLKSEL_12M;
+ break;
+ case 24 * MHZ:
refclk_freq = PHYCLK_CLKSEL_24M;
- break;
+ break;
+ case 48 * MHZ:
+ refclk_freq = PHYCLK_CLKSEL_48M;
+ break;
+ default:
+ if (sphy-cpu_type == TYPE_S3C64XX)
+ refclk_freq = PHYCLK_CLKSEL_48M;
+ else
+ refclk_freq = PHYCLK_CLKSEL_24M;
+ break;
+ }
}
clk_put(ref_clk);
return refclk_freq;
}
-Doug
