Re: [PATCH 2/3] PM / OPP: Initialize OPP table from device tree
On Thu, Jul 19, 2012 at 10:54 AM, Shawn Guo shawn@linaro.org wrote:
With a lot of devices booting from device tree nowadays, it requires
that OPP table can be initialized from device tree. The patch adds
a helper function of_init_opp_table together with a binding doc for
that purpose.
nice to see this happen, a quick feedback:
Signed-off-by: Shawn Guo shawn@linaro.org
---
Documentation/devicetree/bindings/power/opp.txt | 29 ++
drivers/base/power/opp.c| 66
+++
include/linux/opp.h |4 ++
3 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/opp.txt
diff --git a/Documentation/devicetree/bindings/power/opp.txt
b/Documentation/devicetree/bindings/power/opp.txt
new file mode 100644
index 000..1dd0db2
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/opp.txt
@@ -0,0 +1,29 @@
+* Generic OPP Interface
+
+SoCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. These
+are called Operating Performance Points or OPPs.
+
+Properties:
+- operating-points: An array of 3-tuples items, and each item consists
+ of frequency, voltage and enabling like freq vol en.
+ freq: clock frequency in kHz
+ vol: voltage in microvolt
+ en: initially enabled (1) or not (0)
+
+Examples:
+
+cpu@0 {
+ compatible = arm,cortex-a9;
I am not sure how this works - would an example of OMAP4430, 60, 70
help? they have completely different OPP entries.
+ reg = 0;
+ next-level-cache = L2;
+ operating-points =
+ /* kHzuVen */
+ 120 1275000 0
+ 996000 1225000 1
+ 792000 110 1
+ 672000 110 0
+ 396000 95 1
+ 198000 85 1
Just my 2cents, If we change en to be a flag:
0 - add, but disable
1 - add (enabled)
we could extend this further if the definition is a flag, for example:
2 - add and disable IF any of notifier chain return failure
3- add but dont call notifier chain (e.g. OPPs that are present for All SoC)
in addition, SoC might have additional properties associated with each
OPP such a flag
could be split up to mean lower 16 bits as OPP library flag and higher
16 bit to mean SoC custom flag
Example - On certain SoC a specific type of power technique is
supposed to be used per OPP, such a flag
passed on via notifiers to SoC handler might be capable of
centralizing the OPP information into the DT.
+ ;
+};
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index ac993ea..2d750f9 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -22,6 +22,7 @@
#include linux/rculist.h
#include linux/rcupdate.h
#include linux/opp.h
+#include linux/of.h
/*
* Internal data structure organization with the OPP layer library is as
@@ -674,3 +675,68 @@ struct srcu_notifier_head *opp_get_notifier(struct
device *dev)
return dev_opp-head;
}
+
+#ifdef CONFIG_OF
+/**
+ * of_init_opp_table() - Initialize opp table from device tree
+ * @dev: device pointer used to lookup device OPPs.
+ *
+ * Register the initial OPP table with the OPP library for given device.
+ */
+int of_init_opp_table(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ const char *propname = operating-points;
+ const struct property *pp;
+ u32 *opp;
+ int ret, i, nr;
+
+ pp = of_find_property(np, propname, NULL);
+ if (!pp) {
+ dev_err(dev, %s: Unable to find property, __func__);
+ return -ENODEV;
+ }
+
+ opp = kzalloc(pp-length, GFP_KERNEL);
+ if (!opp) {
+ dev_err(dev, %s: Unable to allocate array\n, __func__);
+ return -ENOMEM;
+ }
+
+ nr = pp-length / sizeof(u32);
error warn if the pp-length is not multiple of u32? we also expect
later on to be a multiple of 3(f,v,disable
+ ret = of_property_read_u32_array(np, propname, opp, nr);
+ if (ret) {
+ dev_err(dev, %s: Unable to read OPPs\n, __func__);
+ goto out;
+ }
+
+ nr /= 3;
+ for (i = 0; i nr; i++) {
+ /*
+* Each OPP is a set of tuples consisting of frequency,
+* voltage and availability like freq-kHz vol-uV enable.
+*/
+ u32 *val = opp + i * 3;
+
+ val[0] *= 1000;
+ ret = opp_add(dev, val[0], val[1]);
+ if (ret) {
+ dev_warn(dev, %s: Failed to add OPP %d: %d\n,
+__func__, val[0], ret);
+ continue;
+ }
+
+ if (!val[2]) {
+ ret =
RE: [PATCH V2 3/7] ARM: EXYNOS5: add machine specific support for LCD
Hello,
On Thursday, July 19, 2012 3:22 PM Leela Krishna Amudala wrote:
Hello Marek,
On Wed, Jul 18, 2012 at 12:15 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On Wednesday, July 18, 2012 7:57 AM Leela Krishna Amudala wrote:
This patch adds machine specific support for LCD controller like setting
power to LCD
and adding LCD platform device.
Signed-off-by: Prathyush K prathyus...@samsung.com
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
arch/arm/mach-exynos/mach-exynos5-dt.c | 56
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-
dt.c
index e7113cc..02a0e68 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -13,6 +13,7 @@
#include linux/serial_core.h
#include linux/pwm_backlight.h
#include linux/gpio.h
+#include linux/delay.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
@@ -24,6 +25,7 @@
#include plat/gpio-cfg.h
#include common.h
+#include video/platform_lcd.h
static int smdk5250_bl_notify(struct device *unused, int brightness)
{
@@ -47,6 +49,55 @@ static struct platform_pwm_backlight_data
smdk5250_bl_data = {
.notify = smdk5250_bl_notify,
};
+static void lcd_set_power(struct plat_lcd_data *pd,
+ unsigned int power)
+{
+
+ /* reset */
+ gpio_request_one(EXYNOS5_GPX1(5), GPIOF_OUT_INIT_HIGH, GPX1);
+
+ mdelay(20);
+ if (power) {
+ /* fire nRESET on power up */
+ gpio_set_value(EXYNOS5_GPX1(5), 0);
+ mdelay(20);
+ gpio_set_value(EXYNOS5_GPX1(5), 1);
+ mdelay(20);
+ gpio_free(EXYNOS5_GPX1(5));
+ } else {
+ /* fire nRESET on power off */
+ gpio_set_value(EXYNOS5_GPX1(5), 0);
+ mdelay(20);
+ gpio_set_value(EXYNOS5_GPX1(5), 1);
+ mdelay(20);
+ gpio_free(EXYNOS5_GPX1(5));
+ }
+ mdelay(20);
+
+ /*
+ * Request lcd_bl_en GPIO for smdk5250_bl_notify().
+ * TODO: Fix this so we are not at risk of requesting the GPIO
+ * multiple times, this should be done with device tree, and
+ * likely integrated into the plat-samsung/dev-backlight.c init.
+ */
+ gpio_request_one(EXYNOS5_GPX3(0), GPIOF_OUT_INIT_LOW, GPX3);
+}
+
+static int smdk5250_match_fb(struct plat_lcd_data *pd, struct fb_info
*info)
+{
+ /* Don't call .set_power callback while unblanking */
+ return 0;
+}
+
+static struct plat_lcd_data smdk5250_lcd_data = {
+ .set_power = lcd_set_power,
+ .match_fb = smdk5250_match_fb,
+};
+
+static struct platform_device smdk5250_lcd = {
+ .name = platform-lcd,
+ .dev.platform_data = smdk5250_lcd_data,
+};
/*
* The following lookup table is used to override device names when
devices
* are registered from device tree. This is temporarily added to enable
@@ -85,6 +136,10 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[]
__initconst
= {
{},
};
+static struct platform_device *smdk5250_devices[] __initdata = {
+ smdk5250_lcd, /* for platform_lcd device */
+};
+
static void __init exynos5250_dt_map_io(void)
{
exynos_init_io(NULL, 0);
@@ -96,6 +151,7 @@ static void __init exynos5250_dt_machine_init(void)
samsung_bl_set(smdk5250_bl_gpio_info, smdk5250_bl_data);
of_platform_populate(NULL, of_default_bus_match_table,
exynos5250_auxdata_lookup, NULL);
+ platform_add_devices(smdk5250_devices, ARRAY_SIZE(smdk5250_devices));
}
static char const *exynos5250_dt_compat[] __initdata = {
Sorry, but this patch looks completely weird to me. exynos5-dt machine is
aimed to
operate on ANY Exynos5 based board with proper device tree bindings, not
only SMDK5250.
Please add DT support to platform lcd driver and create required bindings
for it
instead of hardcoding the platform data and gpio numbers in
mach-exynos5-dt.c
Yes true, that GPIO numbers will vary for boards.
Can you please confirm that platform lcd driver means the core
drivers/video/backlight/platform_lcd.c file.
Yes, by lcd driver I meant that driver.
But platform lcd driver is used by other(non samsung) platforms also.
So, If I add the DT suppot to that file, I have to test the changes on
other platforms also.
Can you please kindly suggest me some other way to overcome this situation.
Just check that you don't break existing code. For some examples please refer
to the DT
changes in drivers/input/keyboard/gpio_keys.c (see commit fd05d08920). You can
also check
if the driver works fine after your changes by setting
RE: [PATCH V2 1/7] ARM: SAMSUNG: add additional registers and SFR definitions for writeback
Hello, On Thursday, July 19, 2012 2:44 PM Leela Krishna Amudala Hello Marek, On Wed, Jul 18, 2012 at 12:21 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On Wednesday, July 18, 2012 7:57 AM Leela Krishna Amudala wrote: This patch updates the register address offsets and adds SFR definitions for writeback for Samsung's V8 display controller. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 10 arch/arm/plat-samsung/include/plat/regs-fb.h| 51 +++ drivers/video/Kconfig |6 +++ 3 files changed, 67 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h b/arch/arm/plat- samsung/include/plat/regs-fb-v4.h index 4c3647f..1639c17 100644 --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h +++ b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h @@ -30,9 +30,16 @@ #define VIDCON1_FSTATUS_EVEN (1 15) /* Video timing controls */ +#ifdef CONFIG_FB_EXYNOS_FIMD_V8 +#define VIDTCON0(0x20010) +#define VIDTCON1(0x20014) +#define VIDTCON3(0x2001C) +#else #define VIDTCON0 (0x10) #define VIDTCON1 (0x14) #define VIDTCON2 (0x18) +#define VIDTCON3 (0x1C) +#endif /* Window position controls */ @@ -43,9 +50,12 @@ #define VIDOSD_BASE (0x40) #define VIDINTCON0 (0x130) +#define VIDINTCON1 (0x134) /* WINCONx */ +#define WINCONx_CSC_CON_EQ709 (1 28) +#define WINCONx_CSC_CON_EQ601 (0 28) #define WINCONx_CSCWIDTH_MASK(0x3 26) #define WINCONx_CSCWIDTH_SHIFT (26) #define WINCONx_CSCWIDTH_WIDE(0x0 26) diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat- samsung/include/plat/regs-fb.h index 9a78012..6d2ee16 100644 --- a/arch/arm/plat-samsung/include/plat/regs-fb.h +++ b/arch/arm/plat-samsung/include/plat/regs-fb.h @@ -32,12 +32,28 @@ #define VIDCON0 (0x00) #define VIDCON0_INTERLACE(1 29) + +#ifdef CONFIG_FB_EXYNOS_FIMD_V8 +#define VIDOUT_CON (0x2) +#define VIDOUT_CON_VIDOUT_UP_MASK(0x1 16) +#define VIDOUT_CON_VIDOUT_UP_SHIFT (16) +#define VIDOUT_CON_VIDOUT_UP_ALWAYS (0x0 16) +#define VIDOUT_CON_VIDOUT_UP_START_FRAME (0x1 16) +#define VIDOUT_CON_VIDOUT_F_MASK (0x7 8) +#define VIDOUT_CON_VIDOUT_F_SHIFT(8) +#define VIDOUT_CON_VIDOUT_F_RGB (0x0 8) +#define VIDOUT_CON_VIDOUT_F_I80_LDI0 (0x2 8) +#define VIDOUT_CON_VIDOUT_F_I80_LDI1 (0x3 8) +#define VIDOUT_CON_VIDOUT_F_WB (0x4 8) +#endif + #define VIDCON0_VIDOUT_MASK (0x3 26) #define VIDCON0_VIDOUT_SHIFT (26) #define VIDCON0_VIDOUT_RGB (0x0 26) #define VIDCON0_VIDOUT_TV(0x1 26) #define VIDCON0_VIDOUT_I80_LDI0 (0x2 26) #define VIDCON0_VIDOUT_I80_LDI1 (0x3 26) +#define VIDCON0_VIDOUT_WB (0x4 26) #define VIDCON0_L1_DATA_MASK (0x7 23) #define VIDCON0_L1_DATA_SHIFT(23) @@ -81,7 +97,13 @@ #define VIDCON0_ENVID(1 1) #define VIDCON0_ENVID_F (1 0) +#ifdef CONFIG_FB_EXYNOS_FIMD_V8 +#define VIDOUT_CON (0x2) +#define VIDCON1 (0x20004) +#else #define VIDCON1 (0x04) +#endif + #define VIDCON1_LINECNT_MASK (0x7ff 16) #define VIDCON1_LINECNT_SHIFT(16) #define VIDCON1_LINECNT_GET(_v) (((_v) 16) 0x7ff) @@ -111,6 +133,14 @@ #define VIDCON2_TVFMTSEL1_RGB(0x0 12) #define VIDCON2_TVFMTSEL1_YUV422 (0x1 12) #define VIDCON2_TVFMTSEL1_YUV444 (0x2 12) +#define VIDCON2_TVFMTSEL1_SHIFT (12) +#define VIDCON2_TVFMTSEL_SW (1 14) +#define VIDCON2_TVFORMATSEL_YUV444 (0x2 12) + +#define VIDCON2_TVFMTSEL1_MASK (0x3 12) +#define VIDCON2_TVFMTSEL1_RGB(0x0 12) +#define VIDCON2_TVFMTSEL1_YUV422 (0x1 12) +#define VIDCON2_TVFMTSEL1_YUV444 (0x2 12) #define VIDCON2_ORGYCbCr (1 8)
[patch] driver-core: dev_to_node() should handle NULL pointers
What prompted this patch is that in dma_pool_create() we call
dev_to_node() before checking whether dev is NULL. It looks like
there are places which call dma_pool_create() with a NULL pointer. An
example is in drivers/usb/gadget/amd5536udc.c.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Static checker fix.
diff --git a/include/linux/device.h b/include/linux/device.h
index aa7b3b4..c80e7a8d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -714,7 +714,9 @@ int dev_set_name(struct device *dev, const char *name, ...);
#ifdef CONFIG_NUMA
static inline int dev_to_node(struct device *dev)
{
- return dev-numa_node;
+ if (dev)
+ return dev-numa_node;
+ return -1;
}
static inline void set_dev_node(struct device *dev, int node)
{
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/2] Add pinctrl support to AM33XX family of devices
Adds pinctrl support to AM33XX family of devices. These patches were tested on AM335x-Bone and AM335x-EVM Changes from v1: - Rebased the patches based on latest pinctrl-single driver AnilKumar Ch (2): arm/dts: Add AM33XX basic pinctrl support arm/dts: Configure pinmuxs for user leds control on Bone arch/arm/boot/dts/am335x-bone.dts | 15 +++ arch/arm/boot/dts/am33xx.dtsi |9 + 2 files changed, 24 insertions(+), 0 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/2] arm/dts: Configure pinmuxs for user leds control on Bone
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index a4d4415..452ce3f 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -28,3 +28,18 @@
};
/include/ tps65217.dtsi
+
+am3358_pinmux {
+
+ pinctrl-names = default;
+ pinctrl-0 = userled_pins;
+
+ userled_pins: pinmux_userled_pins {
+ pinctrl-single,pins =
+ 0x54 0x7/* gpmc_a5.gpio1_21, OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x58 0x17 /* gpmc_a6.gpio1_22,
OMAP_PIN_OUTPUT_PULLUP | OMAP_MUX_MODE7 */
+ 0x5C 0x7/* gpmc_a7.gpio1_23, OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x60 0x17 /* gpmc_a8.gpio1_24,
OMAP_PIN_OUTPUT_PULLUP | OMAP_MUX_MODE7 */
+ ;
+ };
+};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/2] arm/dts: Add AM33XX basic pinctrl support
Add basic pinctrl support for AM33XX family of devices by adding DT
data to am33xx dtsi file. These patches are based on pinctrl-single
driver and tested on am335x-evm am335x-bone devices.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..9b974dc 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44E10800 {
+ compatible = pinctrl-single;
+ reg = 0x44E10800 0x0338;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x7F;
+ };
+
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp
On Fri, Jul 20, 2012 at 12:06:50PM +0530, Shilimkar, Santosh wrote: On Thu, Jul 19, 2012 at 9:24 PM, Shawn Guo shawn@linaro.org wrote: From: Richard Zhao richard.z...@linaro.org If CONFIG_SMP, cpufreq skips loops_per_jiffy update, because different arch has different per-cpu loops_per_jiffy definition. Signed-off-by: Richard Zhao richard.z...@linaro.org Acked-by: Russell King rmk+ker...@arm.linux.org.uk --- Nice. Avoids other driver duplicating this code. May be you can keep Richard's credit in commit too. It's all Richard's credit in the commit. FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks. -- Regards, Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] PM / OPP: Initialize OPP table from device tree
On Fri, Jul 20, 2012 at 3:46 AM, Shawn Guo shawn@linaro.org wrote:
+ ret = of_property_read_u32_array(np, propname, opp, nr);
+ if (ret) {
+ dev_err(dev, %s: Unable to read OPPs\n, __func__);
+ goto out;
+ }
+
+ nr /= 3;
+ for (i = 0; i nr; i++) {
+ /*
+* Each OPP is a set of tuples consisting of frequency,
+* voltage and availability like freq-kHz vol-uV enable.
+*/
+ u32 *val = opp + i * 3;
+
+ val[0] *= 1000;
+ ret = opp_add(dev, val[0], val[1]);
+ if (ret) {
+ dev_warn(dev, %s: Failed to add OPP %d: %d\n,
+__func__, val[0], ret);
+ continue;
+ }
+
+ if (!val[2]) {
+ ret = opp_disable(dev, val[0]);
Since we are updating the table out of context of the SoC users,
consider what might happen if someone where to operate on the OPP
after opp_add, but before opp_disable?
I would take this as another comment reminding me to remove the
enabling/availability tuple from the binding. Will do it in the
next version.
I am not completely convinced that dropping the flag would be the best approach
on a long run, but might be a good starting point while we meet current reqs and
as a need arises, could increase the scope. Thanks once again for doing this.
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2 v3] USB: dwc3-exynos: Add support for device tree
Hi,
On Mon, Jul 16, 2012 at 11:27:38AM +0530, Vivek Gautam wrote:
This patch adds support to parse probe data for
dwc3 driver for exynos using device tree
Signed-off-by: Praveen Paneri p.pan...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index b8f0038..a293c69 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -19,6 +19,7 @@
#include linux/platform_data/dwc3-exynos.h
#include linux/dma-mapping.h
#include linux/clk.h
+#include linux/of.h
#include core.h
@@ -29,6 +30,8 @@ struct dwc3_exynos {
struct clk *clk;
};
+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
+
static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
{
struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
@@ -45,6 +48,16 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
goto err0;
}
+ /*
+ * Right now device-tree probed devices don't get dma_mask set.
+ * Since shared usb code relies on it, set it here for now.
+ * Once we move to full device tree support this will vanish off.
+ */
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = dwc3_exynos_dma_mask;
+ if (!pdev-dev.coherent_dma_mask)
+ pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
platform_set_drvdata(pdev, exynos);
devid = dwc3_get_device_id();
@@ -134,11 +147,20 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_xhci_match[] = {
+ { .compatible = samsung,exynos-xhci },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_xhci_match);
this is not an xhci device. It contains one inside of it, but it's not
an xhci device.
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/7] ARM: SAMSUNG: add additional registers and SFR definitions for writeback
On 07/20/2012 04:59 AM, Leela Krishna Amudala wrote: --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h +++ b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h @@ -30,9 +30,16 @@ #define VIDCON1_FSTATUS_EVEN (1 15) /* Video timing controls */ +#ifdef CONFIG_FB_EXYNOS_FIMD_V8 +#define VIDTCON0(0x20010) +#define VIDTCON1(0x20014) +#define VIDTCON3(0x2001C) +#else #define VIDTCON0 (0x10) #define VIDTCON1 (0x14) #define VIDTCON2 (0x18) +#define VIDTCON3 (0x1C) +#endif Wouldn't it break s3c-fb on SoCs with earlier FIMD versions with CONFIG_FB_EXYNOS_FIMD_V8 selected? We are aiming at multi-platform ARM kernels, aren't we (i.e support of both V8 and earlier FIMD in one kernel)? Exynos5 has FIMD_V8 and other SoCs has older FIMD versions. As address offsets for certain registers has changed in FIMD_V8, we introduced these defines. So we have to select CONFIG_FB_EXYNOS_FIMD_V8 in case of Exynos5 SoC, and deselect for other SoCs. Yes, I'm aware of different FIMD versions in different SoCs. My point is that it shouldn't be necessary to deselect CONFIG_FB_EXYNOS_FIMD_V8 to support other SoCs than Exynos5, i.e. additional config options should be incremental - should not break other setups. Ideally there should not be any new config option for FIMD v8. The detection of FIMD version and selection of appropriate register offsets should be done in the driver at runtime, based for example on platform_device_id (see the s3c-fb driver and usage of s3c_fb_driverdata and s3c_fb_win_variant structs). I could not agree with Tomasz Figa more. FIMD register offset should be selected at runtime. Leela Krishna Amudala, Please, don't use ugly #ifdef. Best regards, Jingoo Han Yes, Each SoC having its own defconfigs (eg: exynos4_defconfig, exynos5_defconfig etc.,) So, CONFIG_FB_EXYNOS_FIMD_V8 will be added into exynos5_defconfig and it won't affect the other SoCs. NACK. As others explained, and you don't seem to understand or you are stubborn enough not to change your approach, resolving hardware differences at compile time only is not acceptable, especially that Exynos SoCs are going to be DT only platforms. We shouldn't be short-sighted like this. Especially that the problem is relatively easy to solve at run-time, just add EXYNOS5_* register address definitions and create separate functions at the driver(s) touching those registers that changed on Exynos5. Or parametrize existing ones with an offset that would be stored in driver data passed trough struct platform_device_id::driver_data. @Jingoo: BTW, shouldn't we have plat-samsung/include/plat/regs-fb.h plat-samsung/include/plat/regs-fb-v4.h merged into one file and moved under include/video/ ? For example include/video/s3c-fb.h, and board files could also include that header. We have FIMD variant structures anyway, so why do we still need multiple headers ? -- Regards, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/7] ARM: SAMSUNG: add additional registers and SFR definitions for writeback
On 07/18/2012 09:09 AM, Ajay kumar wrote: +config FB_EXYNOS_FIMD_V8 + bool register extensions for FIMD version 8 + depends on ARCH_EXYNOS5 + ---help--- + This uses register extensions for FIMD version 8 + config FB_S3C_DEBUG_REGWRITE bool Debug register writes depends on FB_S3C Do we really need these defines in arch/arm/plat-samsung/include/plat/regs-fb* ? IMHO they should be moved from arch/arm to drivers/video to live together with the driver. They are not a part of core platform code. I thought that there have been some patches cleaning up regs-fb mess a long time ago, but it looks they didn't get their way to mainline. http://comments.gmane.org/gmane.linux.kernel.samsung-soc/5826 These patches are merged. I created the patchset. I felt it was redundant to have regs-fb.h in individual samsung boards(arch/arm/mach-s*), so I moved them to plat-samsung. We still need to move plat/regs-fb.h to driver side. Great. These headers are now used by drivers/video/s3c-fb.c and drivers/gpu/drm/exynos/exynos_drm_fimd.c, so we probably need to merge them into one file under include/video. -- Regards, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/7] ARM: SAMSUNG: add additional registers and SFR definitions for writeback
Hello, On Fri, Jul 20, 2012 at 3:30 PM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 07/20/2012 04:59 AM, Leela Krishna Amudala wrote: --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h +++ b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h @@ -30,9 +30,16 @@ #define VIDCON1_FSTATUS_EVEN (1 15) /* Video timing controls */ +#ifdef CONFIG_FB_EXYNOS_FIMD_V8 +#define VIDTCON0(0x20010) +#define VIDTCON1(0x20014) +#define VIDTCON3(0x2001C) +#else #define VIDTCON0 (0x10) #define VIDTCON1 (0x14) #define VIDTCON2 (0x18) +#define VIDTCON3 (0x1C) +#endif Wouldn't it break s3c-fb on SoCs with earlier FIMD versions with CONFIG_FB_EXYNOS_FIMD_V8 selected? We are aiming at multi-platform ARM kernels, aren't we (i.e support of both V8 and earlier FIMD in one kernel)? Exynos5 has FIMD_V8 and other SoCs has older FIMD versions. As address offsets for certain registers has changed in FIMD_V8, we introduced these defines. So we have to select CONFIG_FB_EXYNOS_FIMD_V8 in case of Exynos5 SoC, and deselect for other SoCs. Yes, I'm aware of different FIMD versions in different SoCs. My point is that it shouldn't be necessary to deselect CONFIG_FB_EXYNOS_FIMD_V8 to support other SoCs than Exynos5, i.e. additional config options should be incremental - should not break other setups. Ideally there should not be any new config option for FIMD v8. The detection of FIMD version and selection of appropriate register offsets should be done in the driver at runtime, based for example on platform_device_id (see the s3c-fb driver and usage of s3c_fb_driverdata and s3c_fb_win_variant structs). I could not agree with Tomasz Figa more. FIMD register offset should be selected at runtime. Leela Krishna Amudala, Please, don't use ugly #ifdef. Best regards, Jingoo Han Yes, Each SoC having its own defconfigs (eg: exynos4_defconfig, exynos5_defconfig etc.,) So, CONFIG_FB_EXYNOS_FIMD_V8 will be added into exynos5_defconfig and it won't affect the other SoCs. NACK. As others explained, and you don't seem to understand or you are stubborn enough not to change your approach, resolving hardware differences at compile time only is not acceptable, especially that Exynos SoCs are going to be DT only platforms. We shouldn't be short-sighted like this. Especially that the problem is relatively easy to solve at run-time, just add EXYNOS5_* register address definitions and create separate functions at the driver(s) touching those registers that changed on Exynos5. Or parametrize existing ones with an offset that would be stored in driver data passed trough struct platform_device_id::driver_data. @Jingoo: BTW, shouldn't we have plat-samsung/include/plat/regs-fb.h plat-samsung/include/plat/regs-fb-v4.h merged into one file and moved under include/video/ ? For example include/video/s3c-fb.h, and board files could also include that header. We have FIMD variant structures anyway, so why do we still need multiple headers ? Will do the run-time approach, and post the next version patchset soon. Thanks, Leela Krishna Amudala -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv2 1/2] ARM: vt8500: Update vt8500-ehci driver to support device tree.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
.../devicetree/bindings/usb/vt8500-ehci.txt| 10 ++
drivers/usb/host/ehci-vt8500.c |9 +
2 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt
diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
new file mode 100644
index 000..74f75c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
@@ -0,0 +1,10 @@
+VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
+
+Required properties:
+ - compatible: Should be via,vt8500-ehci or wm,prizm-ehci.
+
+usb: ehci@D8007100 {
+ compatible = wm,prizm-ehci, usb-ehci;
+ reg = 0xD8007100 0x200;
+ interrupts = 1;
+};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index c1eda73..4ba8f0c 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,6 +16,7 @@
*
*/
+#include linux/of.h
#include linux/platform_device.h
static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
@@ -162,6 +163,12 @@ static int vt8500_ehci_drv_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = via,vt8500-ehci, },
+ { .compatible = wm,prizm-ehci, },
+ {}
+};
+
static struct platform_driver vt8500_ehci_driver = {
.probe = vt8500_ehci_drv_probe,
.remove = vt8500_ehci_drv_remove,
@@ -169,7 +176,9 @@ static struct platform_driver vt8500_ehci_driver = {
.driver = {
.name = vt8500-ehci,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
MODULE_ALIAS(platform:vt8500-ehci);
+MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 0/2] Add device tree and clock support for Gscaler.
This patch series adds clock support for Gscaler and device node entries for Gscaler on exynos5. This patch is based on Kukjin Kim's (linux-samsung) for-next branch. https://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git changes since v2: - Addressed review comments from Sylwester Nawrocki http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg11372.html - Addressed review comments from Kukjin Kim and Sunyoung Kang http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg11377.html http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg11429.html Shaik Ameer Basha (2): ARM: EXYNOS: Add clock support for Gscaler ARM: EXYNOS: Add Gscaler device from DT .../devicetree/bindings/media/exynos5-gsc.txt | 32 ++ arch/arm/boot/dts/exynos5250.dtsi | 28 ++ arch/arm/mach-exynos/clock-exynos5.c | 100 arch/arm/mach-exynos/include/mach/map.h|3 + arch/arm/mach-exynos/mach-exynos5-dt.c |8 ++ 5 files changed, 171 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/exynos5-gsc.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 2/2] ARM: EXYNOS: Add Gscaler device from DT
This patch adds,
- 4 Gscaler devices to the DT device list
- Gscaler specific entries to the machine file
- binding documentation for Gscaler entries
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
.../devicetree/bindings/media/exynos5-gsc.txt | 32
arch/arm/boot/dts/exynos5250.dtsi | 28 +
arch/arm/mach-exynos/include/mach/map.h|3 ++
arch/arm/mach-exynos/mach-exynos5-dt.c |8 +
4 files changed, 71 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/exynos5-gsc.txt
diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
new file mode 100644
index 000..1cb4ea0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -0,0 +1,32 @@
+* Samsung Exynos5 Gscaler device
+
+Gscaler is used for scaling and color space conversion on EXYNOS5 SoCs.
+
+Required properties:
+- compatible: should be samsung,exynos5250-gsc
+- reg: should contain Gscaler physical address location and length.
+- interrupts: should contain Gscaler interrupt number
+
+Example:
+
+gsc_0: gsc@0x13e0 {
+ compatible = samsung,exynos5250-gsc;
+ reg = 0x13e0 0x1000;
+ interrupts = 0 85 0;
+};
+
+Aliases:
+Each Gscaler node should have a numbered alias in the aliases node,
+in the form of gscN, N = 0...3. Gscaler driver uses these aliases
+to retrieve the device IDs using of_alias_get_id() call.
+
+Example:
+
+aliases {
+ gsc0 =gsc_0;
+ gsc1 =gsc_1;
+ gsc2 =gsc_2;
+ gsc3 =gsc_3;
+};
+
+
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index a3a2eb2..ad6c3c5 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -27,6 +27,10 @@
spi0 = spi_0;
spi1 = spi_1;
spi2 = spi_2;
+ gsc0 = gsc_0;
+ gsc1 = gsc_1;
+ gsc2 = gsc_2;
+ gsc3 = gsc_3;
};
gic:interrupt-controller@10481000 {
@@ -460,4 +464,28 @@
#gpio-cells = 4;
};
};
+
+ gsc_0: gsc@0x13e0 {
+ compatible = samsung,exynos5250-gsc;
+ reg = 0x13e0 0x1000;
+ interrupts = 0 85 0;
+ };
+
+ gsc_1: gsc@0x13e1 {
+ compatible = samsung,exynos5250-gsc;
+ reg = 0x13e1 0x1000;
+ interrupts = 0 86 0;
+ };
+
+ gsc_2: gsc@0x13e2 {
+ compatible = samsung,exynos5250-gsc;
+ reg = 0x13e2 0x1000;
+ interrupts = 0 87 0;
+ };
+
+ gsc_3: gsc@0x13e3 {
+ compatible = samsung,exynos5250-gsc;
+ reg = 0x13e3 0x1000;
+ interrupts = 0 88 0;
+ };
};
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index c72b675..217e470 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -121,6 +121,9 @@
#define EXYNOS4_PA_SYSMMU_MFC_L0x1362
#define EXYNOS4_PA_SYSMMU_MFC_R0x1363
+/* x = 0...3 */
+#define EXYNOS5_PA_GSC(x) (0x13e0 + ((x) * 0x1))
+
#define EXYNOS5_PA_SYSMMU_MDMA10x10A4
#define EXYNOS5_PA_SYSMMU_SSS 0x10A5
#define EXYNOS5_PA_SYSMMU_2D 0x10A6
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index ef770bc..fd8f1ca 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -56,6 +56,14 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
OF_DEV_AUXDATA(arm,pl330, EXYNOS5_PA_PDMA0, dma-pl330.0, NULL),
OF_DEV_AUXDATA(arm,pl330, EXYNOS5_PA_PDMA1, dma-pl330.1, NULL),
OF_DEV_AUXDATA(arm,pl330, EXYNOS5_PA_MDMA1, dma-pl330.2, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-gsc, EXYNOS5_PA_GSC(0),
+ exynos-gsc.0, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-gsc, EXYNOS5_PA_GSC(1),
+ exynos-gsc.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-gsc, EXYNOS5_PA_GSC(2),
+ exynos-gsc.2, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-gsc, EXYNOS5_PA_GSC(3),
+ exynos-gsc.3, NULL),
{},
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/7] ARM: SAMSUNG: add additional registers and SFR definitions for writeback
On 07/20/2012 01:07 PM, Leela Krishna Amudala wrote: Will do the run-time approach, and post the next version patchset soon. Great, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] cpufreq: Add a generic cpufreq-cpu0 driver
On Fri, Jul 20, 2012 at 08:51:17PM +0800, Richard Zhao wrote: Hi, Shawn, I find you create a new driver rather than work on my generic cpufreq driver based on clk and regulator. Is there any reason besides adding opp support? Adopting OPP support forces me to look at omap-cpufreq driver, hence makes me create a new driver by referencing to omap-cpufreq. -- Regards, Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: vt8500: Minor updates to platform drivers for devicetree support
Updated the vt8500-rtc and vt8500-uart platform drivers for
devicetree support.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
.../devicetree/bindings/rtc/vt8500-rtc.txt | 14 ++
.../devicetree/bindings/tty/serial/vt8500-uart.txt | 14 ++
drivers/rtc/rtc-vt8500.c |8
drivers/tty/serial/vt8500_serial.c |8
4 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/vt8500-rtc.txt
create mode 100644 Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
diff --git a/Documentation/devicetree/bindings/rtc/vt8500-rtc.txt
b/Documentation/devicetree/bindings/rtc/vt8500-rtc.txt
new file mode 100644
index 000..8cf6ce1
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/vt8500-rtc.txt
@@ -0,0 +1,14 @@
+* SPEAr RTC
+
+Required properties:
+- compatible : via,vt8500-rtc
+- reg : Address range of the rtc registers
+- interrupt: Should contain the rtc interrupt number
+
+Example:
+
+ rtc@d810 {
+ compatible = via,vt8500-rtc;
+ reg = 0xd810 0x2c;
+ interrupts = 48;
+ };
diff --git a/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
b/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
new file mode 100644
index 000..745070a
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
@@ -0,0 +1,14 @@
+* VIA/Wondermedia Universal Asynchronous Receiver/Transmitter (UART)
+
+Required properties:
+- compatible: Should be via,vt8500-uart
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+
+Example:
+ uart0: serial@d820 {
+ compatible = via,vt8500-uart;
+ reg = 0xd820 0x1040;
+ interrupts = 32;
+ };
+
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 9e94fb1..2f155c2 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -23,6 +23,7 @@
#include linux/bcd.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of.h
/*
* Register definitions
@@ -302,12 +303,18 @@ static int __devexit vt8500_rtc_remove(struct
platform_device *pdev)
return 0;
}
+static const struct of_device_id vt8500_rtc_ids[] = {
+ { .compatible = via,vt8500-rtc, },
+ {}
+};
+
static struct platform_driver vt8500_rtc_driver = {
.probe = vt8500_rtc_probe,
.remove = __devexit_p(vt8500_rtc_remove),
.driver = {
.name = vt8500-rtc,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_rtc_ids),
},
};
@@ -317,3 +324,4 @@ MODULE_AUTHOR(Alexey Charkov alch...@gmail.com);
MODULE_DESCRIPTION(VIA VT8500 SoC Realtime Clock Driver (RTC));
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:vt8500-rtc);
+MODULE_DEVICE_TABLE(of, vt8500_rtc_ids);
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 2be006f..bd20b4e 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -34,6 +34,7 @@
#include linux/slab.h
#include linux/clk.h
#include linux/platform_device.h
+#include linux/of.h
/*
* UART Register offsets
@@ -603,12 +604,18 @@ static int __devexit vt8500_serial_remove(struct
platform_device *pdev)
return 0;
}
+static const struct of_device_id vt8500_uart_ids[] = {
+ { .compatible = via,vt8500-uart, },
+ {}
+};
+
static struct platform_driver vt8500_platform_driver = {
.probe = vt8500_serial_probe,
.remove = __devexit_p(vt8500_serial_remove),
.driver = {
.name = vt8500_serial,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_uart_ids),
},
};
@@ -643,3 +650,4 @@ module_exit(vt8500_serial_exit);
MODULE_AUTHOR(Alexey Charkov alch...@gmail.com);
MODULE_DESCRIPTION(Driver for vt8500 serial device);
MODULE_LICENSE(GPL);
+MODULE_DEVICE_TABLE(of, vt8500_uart_ids);
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv3 2/2] ARM: vt8500: Add support for UHCI companion controller
Add support for a generic non-pci UHCI companion controller.
Existing board files for arch-vt8500 updated to include UHCI
support.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
V3:
Added the missing commits for the board files.
arch/arm/mach-vt8500/bv07.c |1 +
arch/arm/mach-vt8500/devices-vt8500.c |5 +
arch/arm/mach-vt8500/devices-wm8505.c |4 +
arch/arm/mach-vt8500/devices.c| 11 +++
arch/arm/mach-vt8500/devices.h|1 +
arch/arm/mach-vt8500/wm8505_7in.c |1 +
drivers/usb/host/Kconfig | 12 ++-
drivers/usb/host/uhci-hcd.c |5 +
drivers/usb/host/uhci-platform.c | 157 +
9 files changed, 195 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/host/uhci-platform.c
diff --git a/arch/arm/mach-vt8500/bv07.c b/arch/arm/mach-vt8500/bv07.c
index a464c75..19d20d9 100644
--- a/arch/arm/mach-vt8500/bv07.c
+++ b/arch/arm/mach-vt8500/bv07.c
@@ -32,6 +32,7 @@ static struct platform_device *devices[] __initdata = {
vt8500_device_uart0,
vt8500_device_lcdc,
vt8500_device_ehci,
+ vt8500_device_uhci,
vt8500_device_ge_rops,
vt8500_device_pwm,
vt8500_device_pwmbl,
diff --git a/arch/arm/mach-vt8500/devices-vt8500.c
b/arch/arm/mach-vt8500/devices-vt8500.c
index 19519ae..def7fe3 100644
--- a/arch/arm/mach-vt8500/devices-vt8500.c
+++ b/arch/arm/mach-vt8500/devices-vt8500.c
@@ -48,6 +48,11 @@ void __init vt8500_set_resources(void)
tmp[1] = wmt_irq_res(IRQ_EHCI);
wmt_res_add(vt8500_device_ehci, tmp, 2);
+ /* vt8500 uses a single IRQ for both EHCI and UHCI controllers */
+ tmp[0] = wmt_mmio_res(VT8500_UHCI_BASE, SZ_512);
+ tmp[1] = wmt_irq_res(IRQ_EHCI);
+ wmt_res_add(vt8500_device_uhci, tmp, 2);
+
tmp[0] = wmt_mmio_res(VT8500_GEGEA_BASE, SZ_256);
wmt_res_add(vt8500_device_ge_rops, tmp, 1);
diff --git a/arch/arm/mach-vt8500/devices-wm8505.c
b/arch/arm/mach-vt8500/devices-wm8505.c
index db4594e..c810454 100644
--- a/arch/arm/mach-vt8500/devices-wm8505.c
+++ b/arch/arm/mach-vt8500/devices-wm8505.c
@@ -55,6 +55,10 @@ void __init wm8505_set_resources(void)
tmp[1] = wmt_irq_res(IRQ_EHCI);
wmt_res_add(vt8500_device_ehci, tmp, 2);
+ tmp[0] = wmt_mmio_res(WM8505_UHCI_BASE, SZ_512);
+ tmp[1] = wmt_irq_res(IRQ_UHCI);
+ wmt_res_add(vt8500_device_uhci, tmp, 2);
+
tmp[0] = wmt_mmio_res(WM8505_GEGEA_BASE, SZ_256);
wmt_res_add(vt8500_device_ge_rops, tmp, 1);
diff --git a/arch/arm/mach-vt8500/devices.c b/arch/arm/mach-vt8500/devices.c
index 1fcdc36..46ff82d 100644
--- a/arch/arm/mach-vt8500/devices.c
+++ b/arch/arm/mach-vt8500/devices.c
@@ -204,6 +204,17 @@ struct platform_device vt8500_device_ehci = {
},
};
+static u64 uhci_dma_mask = DMA_BIT_MASK(32);
+
+struct platform_device vt8500_device_uhci = {
+ .name = platform-uhci,
+ .id = 0,
+ .dev= {
+ .dma_mask = uhci_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
struct platform_device vt8500_device_ge_rops = {
.name = wmt_ge_rops,
.id = -1,
diff --git a/arch/arm/mach-vt8500/devices.h b/arch/arm/mach-vt8500/devices.h
index 188d4e1..0e6d9f9 100644
--- a/arch/arm/mach-vt8500/devices.h
+++ b/arch/arm/mach-vt8500/devices.h
@@ -81,6 +81,7 @@ extern struct platform_device vt8500_device_uart5;
extern struct platform_device vt8500_device_lcdc;
extern struct platform_device vt8500_device_wm8505_fb;
extern struct platform_device vt8500_device_ehci;
+extern struct platform_device vt8500_device_uhci;
extern struct platform_device vt8500_device_ge_rops;
extern struct platform_device vt8500_device_pwm;
extern struct platform_device vt8500_device_pwmbl;
diff --git a/arch/arm/mach-vt8500/wm8505_7in.c
b/arch/arm/mach-vt8500/wm8505_7in.c
index cf910a9..302ae2f 100644
--- a/arch/arm/mach-vt8500/wm8505_7in.c
+++ b/arch/arm/mach-vt8500/wm8505_7in.c
@@ -31,6 +31,7 @@ static void __iomem *pmc_hiber;
static struct platform_device *devices[] __initdata = {
vt8500_device_uart0,
vt8500_device_ehci,
+ vt8500_device_uhci,
vt8500_device_wm8505_fb,
vt8500_device_ge_rops,
vt8500_device_pwm,
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 83e58df..3d153d0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -450,7 +450,7 @@ config USB_OHCI_LITTLE_ENDIAN
config USB_UHCI_HCD
tristate UHCI HCD (most Intel and VIA) support
- depends on USB (PCI || SPARC_LEON)
+ depends on USB (PCI || SPARC_LEON || ARCH_VT8500)
---help---
The Universal Host Controller Interface is a standard by Intel for
accessing the USB hardware in the PC (which is also called the USB
@@ -468,7 +468,15 @@ config USB_UHCI_HCD
config USB_UHCI_SUPPORT_NON_PCI_HC
Re: [patch] driver-core: dev_to_node() should handle NULL pointers
On Fri, Jul 20, 2012 at 08:00:42AM -0700, Greg Kroah-Hartman wrote:
On Fri, Jul 20, 2012 at 09:56:23AM +0300, Dan Carpenter wrote:
What prompted this patch is that in dma_pool_create() we call
dev_to_node() before checking whether dev is NULL. It looks like
there are places which call dma_pool_create() with a NULL pointer. An
example is in drivers/usb/gadget/amd5536udc.c.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Static checker fix.
diff --git a/include/linux/device.h b/include/linux/device.h
index aa7b3b4..c80e7a8d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -714,7 +714,9 @@ int dev_set_name(struct device *dev, const char *name,
...);
#ifdef CONFIG_NUMA
static inline int dev_to_node(struct device *dev)
{
- return dev-numa_node;
+ if (dev)
+ return dev-numa_node;
+ return -1;
What happens if this function returns -1? Can the callers properly
handle this?
Gar. Now I'm not sure any more.
-1 means no affinity and it's what the dev_to_node() returns if NUMA
is disabled. But now I think probably it's important to get the
NUMA node correct in dma_pool_create() so this isn't the right
answer.
dma_pool_create() is not correct. It has code to handle a NULL
dev pointer, but the dev_to_node() dereference will cause an oops
before we reach it. I'm think this is a real issue that affects a
couple drivers. Maybe those people compile without NUMA?
I'm not sure the right fix now.
regards,
dan carpenter
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] cpufreq: Add a generic cpufreq-cpu0 driver
On Fri, Jul 20, 2012 at 5:33 AM, Shawn Guo shawn@linaro.org wrote: On Fri, Jul 20, 2012 at 12:22:14PM +0530, Shilimkar, Santosh wrote: This *_CPU0 doesn't seems to be appropriate since this infrastructure will be used on SMP systems where CPUs shares clock/voltage rails. May be you can get rid of that unless there is a strong need. All the resource handlers, clk, regulator, opp, DT node, are retrieved from CPU0 device even for SMP. I hope the naming of the driver could tell: - The driver supports UP - The driver supports SMP where CPUs shares clock/voltage rails by managing CPU0 (resource) - The driver does not support SMP where individual CPU can scale clock/voltage independently. How about cpufreq-single-thread.c and CONFIG_CPUFREQ_SINGLE_THREAD? That makes sense for both UP and SMP. Regards, Mike ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] dt/flattree: Add stub defintions for flat device tree functions
Several flattened device tree functions are missing stub functions
when CONFIG_OF_FLATTREE is not selected, creating compilation
errors. Add the stub functions.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
include/linux/of_fdt.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index ed136ad..e3d59cd 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -119,6 +119,11 @@ extern void unflatten_device_tree(void);
extern void early_init_devtree(void *);
#else /* CONFIG_OF_FLATTREE */
static inline void unflatten_device_tree(void) {}
+static inline void *of_get_flat_dt_prop(unsigned long node, const char *name,
+unsigned long *size) { return NULL; }
+
+static inline int of_flat_dt_is_compatible(unsigned long node,
+ const char *name) { return 0; }
#endif /* CONFIG_OF_FLATTREE */
#endif /* __ASSEMBLY__ */
--
1.7.8.3
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] ARM: vt8500: Update vt8500-ehci driver to support device tree.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
.../devicetree/bindings/usb/vt8500-ehci.txt| 10 ++
drivers/usb/host/ehci-vt8500.c |9 +
2 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt
diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
new file mode 100644
index 000..74f75c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
@@ -0,0 +1,10 @@
+VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
+
+Required properties:
+ - compatible: Should be via,vt8500-ehci or wm,prizm-ehci.
+
+usb: ehci@D8007100 {
+ compatible = wm,prizm-ehci, usb-ehci;
+ reg = 0xD8007100 0x200;
+ interrupts = 1;
+};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index c1eda73..4ba8f0c 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,6 +16,7 @@
*
*/
+#include linux/of.h
#include linux/platform_device.h
static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
@@ -162,6 +163,12 @@ static int vt8500_ehci_drv_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = via,vt8500-ehci, },
+ { .compatible = wm,prizm-ehci, },
+ {}
+};
+
static struct platform_driver vt8500_ehci_driver = {
.probe = vt8500_ehci_drv_probe,
.remove = vt8500_ehci_drv_remove,
@@ -169,7 +176,9 @@ static struct platform_driver vt8500_ehci_driver = {
.driver = {
.name = vt8500-ehci,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
MODULE_ALIAS(platform:vt8500-ehci);
+MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv3 2/2] ARM: vt8500: Add support for UHCI companion controller
Add support for a generic non-pci UHCI companion controller.
Existing board files for arch-vt8500 updated to include UHCI
support.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
V3:
Added the missing commits for the board files.
arch/arm/mach-vt8500/bv07.c |1 +
arch/arm/mach-vt8500/devices-vt8500.c |5 +
arch/arm/mach-vt8500/devices-wm8505.c |4 +
arch/arm/mach-vt8500/devices.c| 11 +++
arch/arm/mach-vt8500/devices.h|1 +
arch/arm/mach-vt8500/wm8505_7in.c |1 +
drivers/usb/host/Kconfig | 12 ++-
drivers/usb/host/uhci-hcd.c |5 +
drivers/usb/host/uhci-platform.c | 157 +
9 files changed, 195 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/host/uhci-platform.c
diff --git a/arch/arm/mach-vt8500/bv07.c b/arch/arm/mach-vt8500/bv07.c
index a464c75..19d20d9 100644
--- a/arch/arm/mach-vt8500/bv07.c
+++ b/arch/arm/mach-vt8500/bv07.c
@@ -32,6 +32,7 @@ static struct platform_device *devices[] __initdata = {
vt8500_device_uart0,
vt8500_device_lcdc,
vt8500_device_ehci,
+ vt8500_device_uhci,
vt8500_device_ge_rops,
vt8500_device_pwm,
vt8500_device_pwmbl,
diff --git a/arch/arm/mach-vt8500/devices-vt8500.c
b/arch/arm/mach-vt8500/devices-vt8500.c
index 19519ae..def7fe3 100644
--- a/arch/arm/mach-vt8500/devices-vt8500.c
+++ b/arch/arm/mach-vt8500/devices-vt8500.c
@@ -48,6 +48,11 @@ void __init vt8500_set_resources(void)
tmp[1] = wmt_irq_res(IRQ_EHCI);
wmt_res_add(vt8500_device_ehci, tmp, 2);
+ /* vt8500 uses a single IRQ for both EHCI and UHCI controllers */
+ tmp[0] = wmt_mmio_res(VT8500_UHCI_BASE, SZ_512);
+ tmp[1] = wmt_irq_res(IRQ_EHCI);
+ wmt_res_add(vt8500_device_uhci, tmp, 2);
+
tmp[0] = wmt_mmio_res(VT8500_GEGEA_BASE, SZ_256);
wmt_res_add(vt8500_device_ge_rops, tmp, 1);
diff --git a/arch/arm/mach-vt8500/devices-wm8505.c
b/arch/arm/mach-vt8500/devices-wm8505.c
index db4594e..c810454 100644
--- a/arch/arm/mach-vt8500/devices-wm8505.c
+++ b/arch/arm/mach-vt8500/devices-wm8505.c
@@ -55,6 +55,10 @@ void __init wm8505_set_resources(void)
tmp[1] = wmt_irq_res(IRQ_EHCI);
wmt_res_add(vt8500_device_ehci, tmp, 2);
+ tmp[0] = wmt_mmio_res(WM8505_UHCI_BASE, SZ_512);
+ tmp[1] = wmt_irq_res(IRQ_UHCI);
+ wmt_res_add(vt8500_device_uhci, tmp, 2);
+
tmp[0] = wmt_mmio_res(WM8505_GEGEA_BASE, SZ_256);
wmt_res_add(vt8500_device_ge_rops, tmp, 1);
diff --git a/arch/arm/mach-vt8500/devices.c b/arch/arm/mach-vt8500/devices.c
index 1fcdc36..46ff82d 100644
--- a/arch/arm/mach-vt8500/devices.c
+++ b/arch/arm/mach-vt8500/devices.c
@@ -204,6 +204,17 @@ struct platform_device vt8500_device_ehci = {
},
};
+static u64 uhci_dma_mask = DMA_BIT_MASK(32);
+
+struct platform_device vt8500_device_uhci = {
+ .name = platform-uhci,
+ .id = 0,
+ .dev= {
+ .dma_mask = uhci_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
struct platform_device vt8500_device_ge_rops = {
.name = wmt_ge_rops,
.id = -1,
diff --git a/arch/arm/mach-vt8500/devices.h b/arch/arm/mach-vt8500/devices.h
index 188d4e1..0e6d9f9 100644
--- a/arch/arm/mach-vt8500/devices.h
+++ b/arch/arm/mach-vt8500/devices.h
@@ -81,6 +81,7 @@ extern struct platform_device vt8500_device_uart5;
extern struct platform_device vt8500_device_lcdc;
extern struct platform_device vt8500_device_wm8505_fb;
extern struct platform_device vt8500_device_ehci;
+extern struct platform_device vt8500_device_uhci;
extern struct platform_device vt8500_device_ge_rops;
extern struct platform_device vt8500_device_pwm;
extern struct platform_device vt8500_device_pwmbl;
diff --git a/arch/arm/mach-vt8500/wm8505_7in.c
b/arch/arm/mach-vt8500/wm8505_7in.c
index cf910a9..302ae2f 100644
--- a/arch/arm/mach-vt8500/wm8505_7in.c
+++ b/arch/arm/mach-vt8500/wm8505_7in.c
@@ -31,6 +31,7 @@ static void __iomem *pmc_hiber;
static struct platform_device *devices[] __initdata = {
vt8500_device_uart0,
vt8500_device_ehci,
+ vt8500_device_uhci,
vt8500_device_wm8505_fb,
vt8500_device_ge_rops,
vt8500_device_pwm,
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 83e58df..3d153d0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -450,7 +450,7 @@ config USB_OHCI_LITTLE_ENDIAN
config USB_UHCI_HCD
tristate UHCI HCD (most Intel and VIA) support
- depends on USB (PCI || SPARC_LEON)
+ depends on USB (PCI || SPARC_LEON || ARCH_VT8500)
---help---
The Universal Host Controller Interface is a standard by Intel for
accessing the USB hardware in the PC (which is also called the USB
@@ -468,7 +468,15 @@ config USB_UHCI_HCD
config USB_UHCI_SUPPORT_NON_PCI_HC
