Re: [PATCH] arm: dts: omap5-uevm: Add status parameter for i2c/spi/uart.
On Tuesday 24 September 2013 11:18 AM, Sourav Poddar wrote:
On Tuesday 24 September 2013 11:14 AM, Sekhar Nori wrote:
On Tuesday 24 September 2013 11:09 AM, Sourav Poddar wrote:
omap5 has all devices enable by default.
Disable thosw not required in omap5 uevm board.
s/thosw/those
Fix the following:
Added status parameter
Simulataneously, fix some tab formatting.
s/Simulataneously/Simultaneously
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 38
+++---
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..78cf0f2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -450,6 +450,18 @@
};
};
+i2c2 {
+status = disabled;
+};
+
+i2c3 {
+status = disabled;
+};
+
+i2c4 {
+status = disabled;
+};
The right thing to do would be to mark these as disabled in omap5.dtsi
so boards can enable only what they need instead of disable what they
don't need (which is potentially a very long list)
Yes, initially I thought so. But saw these varies from soc to soc.
On DRA, it is done the way you suggested. For omap5, I saw mmc
getting disabled in board dts.
I can change these though. Then, other modules like keypad/mmc should
also be disable in
dtsi file to have some uniformity. ?
Yes, that would be nice. This is usually the norm. One exception that is
made is that internal modules like RTC, cryptos can be left enabled in
the soc.dtsi so each board doesn't have to enable it. Just make sure
that the module is such that it can really function on *all* boards.
Typically that would mean IOs are not present or optional without loss
of complete functionality.
Thanks,
Sekhar
--
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
Re: [PATCH 1/4] usb: musb: am35x: use SIMPLE_DEV_PM_OPS
On 23.09.2013 23:20, Felipe Balbi wrote:
On Sun, Sep 22, 2013 at 01:46:58PM +0200, Daniel Mack wrote:
-static struct dev_pm_ops am35x_pm_ops = {
-.suspend= am35x_suspend,
-.resume = am35x_resume,
-};
+static SIMPLE_DEV_PM_OPS(am35x_pm_ops, am35x_suspend, am35x_resume);
you could as well remove the DEV_PM_OPS trickery. Ditto for all other
patches
Yes, I noticed that too. That's why I sent out a v2 of the series :)
Thanks,
Daniel
--
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
[PATCHv2] arm: dts: omap5: Add status parameter.
This patch disables devices initially(status = disabled).
Devices will only be probed, if the devices are
present in the board file(status = okay).
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2:
change approach to disabling devices in dtsi and
enable it in respective board file.
arch/arm/boot/dts/omap5-uevm.dts | 43 -
arch/arm/boot/dts/omap5.dtsi | 24 +
2 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..08d6bc1 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -235,30 +235,26 @@
};
mmc1 {
+ status = okay;
vmmc-supply = ldo9_reg;
bus-width = 4;
};
mmc2 {
+ status = okay;
vmmc-supply = vmmcsd_fixed;
bus-width = 8;
ti,non-removable;
};
mmc3 {
+ status = okay;
bus-width = 4;
ti,non-removable;
};
-mmc4 {
- status = disabled;
-};
-
-mmc5 {
- status = disabled;
-};
-
i2c1 {
+ status = okay;
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
@@ -451,14 +447,19 @@
};
i2c5 {
+ status = okay;
pinctrl-names = default;
pinctrl-0 = i2c5_pins;
clock-frequency = 40;
};
-mcbsp3 {
- status = disabled;
+mcbsp1 {
+ status = okay;
+};
+
+mcbsp2 {
+ status = okay;
};
usbhshost {
@@ -470,36 +471,38 @@
phys = 0 hsusb2_phy hsusb3_phy;
};
-mcspi1 {
-
-};
-
mcspi2 {
+ status = okay;
pinctrl-names = default;
pinctrl-0 = mcspi2_pins;
};
mcspi3 {
+ status = okay;
pinctrl-names = default;
pinctrl-0 = mcspi3_pins;
};
mcspi4 {
+ status = okay;
pinctrl-names = default;
pinctrl-0 = mcspi4_pins;
};
uart1 {
-pinctrl-names = default;
-pinctrl-0 = uart1_pins;
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = uart1_pins;
};
uart3 {
-pinctrl-names = default;
-pinctrl-0 = uart3_pins;
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = uart3_pins;
};
uart5 {
-pinctrl-names = default;
-pinctrl-0 = uart5_pins;
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = uart5_pins;
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 8500beb..96aa7ba 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -259,6 +259,7 @@
ti,hwmods = i2c1;
clocks = func_96m_fclk;
clock-names = fck;
+ status = disabled;
};
i2c2: i2c@48072000 {
@@ -270,6 +271,7 @@
ti,hwmods = i2c2;
clocks = func_96m_fclk;
clock-names = fck;
+ status = disabled;
};
i2c3: i2c@4806 {
@@ -281,6 +283,7 @@
ti,hwmods = i2c3;
clocks = func_96m_fclk;
clock-names = fck;
+ status = disabled;
};
i2c4: i2c@4807a000 {
@@ -292,6 +295,7 @@
ti,hwmods = i2c4;
clocks = func_96m_fclk;
clock-names = fck;
+ status = disabled;
};
i2c5: i2c@4807c000 {
@@ -303,6 +307,7 @@
ti,hwmods = i2c5;
clocks = func_96m_fclk;
clock-names = fck;
+ status = disabled;
};
mcspi1: spi@48098000 {
@@ -325,6 +330,7 @@
sdma 42;
dma-names = tx0, rx0, tx1, rx1,
tx2, rx2, tx3, rx3;
+ status = disabled;
};
mcspi2: spi@4809a000 {
@@ -342,6 +348,7 @@
sdma 45,
sdma 46;
dma-names = tx0, rx0, tx1, rx1;
+ status = disabled;
};
mcspi3: spi@480b8000 {
@@ -356,6 +363,7 @@
ti,spi-num-cs = 2;
dmas = sdma 15, sdma 16;
dma-names = tx0, rx0;
+ status = disabled;
};
mcspi4: spi@480ba000 {
@@ -370,6 +378,7 @@
ti,spi-num-cs = 1;
dmas = sdma 70, sdma 71;
dma-names = tx0, rx0;
+ status = disabled;
};
uart1: serial@4806a000 {
@@ -380,6 +389,7 @@
clocks = func_48m_fclk;
clock-names =
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
Hi, On Monday 23 September 2013 10:37 PM, Tony Lindgren wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130923 10:09]: On 09/23/2013 06:45 PM, Tony Lindgren wrote: Hmm does this still work for legacy platform data based drivers that are doing gpio_request() first? Yes it still work when booting using board files. I tested on my OMAP3 board and it worked in both DT and legacy booting mode. OK great. And what's the path for clearing things for PM when free_irq() gets called? It seems that this would leave the GPIO bank enabled causing a PM regression? Indeed, I did set bank-mod_usage |= 1 offset so the bank is enabled if the device goes to suspended and then resumed but I completely forget about the clearing path when the IRQ is freed. Which makes me think that we should probably maintain two usage variables, one for GPIO and another one for IRQ and check both of them on the suspend/resume pm functions. Yes that it seems that they should be treated separately. To understand, why cant the flag be cleared in gpio_irq_shutdown ? Regards, Sricharan -- 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
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/24/2013 09:39 AM, Sricharan R wrote: Hi, On Monday 23 September 2013 10:37 PM, Tony Lindgren wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130923 10:09]: On 09/23/2013 06:45 PM, Tony Lindgren wrote: Hmm does this still work for legacy platform data based drivers that are doing gpio_request() first? Yes it still work when booting using board files. I tested on my OMAP3 board and it worked in both DT and legacy booting mode. OK great. And what's the path for clearing things for PM when free_irq() gets called? It seems that this would leave the GPIO bank enabled causing a PM regression? Indeed, I did set bank-mod_usage |= 1 offset so the bank is enabled if the device goes to suspended and then resumed but I completely forget about the clearing path when the IRQ is freed. Which makes me think that we should probably maintain two usage variables, one for GPIO and another one for IRQ and check both of them on the suspend/resume pm functions. Yes that it seems that they should be treated separately. To understand, why cant the flag be cleared in gpio_irq_shutdown ? Hi Sricharan, Without this patch today drivers do this: gpio_request(gpio, foo IRQ); // bank-mod_usage |= 1 offset gpio_direction_input(gpio); and then request a IRQ with: irq = gpio_to_irq(gpio); request_irq(irq, ...); later on its cleanup path: free_irq(irq, dev); gpio_free(gpio) // bank-mod_usage = ~(1 offset); So if you clear the flag on gpio_irq_shutdown then bank module won't be enabled after a suspend making drivers using the GPIO after freeing the IRQ to fail. So the idea is to have something like this: a) Drivers that request both the GPIO and IRQ gpio_request(gpio, foo IRQ); // bank-mod_usage |= 1 offset gpio_direction_input(gpio); irq = gpio_to_irq(gpio); request_irq(irq, ...); // bank-irq_usage |= 1 offset free_irq(irq, dev); // bank-irq_usage = ~(1 offset); gpio_free(gpio) // bank-mod_usage = ~(1 offset); b) Drivers that just request the IRQ: irq = gpio_to_irq(gpio); request_irq(irq, ...); // bank-irq_usage |= 1 offset free_irq(irq, dev); // bank-irq_usage = ~(1 offset); So irq_usage or mod_usage is set means that the bank has to be enabled and if both are not set means that the bank module can be disabled. Regards, Sricharan Best regards, Javier -- 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
[RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
caller won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Tested on a OMAP3 DM3730 board with both legacy and DT based booting.
Changes since v1:
- Simplify patch description as suggested by Stephen Warren.
- Track IRQ and GPIO module usage separately.
- Add clearing path for PM when free_irq() is called to not
leave the bank unnecessary enabled as suggested by Tony Lindgren.
- Check if the line is used as IRQ to not allow a second caller
to set the GPIO direction as output as suggested by Linus Walleij.
drivers/gpio/gpio-omap.c | 158 ++-
1 file changed, 101 insertions(+), 57 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0ff4355..89675f8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -63,6 +63,7 @@ struct gpio_bank {
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
+ u32 irq_usage;
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -86,6 +87,9 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
+#define LINE_USED(line, offset) (line (1 offset))
+
static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
return bank-chip.base + gpio_irq;
@@ -420,15 +424,69 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ if (bank-regs-pinctrl) {
+ void __iomem *reg = bank-base + bank-regs-pinctrl;
+
+ /* Claim the pin for MPU */
+ __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is enabled, clocks are not gated */
+ ctrl = ~GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
+static void _disable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ void __iomem *base = bank-base;
+
+ if (bank-regs-wkup_en
+ !LINE_USED(bank-mod_usage, offset)
+ !LINE_USED(bank-irq_usage, offset)) {
+ /* Disable wake-up during idle for dynamic tick */
+ _gpio_rmw(base, bank-regs-wkup_en, 1 offset, 0);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is disabled, clocks are gated */
+ ctrl |= GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+ void __iomem *reg = bank-base + bank-regs-direction;
+
+ return __raw_readl(reg) mask;
+}
+
static int gpio_irq_type(struct irq_data *d, unsigned type)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
unsigned gpio = 0;
int retval;
unsigned long flags;
+ unsigned offset;
- if (WARN_ON(!bank-mod_usage))
- return -EINVAL;
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
if (d-irq IH_MPUIO_BASE)
@@ -446,7 +504,17 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
return -EINVAL;
spin_lock_irqsave(bank-lock, flags);
- retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
+ offset = GPIO_INDEX(bank, gpio);
+ retval = _set_gpio_triggering(bank, offset, type);
+ if (!LINE_USED(bank-mod_usage, offset)) {
+ _enable_gpio_module(bank, offset);
+ _set_gpio_direction(bank, offset, 1);
+ } else if (!gpio_is_input(bank, 1 offset)) {
+ spin_unlock_irqrestore(bank-lock,
Re: [PATCH 00/10] pwm-backlight: Add GPIO and power supply support
[ Cc: Olof Johansson, Kevin Hilman and Arnd Bergman: arm-soc maintainers ] On Mon, Sep 23, 2013 at 11:40:57PM +0200, Thierry Reding wrote: This series adds the ability to specify a GPIO and a power supply to enable a backlight. Patch 1 refactors the power on and power off sequences into separate functions in preparation for subsequent patches. Patch 2 adds an optional GPIO to enable a backlight. This patch only includes the field within the platform data so that it can be properly setup before actually being put to use. Patches 3 to 7 convert all users of the pwm-backlight driver to use the new field. For most of them, this just initializes the field to -1, marking the field as unused. Patch 8 uses the new field within the pwm-backlight driver and at the same time allows it to be parsed from device tree. Patch 9 implements support for an optional power supply. This relies on the regulator core to return a dummy regulator when no supply has been otherwise setup so the driver doesn't have to handle that specially nor require all users to be updated. Patch 10 adds a way to keep a backlight turned off at boot. This is useful when hooking up a backlight with a subsystem such as DRM which has more explicit semantics as to when a backlight should be turned on. Due to the dependencies within the series, I propose to take all these patches through the PWM tree, so I'll need acks from OMAP, PXA, Samsung, shmobile and Unicore32 maintainers. I received some feedback regarding shmobile conflicts when arm-soc was merged between v3.11 and v3.12-rc1. With this in mind I now have a strong preference for changes inside arch/arm/mach-shmobile/ to be taken through my renesas tree and thus more importantly through arm-soc if possible. Thierry Thierry Reding (10): pwm-backlight: Refactor backlight power on/off pwm-backlight: Add optional enable GPIO ARM: OMAP: Initialize PWM backlight enable_gpio field ARM: pxa: Initialize PWM backlight enable_gpio field ARM: SAMSUNG: Initialize PWM backlight enable_gpio field ARM: shmobile: Initialize PWM backlight enable_gpio field unicore32: Initialize PWM backlight enable_gpio field pwm-backlight: Use new enable_gpio field pwm-backlight: Use an optional power supply pwm-backlight: Allow backlight to remain disabled on boot .../bindings/video/backlight/pwm-backlight.txt | 6 + arch/arm/mach-omap2/board-zoom-peripherals.c | 1 + arch/arm/mach-pxa/cm-x300.c| 1 + arch/arm/mach-pxa/colibri-pxa270-income.c | 1 + arch/arm/mach-pxa/ezx.c| 1 + arch/arm/mach-pxa/hx4700.c | 1 + arch/arm/mach-pxa/lpd270.c | 1 + arch/arm/mach-pxa/magician.c | 1 + arch/arm/mach-pxa/mainstone.c | 1 + arch/arm/mach-pxa/mioa701.c| 1 + arch/arm/mach-pxa/palm27x.c| 1 + arch/arm/mach-pxa/palmtc.c | 35 + arch/arm/mach-pxa/palmte2.c| 1 + arch/arm/mach-pxa/pcm990-baseboard.c | 1 + arch/arm/mach-pxa/raumfeld.c | 1 + arch/arm/mach-pxa/tavorevb.c | 2 + arch/arm/mach-pxa/viper.c | 1 + arch/arm/mach-pxa/z2.c | 2 + arch/arm/mach-pxa/zylonite.c | 1 + arch/arm/mach-s3c24xx/mach-h1940.c | 1 + arch/arm/mach-s3c24xx/mach-rx1950.c| 1 + arch/arm/mach-s3c64xx/mach-crag6410.c | 1 + arch/arm/mach-s3c64xx/mach-hmt.c | 1 + arch/arm/mach-s3c64xx/mach-smartq.c| 1 + arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 + arch/arm/mach-s5p64x0/mach-smdk6440.c | 1 + arch/arm/mach-s5p64x0/mach-smdk6450.c | 1 + arch/arm/mach-s5pc100/mach-smdkc100.c | 1 + arch/arm/mach-s5pv210/mach-smdkv210.c | 1 + arch/arm/mach-shmobile/board-armadillo800eva.c | 1 + arch/arm/plat-samsung/dev-backlight.c | 5 + arch/unicore32/kernel/puv3-nb0916.c| 1 + drivers/video/backlight/pwm_bl.c | 142 - include/linux/pwm_backlight.h | 7 + 34 files changed, 162 insertions(+), 64 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
On Tuesday 24 September 2013 01:24 PM, Javier Martinez Canillas wrote: On 09/24/2013 09:39 AM, Sricharan R wrote: Hi, On Monday 23 September 2013 10:37 PM, Tony Lindgren wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130923 10:09]: On 09/23/2013 06:45 PM, Tony Lindgren wrote: Hmm does this still work for legacy platform data based drivers that are doing gpio_request() first? Yes it still work when booting using board files. I tested on my OMAP3 board and it worked in both DT and legacy booting mode. OK great. And what's the path for clearing things for PM when free_irq() gets called? It seems that this would leave the GPIO bank enabled causing a PM regression? Indeed, I did set bank-mod_usage |= 1 offset so the bank is enabled if the device goes to suspended and then resumed but I completely forget about the clearing path when the IRQ is freed. Which makes me think that we should probably maintain two usage variables, one for GPIO and another one for IRQ and check both of them on the suspend/resume pm functions. Yes that it seems that they should be treated separately. To understand, why cant the flag be cleared in gpio_irq_shutdown ? Hi Sricharan, Without this patch today drivers do this: gpio_request(gpio, foo IRQ); // bank-mod_usage |= 1 offset gpio_direction_input(gpio); and then request a IRQ with: irq = gpio_to_irq(gpio); request_irq(irq, ...); later on its cleanup path: free_irq(irq, dev); gpio_free(gpio) // bank-mod_usage = ~(1 offset); So if you clear the flag on gpio_irq_shutdown then bank module won't be enabled after a suspend making drivers using the GPIO after freeing the IRQ to fail. So the idea is to have something like this: a) Drivers that request both the GPIO and IRQ gpio_request(gpio, foo IRQ); // bank-mod_usage |= 1 offset gpio_direction_input(gpio); irq = gpio_to_irq(gpio); request_irq(irq, ...); // bank-irq_usage |= 1 offset free_irq(irq, dev); // bank-irq_usage = ~(1 offset); gpio_free(gpio) // bank-mod_usage = ~(1 offset); b) Drivers that just request the IRQ: irq = gpio_to_irq(gpio); request_irq(irq, ...); // bank-irq_usage |= 1 offset free_irq(irq, dev); // bank-irq_usage = ~(1 offset); So irq_usage or mod_usage is set means that the bank has to be enabled and if both are not set means that the bank module can be disabled. Ok get it. Thanks. Regards, Sricharan -- 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
I want to invest this fund.
Hi, Can you assist me to invest funds in your Country? if yes, then get back to me, so I can give you details and areas you can participate by being my partner. Ms. Sarah -- 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
[PATCH v3 01/10] usb: phy: generic: Add gpio_reset to platform data
The GPIO number of the RESET line can be passed to the
driver using the gpio_reset member.
Signed-off-by: Roger Quadros rog...@ti.com
---
include/linux/usb/usb_phy_gen_xceiv.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/usb_phy_gen_xceiv.h
b/include/linux/usb/usb_phy_gen_xceiv.h
index f9a7e7b..42f3b71 100644
--- a/include/linux/usb/usb_phy_gen_xceiv.h
+++ b/include/linux/usb/usb_phy_gen_xceiv.h
@@ -9,7 +9,8 @@ struct usb_phy_gen_xceiv_platform_data {
/* if set fails with -EPROBE_DEFER if can't get regulator */
unsigned int needs_vcc:1;
- unsigned int needs_reset:1;
+ unsigned int needs_reset:1; /* deprecated */
+ int gpio_reset;
};
#if IS_ENABLED(CONFIG_NOP_USB_XCEIV)
--
1.7.4.1
--
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
[PATCH v3 09/10] ARM: dts: omap3-beagle-xm: Add USB Host support
Provide RESET GPIO and Power regulator for the USB PHY,
the USB Host port mode and the PHY device for the controller.
Also provide pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 65 -
1 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..b081f5a 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -69,6 +69,23 @@
};
};
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-gpios = gpio5 19 GPIO_ACTIVE_LOW; /* gpio_147 */
+ vcc-supply = hsusb2_power;
+ };
};
omap3_pmx_wkup {
@@ -79,6 +96,37 @@
};
};
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
+ ;
+ };
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
+ ;
+ };
+};
+
i2c1 {
clock-frequency = 260;
@@ -148,15 +196,6 @@
power = 50;
};
-omap3_pmx_core {
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins =
- 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
- 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
- ;
- };
-};
-
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
@@ -166,3 +205,11 @@
pinctrl-names = default;
pinctrl-0 = gpio1_pins;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
--
1.7.4.1
--
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
[PATCH v3 06/10] ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts reset-gpios property.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..c60ebd0 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -60,22 +60,6 @@
AFMR, Line In;
};
- /*
-* Temp hack: Need to be replaced with the proper gpio-controlled
-* reset driver as soon it will be merged.
-* http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
-*/
- /* HS USB Port 1 RESET */
- hsusb1_reset: hsusb1_reset_reg {
- compatible = regulator-fixed;
- regulator-name = hsusb1_reset;
- regulator-min-microvolt = 330;
- regulator-max-microvolt = 330;
- gpio = gpio2 30 0; /* gpio_62 */
- startup-delay-us = 7;
- enable-active-high;
- };
-
/* HS USB Port 1 Power */
hsusb1_power: hsusb1_power_reg {
compatible = regulator-fixed;
@@ -97,7 +81,7 @@
/* HS USB Host PHY on PORT 1 */
hsusb1_phy: hsusb1_phy {
compatible = usb-nop-xceiv;
- reset-supply = hsusb1_reset;
+ reset-gpios = gpio2 30 GPIO_ACTIVE_LOW; /* gpio_62 */
vcc-supply = hsusb1_power;
/**
* FIXME:
--
1.7.4.1
--
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
[PATCH v3 10/10] ARM: dts: omap3-beagle: Add USB OTG PHY details
Add information about the USB OTG PHY. Without this
the OTG port on beagle will not work.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 1237822..7669c16 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -169,3 +169,10 @@
pinctrl-names = default;
pinctrl-0 = gpio1_pins;
};
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ mode = 3;
+ power = 50;
+};
--
1.7.4.1
--
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
[PATCH v3 03/10] ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
The platform data bits can be inferred from the other members of
struct usbhs_phy_data. So get rid of the platform_data member.
Build the platform data for the PHY device in usbhs_init_phys() instead.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |6 --
arch/arm/mach-omap2/usb-host.c | 11 ++-
arch/arm/mach-omap2/usb.h |1 -
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f269184..8b9cd06 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -289,18 +289,12 @@ static struct regulator_consumer_supply
beagle_vsim_supply[] = {
static struct gpio_led gpio_leds[];
-/* PHY's VCC regulator might be added later, so flag that we need it */
-static struct usb_phy_gen_xceiv_platform_data hsusb2_phy_data = {
- .needs_vcc = true,
-};
-
static struct usbhs_phy_data phy_data[] = {
{
.port = 2,
.reset_gpio = 147,
.vcc_gpio = -1, /* updated in beagle_twl_gpio_setup */
.vcc_polarity = 1, /* updated in beagle_twl_gpio_setup */
- .platform_data = hsusb2_phy_data,
},
};
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index e83a6a4..78ac1c2 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -435,6 +435,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
struct platform_device *pdev;
char *phy_id;
struct platform_device_info pdevinfo;
+ struct usb_phy_gen_xceiv_platform_data nop_pdata;
for (i = 0; i num_phys; i++) {
@@ -455,11 +456,19 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
return -ENOMEM;
}
+ /* set platform data */
+ memset(nop_pdata, 0, sizeof(nop_pdata));
+ if (gpio_is_valid(phy-vcc_gpio))
+ nop_pdata.needs_vcc = true;
+ if (gpio_is_valid(phy-reset_gpio))
+ nop_pdata.needs_reset = true;
+ nop_pdata.type = USB_PHY_TYPE_USB2;
+
/* create a NOP PHY device */
memset(pdevinfo, 0, sizeof(pdevinfo));
pdevinfo.name = nop_name;
pdevinfo.id = phy-port;
- pdevinfo.data = phy-platform_data;
+ pdevinfo.data = nop_pdata;
pdevinfo.size_data =
sizeof(struct usb_phy_gen_xceiv_platform_data);
scnprintf(phy_id, MAX_STR, usb_phy_gen_xceiv.%d,
diff --git a/arch/arm/mach-omap2/usb.h b/arch/arm/mach-omap2/usb.h
index e7261eb..4ba2ae7 100644
--- a/arch/arm/mach-omap2/usb.h
+++ b/arch/arm/mach-omap2/usb.h
@@ -58,7 +58,6 @@ struct usbhs_phy_data {
int reset_gpio;
int vcc_gpio;
bool vcc_polarity; /* 1 active high, 0 active low */
- void *platform_data;
};
extern void usb_musb_init(struct omap_musb_board_data *board_data);
--
1.7.4.1
--
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
Re: [PATCH 00/10] pwm-backlight: Add GPIO and power supply support
On Tue, Sep 24, 2013 at 05:14:46PM +0900, Simon Horman wrote: [ Cc: Olof Johansson, Kevin Hilman and Arnd Bergman: arm-soc maintainers ] On Mon, Sep 23, 2013 at 11:40:57PM +0200, Thierry Reding wrote: This series adds the ability to specify a GPIO and a power supply to enable a backlight. Patch 1 refactors the power on and power off sequences into separate functions in preparation for subsequent patches. Patch 2 adds an optional GPIO to enable a backlight. This patch only includes the field within the platform data so that it can be properly setup before actually being put to use. Patches 3 to 7 convert all users of the pwm-backlight driver to use the new field. For most of them, this just initializes the field to -1, marking the field as unused. Patch 8 uses the new field within the pwm-backlight driver and at the same time allows it to be parsed from device tree. Patch 9 implements support for an optional power supply. This relies on the regulator core to return a dummy regulator when no supply has been otherwise setup so the driver doesn't have to handle that specially nor require all users to be updated. Patch 10 adds a way to keep a backlight turned off at boot. This is useful when hooking up a backlight with a subsystem such as DRM which has more explicit semantics as to when a backlight should be turned on. Due to the dependencies within the series, I propose to take all these patches through the PWM tree, so I'll need acks from OMAP, PXA, Samsung, shmobile and Unicore32 maintainers. I received some feedback regarding shmobile conflicts when arm-soc was merged between v3.11 and v3.12-rc1. With this in mind I now have a strong preference for changes inside arch/arm/mach-shmobile/ to be taken through my renesas tree and thus more importantly through arm-soc if possible. I understand. Unfortunately the nature of patche series such as this is that they require the whole series to be applied atomically (or at least in a very specific order). So the patch that uses the new enable_gpio field can only be applied after all previous patches. The only reasonable way to ensure that is to take all of the patches through one tree. Furthermore this patch is tiny (it adds a single line) and touches code that's unlikely to be modified by anyone else. But if it makes you more comfortable, I could provide a stable branch that contains this series for you to merge into the shmobile tree. That should enable you to handle all conflict resolution prior to submitting to arm-soc. Thierry pgpWmaBVZWHdw.pgp Description: PGP signature
[PATCH v3 08/10] ARM: dts: omap3-beagle: Make USB host pin naming consistent
Use a common naming scheme mode0name.modename flags for the
USB host pins to be consistent.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 71bde47..1237822 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -90,18 +90,18 @@
hsusbb2_pins: pinmux_hsusbb2_pins {
pinctrl-single,pins =
- 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_clk */
- 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_stp */
- 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dir */
- 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_nxt */
- 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat0 */
- 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat1 */
- 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat2 */
- 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat3 */
- 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat4 */
- 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat5 */
- 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat6 */
- 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat7 */
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
;
};
--
1.7.4.1
--
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
[PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts reset-gpios property.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = regulator-fixed;
- regulator-name = hsusb2_reset;
- regulator-min-microvolt = 330;
- regulator-max-microvolt = 330;
- gpio = gpio5 19 0; /* gpio_147 */
- startup-delay-us = 7;
- enable-active-high;
- };
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = regulator-fixed;
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
- reset-supply = hsusb2_reset;
+ reset-gpios = gpio5 19 GPIO_ACTIVE_LOW; /* gpio_147 */
vcc-supply = hsusb2_power;
};
--
1.7.4.1
--
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
[PATCH v3 02/10] usb: phy: generic: Don't use regulator framework for RESET line
Modelling the RESET line as a regulator supply wasn't a good idea
as it kind of abuses the regulator framework and also makes adaptation
code more complex.
Instead, manage the RESET gpio line directly in the driver. Update
the device tree binding information.
This also makes us easy to migrate to a dedicated GPIO RESET controller
whenever it becomes available.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt |7 +-
drivers/usb/phy/phy-am335x.c |2 +-
drivers/usb/phy/phy-generic.c | 84 +---
drivers/usb/phy/phy-generic.h |6 +-
4 files changed, 63 insertions(+), 36 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index d7e2726..1bd37fa 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -15,7 +15,7 @@ Optional properties:
- vcc-supply: phandle to the regulator that provides RESET to the PHY.
-- reset-supply: phandle to the regulator that provides power to the PHY.
+- reset-gpios: Should specify the GPIO for reset.
Example:
@@ -25,10 +25,9 @@ Example:
clocks = osc 0;
clock-names = main_clk;
vcc-supply = hsusb1_vcc_regulator;
- reset-supply = hsusb1_reset_regulator;
+ reset-gpios = gpio1 7 GPIO_ACTIVE_LOW;
};
hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
-hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
-controls RESET.
+hsusb1_vcc_regulator provides power to the PHY and GPIO 7 controls RESET.
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index c4d614d..fb4bf28 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -53,7 +53,7 @@ static int am335x_phy_probe(struct platform_device *pdev)
}
ret = usb_phy_gen_create_phy(dev, am_phy-usb_phy_gen,
- USB_PHY_TYPE_USB2, 0, false, false);
+ USB_PHY_TYPE_USB2, 0, false);
if (ret)
return ret;
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index efe59f3..36d7071 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -35,6 +35,9 @@
#include linux/clk.h
#include linux/regulator/consumer.h
#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+#include linux/delay.h
#include phy-generic.h
@@ -64,6 +67,23 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)
return 0;
}
+static void nop_reset_set(struct usb_phy_gen_xceiv *nop, int asserted)
+{
+ int value;
+
+ if (!gpio_is_valid(nop-gpio_reset))
+ return;
+
+ value = asserted;
+ if (nop-reset_active_low)
+ value = !value;
+
+ gpio_set_value_cansleep(nop-gpio_reset, value);
+
+ if (!asserted)
+ usleep_range(1, 2);
+}
+
int usb_gen_phy_init(struct usb_phy *phy)
{
struct usb_phy_gen_xceiv *nop = dev_get_drvdata(phy-dev);
@@ -76,11 +96,8 @@ int usb_gen_phy_init(struct usb_phy *phy)
if (!IS_ERR(nop-clk))
clk_enable(nop-clk);
- if (!IS_ERR(nop-reset)) {
- /* De-assert RESET */
- if (regulator_enable(nop-reset))
- dev_err(phy-dev, Failed to de-assert reset\n);
- }
+ /* De-assert RESET */
+ nop_reset_set(nop, 0);
return 0;
}
@@ -90,11 +107,8 @@ void usb_gen_phy_shutdown(struct usb_phy *phy)
{
struct usb_phy_gen_xceiv *nop = dev_get_drvdata(phy-dev);
- if (!IS_ERR(nop-reset)) {
- /* Assert RESET */
- if (regulator_disable(nop-reset))
- dev_err(phy-dev, Failed to assert reset\n);
- }
+ /* Assert RESET */
+ nop_reset_set(nop, 1);
if (!IS_ERR(nop-clk))
clk_disable(nop-clk);
@@ -136,8 +150,7 @@ static int nop_set_host(struct usb_otg *otg, struct usb_bus
*host)
}
int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_gen_xceiv *nop,
- enum usb_phy_type type, u32 clk_rate, bool needs_vcc,
- bool needs_reset)
+ enum usb_phy_type type, u32 clk_rate, bool needs_vcc)
{
int err;
@@ -176,12 +189,22 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_gen_xceiv *nop,
return -EPROBE_DEFER;
}
- nop-reset = devm_regulator_get(dev, reset);
- if (IS_ERR(nop-reset)) {
- dev_dbg(dev, Error getting reset regulator: %ld\n,
- PTR_ERR(nop-reset));
- if (needs_reset)
-
[PATCH v3 04/10] ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
The USB phy-nop nop driver expects the RESET line information
to be sent as a GPIO number via platform data. Adapt to that.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 78ac1c2..10855eb 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -460,8 +460,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
memset(nop_pdata, 0, sizeof(nop_pdata));
if (gpio_is_valid(phy-vcc_gpio))
nop_pdata.needs_vcc = true;
- if (gpio_is_valid(phy-reset_gpio))
- nop_pdata.needs_reset = true;
+ nop_pdata.gpio_reset = phy-reset_gpio;
nop_pdata.type = USB_PHY_TYPE_USB2;
/* create a NOP PHY device */
@@ -483,14 +482,6 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
usb_bind_phy(ehci-omap.0, phy-port - 1, phy_id);
- /* Do we need RESET regulator ? */
- if (gpio_is_valid(phy-reset_gpio)) {
- scnprintf(rail_name, MAX_STR,
- hsusb%d_reset, phy-port);
- usbhs_add_regulator(rail_name, phy_id, reset,
- phy-reset_gpio, 1);
- }
-
/* Do we need VCC regulator ? */
if (gpio_is_valid(phy-vcc_gpio)) {
scnprintf(rail_name, MAX_STR, hsusb%d_vcc, phy-port);
--
1.7.4.1
--
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
[PATCH v3 07/10] ARM: dts: omap5-uevm: Use reset-gpios for hsusb2/3_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts reset-gpios property.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 26 ++
1 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..506bdc2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -27,21 +27,10 @@
regulator-max-microvolt = 300;
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = regulator-fixed;
- regulator-name = hsusb2_reset;
- regulator-min-microvolt = 330;
- regulator-max-microvolt = 330;
- gpio = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
- startup-delay-us = 7;
- enable-active-high;
- };
-
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
- reset-supply = hsusb2_reset;
+ reset-gpios = gpio3 16 GPIO_ACTIVE_LOW; /* gpio3_80
HUB_NRESET */
/**
* FIXME
* Put the right clock phandle here when available
@@ -51,21 +40,10 @@
clock-frequency = 1920;
};
- /* HS USB Port 3 RESET */
- hsusb3_reset: hsusb3_reset_reg {
- compatible = regulator-fixed;
- regulator-name = hsusb3_reset;
- regulator-min-microvolt = 330;
- regulator-max-microvolt = 330;
- gpio = gpio3 15 GPIO_ACTIVE_HIGH; /* gpio3_79 ETH_NRESET */
- startup-delay-us = 7;
- enable-active-high;
- };
-
/* HS USB Host PHY on PORT 3 */
hsusb3_phy: hsusb3_phy {
compatible = usb-nop-xceiv;
- reset-supply = hsusb3_reset;
+ reset-gpios = gpio3 15 GPIO_ACTIVE_LOW; /* gpio3_79
ETH_NRESET */
};
leds {
--
1.7.4.1
--
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
[PATCH v3 00/10] USB: phy: phy-nop: Manage RESET GPIO in the driver
Hi, Modelling the RESET line as a regulator supply wasn't a good idea as it abuses the regulator framework and makes adaptation code/data more complex. Instead, manage the RESET gpio line directly in the driver. This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available. Apart from RESET line changes this series also adds USB host support fro beagle-xm and fixes USB OTG port on beagle. The full series is avilable at git://github.com/rogerq/linux.git in branch phy-reset *NOTE:* As there are changes to platform data, Patch 1 needs to be shared between the arm-soc tree and usb tree. Patch 1 is available at repo git://github.com/rogerq/linux.git in branch phy-reset-common Patch 2 contains the phy-nop driver changes Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. Patches 5, 6 and 7 adapt DT data to the binding changes. Patch 8 is cleanup of omap3-beagle DT. Patch 9 adds USB host support to omap3-beagle-xm using the new binding. Patch 10 fixes USB OTG port on beagle. Patches are based on v3.12-rc1 Tested leacy boot on omap3-beagle and omap3-beagle-xm Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-es v3: - Fix the Initial state of RESET line at probe time. - Update hsusb3_reset line on omap5-uevm as well. - Add patch 10 that fixes USB OTG port on beagle. v2: - Added RESET GPIO polarity feature - Changed to gpio_set_value_cansleep() cheers, -roger Roger Quadros (10): usb: phy: generic: Add gpio_reset to platform data usb: phy: generic: Don't use regulator framework for RESET line ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset ARM: dts: omap5-uevm: Use reset-gpios for hsusb2/3_reset ARM: dts: omap3-beagle: Make USB host pin naming consistent ARM: dts: omap3-beagle-xm: Add USB Host support ARM: dts: omap3-beagle: Add USB OTG PHY details .../devicetree/bindings/usb/usb-nop-xceiv.txt |7 +- arch/arm/boot/dts/omap3-beagle-xm.dts | 65 +-- arch/arm/boot/dts/omap3-beagle.dts | 44 +-- arch/arm/boot/dts/omap4-panda-common.dtsi | 18 + arch/arm/boot/dts/omap5-uevm.dts | 26 +-- arch/arm/mach-omap2/board-omap3beagle.c|6 -- arch/arm/mach-omap2/usb-host.c | 18 ++-- arch/arm/mach-omap2/usb.h |1 - drivers/usb/phy/phy-am335x.c |2 +- drivers/usb/phy/phy-generic.c | 84 +--- drivers/usb/phy/phy-generic.h |6 +- include/linux/usb/usb_phy_gen_xceiv.h |3 +- 12 files changed, 153 insertions(+), 127 deletions(-) -- 1.7.4.1 -- 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
Re: [PATCH] ARM: DTS: omap3-devkit8000.dts: fix a typo
Hi Aaro, On 21/09/2013 01:40, Aaro Koskinen wrote: gpmc,sync-clki-ps is not defined/documented, it should be gpmc,sync-clk-ps instead. Thanks for the fix. I've just applied it with a slight change in the subject for consistency: ARM: dts: omap3-devkit8000: fix a typo in GMPC node Regards, Benoit Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/arm/boot/dts/omap3-devkit8000.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts index 7ef2827..4665421 100644 --- a/arch/arm/boot/dts/omap3-devkit8000.dts +++ b/arch/arm/boot/dts/omap3-devkit8000.dts @@ -125,7 +125,7 @@ nand-bus-width = 16; gpmc,device-nand; - gpmc,sync-clki-ps = 0; + gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; gpmc,cs-rd-off-ns = 44; gpmc,cs-wr-off-ns = 44; -- 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
Re: [PATCH 2/2] ARM: dts: dra7-evm: Add mmc2 node for eMMC support
+ Sekhar
Hi Balaji,
On 26/08/2013 15:53, Balaji T K wrote:
Add mmc2 dt node to dra7-evm board
and model eMMC vcc as fixed regulator.
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index a59bbd0..2062724 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,6 +17,13 @@
device_type = memory;
reg = 0x8000 0x6000; /* 1536 MB */
};
+
+ mmc2_3v3: fixedregulator-mmc2 {
+ compatible = regulator-fixed;
+ regulator-name = mmc2_3v3;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
dra7_pmx_core {
@@ -257,3 +264,10 @@
vmmc-supply = ldo1_reg;
bus-width = 4;
};
+
+mmc2 {
+ status = okay;
+ vmmc-supply = mmc2_3v3;
+ bus-width = 8;
+ ti,non-removable;
Sekhar just posted a series to replace that with a non-TI attribute:
non-removable.
I'm not sure if this got merged, but it might be good to use the
standard attribute instead.
Regards,
Benoit
--
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
Re: new binutils needed for arm in 3.12-rc1
Rob Landley r...@landley.net writes: On 09/23/2013 06:59:17 PM, Pavel Machek wrote: During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. Um, my toolchain is using the last gplv2 snapshot of binutils out of git, which is just past 2.17 and can build armv7 (but not armv8). Binutils 2.12-2.22 is quite the jump. (11 years.) I'd except some thought to have gone into that? Possibly a mention of it? I seriously doubt that 2.12 still works at all (I doubt it can even be built on a modern system). In my experience, binutils older than 2.19 or so rarely works properly for ARM. What value is there in maintaining compatibility with a truly ancient binutils version anyway? -- Måns Rullgård m...@mansr.com -- 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
Re: [net-next PATCH 0/4] cpsw: support for control module register
From: Mugunthan V N mugunthan...@ti.com Date: Sat, 21 Sep 2013 00:50:37 +0530 This patch series adds the support for configuring GMII_SEL register of control module to select the phy mode type and also to configure the clock source for RMII phy mode whether to use internal clock or the external clock from the phy itself. Till now CPSW works as this configuration is done in U-Boot and carried over to the kernel. But during suspend/resume Control module tends to lose its configured value for GMII_SEL register in AM33xx PG1.0, so if CPSW is used in RMII or RGMII mode, on resume cpsw is not working as GMII_SEL register lost its configuration values. The initial version of the patch is done by Daniel Mack but as per Tony's comment he wants it as a seperate driver as it is done in USB control module. I have created a seperate driver for the same. Series applied, thanks. -- 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
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130923 22:49]: On 09/23/2013 10:15 PM, Linus Walleij wrote: javier.marti...@collabora.co.uk wrote: - When a second caller calls omap_gpio_request() it should be OK as well, but only if the flags corresponds to the previously enabled input mode. Else it should be disallowed. - The same should happen for _set_gpio_direction() if a pin previously set up for IRQ gets a request to be used as output. If this cannot be tracked in the driver, it is certainly a candidate for something that gpiolib should be doing. And then I'm open to solutions to how we can do that. Ok, this can be tracked in the driver, will add it when posting v2 soon. If this needs to be applied pronto to fix the regression I'm happy with that too, if we add a big boilerplate stating the above problem and that it needs to be *fixed* at some point. In the mainline kernel, the regression is happening at least for smsc911x using boards, so that's omap3-igep.dtsi and omap3-tobi.dts currently. Also MMC card detection for omap4 is failing. Then of course there are tons of boards where we don't have the .dts files in the mainline kernel yet. So maybe let's do a minimal fix for the -rc cycle first? Then the extra checks can be queued for the next merge window if it gets too intrusive. But in either case I want this to be tested on OMAP1 before I apply it, as in a Tested-by tag. Agreed. Even though this is a fix for a long standing issue I prefer it to be tested extensively than applying the patch in a rush just to learn that causes regressions and have to be reverted as it happens last time. So as you said let's wait until we have a few Tested-by tags by people using different OMAP platforms specially OMAP1. Yup. Regards, Tony -- 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
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130924 01:06]:
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
caller won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
Also please mention the regression that this fixes. So far we know
that smsc911x for tobi and igep boards in mainline, and also the
MMC card detect for omap4 boards.
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -63,6 +63,7 @@ struct gpio_bank {
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
+ u32 irq_usage;
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -86,6 +87,9 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BITBIT(0)
+#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
+#define LINE_USED(line, offset) (line (1 offset))
Hmm this patch is hard to read, maybe break it into two patches?
First you could do a patch to prepare thing by introducing
BANK_USED and LINE_USED.
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+ void __iomem *reg = bank-base + bank-regs-direction;
+
+ return __raw_readl(reg) mask;
+}
And also move gpio_is_input() around in the first patch.
Then the second patch for the fix would probably be much
easier to read.
Regards,
Tony
--
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
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/24/2013 05:40 PM, Tony Lindgren wrote:
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130924 01:06]:
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
caller won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
Also please mention the regression that this fixes. So far we know
that smsc911x for tobi and igep boards in mainline, and also the
MMC card detect for omap4 boards.
Ok, I'll mention that on the next post.
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -63,6 +63,7 @@ struct gpio_bank {
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
+u32 irq_usage;
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -86,6 +87,9 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
+#define LINE_USED(line, offset) (line (1 offset))
Hmm this patch is hard to read, maybe break it into two patches?
First you could do a patch to prepare thing by introducing
BANK_USED and LINE_USED.
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+void __iomem *reg = bank-base + bank-regs-direction;
+
+return __raw_readl(reg) mask;
+}
And also move gpio_is_input() around in the first patch.
Then the second patch for the fix would probably be much
easier to read.
Sure will split in more patches, I just wanted to keep in one patch since it was
a RFC but it seems that the change makes sense so I'll post it as a proper
patch-set.
Regards,
Tony
Thanks a lot for your feedback and best regards,
Javier
--
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
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
On Tuesday 24 September 2013 09:10 PM, Tony Lindgren wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130924 01:06]: The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another caller won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. Also please mention the regression that this fixes. So far we know that smsc911x for tobi and igep boards in mainline, and also the MMC card detect for omap4 boards. Hi Tony, Card detect on omap4 board (sdp and panda) is not based on omap gpio, so I think this fix is not applicable for omap4. Card detect line for SD card goes to power IC on OMAP4 panda and SDP. -- 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
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
On Tuesday 24 September 2013 11:45 AM, Balaji T K wrote: On Tuesday 24 September 2013 09:10 PM, Tony Lindgren wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130924 01:06]: The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another caller won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. Also please mention the regression that this fixes. So far we know that smsc911x for tobi and igep boards in mainline, and also the MMC card detect for omap4 boards. Hi Tony, Card detect on omap4 board (sdp and panda) is not based on omap gpio, so I think this fix is not applicable for omap4. Card detect line for SD card goes to power IC on OMAP4 panda and SDP. I confused Tony mostly. It was OMAP4 SPI based ethernet which uses the GPIO as an interrupt line. So for Panda, its Ethernet driver and not MMC. Regards, Santosh -- 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
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
* Balaji T K balaj...@ti.com [130924 08:54]: On Tuesday 24 September 2013 09:10 PM, Tony Lindgren wrote: Also please mention the regression that this fixes. So far we know that smsc911x for tobi and igep boards in mainline, and also the MMC card detect for omap4 boards. Hi Tony, Card detect on omap4 board (sdp and panda) is not based on omap gpio, so I think this fix is not applicable for omap4. Card detect line for SD card goes to power IC on OMAP4 panda and SDP. Hmm OK is that the twl6030_mmc_card_detect_config() on PMIC? Santosh, care to clarify what you mentioned to me earlier regarding the MMC card detect regression? Regards, Tony -- 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
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
* Santosh Shilimkar santosh.shilim...@ti.com [130924 08:56]: On Tuesday 24 September 2013 11:45 AM, Balaji T K wrote: On Tuesday 24 September 2013 09:10 PM, Tony Lindgren wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130924 01:06]: The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another caller won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. Also please mention the regression that this fixes. So far we know that smsc911x for tobi and igep boards in mainline, and also the MMC card detect for omap4 boards. Hi Tony, Card detect on omap4 board (sdp and panda) is not based on omap gpio, so I think this fix is not applicable for omap4. Card detect line for SD card goes to power IC on OMAP4 panda and SDP. I confused Tony mostly. It was OMAP4 SPI based ethernet which uses the GPIO as an interrupt line. So for Panda, its Ethernet driver and not MMC. OK :) Thanks for clarifying. Tony -- 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
panda, 3.11 and wifi: 'wlcore: ERROR timeout waiting for the hardware to complete initialization'
Dear, after the inclusion of 851320e: ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard wlan0 is back on my pandaes, but it doesn't work and my logs are swamped with: [ 56.255401] wlcore: ERROR timeout waiting for the hardware to complete initialization [ 56.264770] wlcore: ERROR firmware boot failed despite 3 retries [ 58.689971] wlcore: ERROR timeout waiting for the hardware to complete initialization [ 61.086730] wlcore: ERROR timeout waiting for the hardware to complete initialization [ 63.523223] wlcore: ERROR timeout waiting for the hardware to complete initialization [ 63.532592] wlcore: ERROR firmware boot failed despite 3 retries ... any idea what could be wrong now? here is a complete dmesg: http://goo.gl/e1ZDVp -- bye, p. -- 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
Re: [PATCH v2 2/2] RX-51: ARM errata 430973 workaround
* Pavel Machek pa...@ucw.cz [130923 17:23]: Hi! Tony, if you did not have time for review this patch months ago or you found it only today - no problem, I understand it. But what I need to know is what will happen with board-rx51-* files (and when?) You can see that DT does not have definitions of all n900 hw parts (plus it is not in last 3.11 kernel!) which means that DT is not usable for me and other n900 people. This also means that I cannot rewrite my patches for DT and test if they working. I usually stop looking at new code around -rc4 and concentrate on fixes until -rc1 or so. So there can be easily one month delays on reviewing stuff depending on where we are with the current merge window or -rc cycle, sorry if that's annoying. The .dts files will be separate from the kernel soonish, so that's not be a show stopper. Just like all the board specific .config files are separate from the kernel already. Too bad our .dts changes did not get merged for v3.12 because of conflicts with other branches, but hey, they should be independent from the kernel anyways. Well... I'd say it is still time to merge them. New hardware support is ok after -rc1. Sure if there's a good reason like driver foo is already device tree only and cannot be used for board bar without blah. The board files will be going away as soon as things are working with DT. We've been pretty much only applying fixes to them for quite some time now. For the timeline, the earliest we'll be able to remove the board-*.c files and platform data is for v3.13 And it would be good to merge n900 dts support for 3.12. Adding device tree at the same release as removing board support files in same release leaves zero room for testing, and practically guarantees regressions. Yes we experienced that with omap4 conversion where it caused some wl12xx regression. So we might want to keep some omap3 board files around until v3.14 if necessary. Also please take a look at the [PATCH 0/4] Clean up legacy platform data handling for omaps for v3.13 patches I posted few days ago, those should make it easy to have board specific pdata quirks for DT based booting. Regards, Tony -- 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
[RFC 00/15] Device Tree schemas and validation
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device tree compilation in DTC itself
[1] http://www.spinics.net/lists/arm-kernel/msg262224.html
=== What it does? ===
For now device-tree bindings are defined in a not standardized
text-based format and thus any one can write the documentation for a
binding as he wish. In addition to this there is no automated way to
check if a dts is conform to the available bindings.
The goal of this series of patch is to fix this situation by adding a
well defined way to write bindings in a human-readable format. These
bindings will be written through files called schemas.
=== What is a schema? ===
A schema is a file describing the constraints that one or several nodes
of a dts must conform to. Schemas must use the file extension .schema.
A schema can check that:
- A node has a given property
- An array has a valid size
- A node contains the required children.
- A property has the correct type.
- A property has the correct value.
A schema can as well recursively check the constraints for parent nodes.
The syntax for a schema is the same as the one for dts. This choice has
been made to simplify its development, to maximize the code reuse and
finally because the format is human-readable.
=== How to defined a schema? ===
A binding directory has been added at the root of repository. Users can
add schema files anywhere in it but a nice way would be to keep the same
structure as the binding directory in the documentation.
To demonstrate how to write a schema and its capability I will use the
OMAP DTS schemas when applicable.
How to:
* Associate a schema to one or several nodes
As said earlier a schema can be used to validate one or several nodes
from a dts. To do this the compatible properties from the nodes which
should be validated must be present in the schema.
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
interrupts = 0x0 0x25 0x4;
ti,hwmods = timer1;
ti,timer-alwon;
};
To write a schema which will validate OMAP Timers like the one above,
one may write the following schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
...
};
The schema above will be used to validate every node in a dts which has
a compatible matching the following regular expression:
ti,omap[0-9]+-timer.
It is possible to specify multiple compatible inside a schema using this
syntax:
compatible = ti,omap[0-9]+-timer, ti,am[0-9]+-timer;
This time the schema will be application for both OMAP Timers and AM
Timers.
* Define constraints on properties
To define constraints on a property one has to create a node in a schema
which has as name the name of the property that one want to validate.
To specify constraints on the property ti,hwmods of OMAP Timers one
can write this schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
ti,hwmods {
...
};
};
If one want to use a regular as property name one can write this schema:
/dts-v1/;
/ {
compatible = abc;
def {
name = def[0-9];
...
};
};
Above one can see that the name property override the node name.
* Require the presence of a property
One can require the presence of a property by using the is-required
constraint.
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
ti,hwmods {
is-required;
};
};
The ti,hwmods property above is set as required and its presence will
be checked in every OMAP timer.
* Require the presence of a property inside a node or inside one of its
parents
Sometimes a property required is not directly present inside a node but
is present in one of its parents. To check this, one can use
can-be-inherited in addition to is-required.
twl {
interrupt-controller;
rtc {
compatible = ti,twl4030-rtc;
interrupts = 0xc;
};
}
In the case of the rtc above the interrupt-controller is not present,
but it is present in its parent. If inheriting the property from the
parent makes senses like here one can specify in the schema that
interrupt-controller is required in the rtc node and that the property
can be inherited from a parent.
/dts-v1/;
/ {
compatible = ti,twl[0-9]+-rtc;
interrupt-controller {
is-required;
can-be-inherited;
};
};
* Require a node to contains a given list of children
One may want to check if a node has some
[RFC 03/15] scripts/dtc: validate each nodes and properties
From: Fabien Parent fpar...@baylibre.com
Add support to navigate through the device tree and try to validate each node
which has an associated schema in the schema index. So far, only the framework
is added and no validation is really done yet.
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/schema.c | 234 ++-
1 file changed, 233 insertions(+), 1 deletion(-)
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index dd134d6..a797821 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -9,9 +9,21 @@ static const char *const SCHEMA_EXT = .schema;
static const char *const VALUE_PROPNAME = value;
static int exit_on_failure = 0;
+struct node_list {
+ struct node *n;
+ struct node_list *next;
+};
+
+struct prop_constraints {
+ const char *name;
+};
+
struct node_constraints {
pcre *re_compat;
char *filepath;
+ struct boot_info *bi;
+ struct node *dt;
+
const char *compatible;
};
@@ -54,6 +66,34 @@ static int get_next_string_offset(struct property *p, int
offset)
return -1;
}
+static struct property *get_property_matching_pattern(struct property **list,
+ const char *pattern)
+{
+ struct property *p;
+ pcre *re;
+ int is_matching;
+
+ assert(list);
+ assert(pattern);
+
+ re = compile_pattern(pattern);
+ if (!re)
+ die(Invalid pattern: %s\n, pattern);
+
+ for (p = *list; p; p = p-next) {
+ assert(p-name);
+ is_matching = pcre_exec(re, 0, p-name, strlen(p-name),
+ 0, 0, NULL, 0) = 0;
+ if (is_matching) {
+ *list = p-next;
+ break;
+ }
+ }
+
+ pcre_free(re);
+ return p;
+}
+
static int is_prop_value(const char *p)
{
int is_value = 1;
@@ -70,12 +110,203 @@ static int is_prop_value(const char *p)
/** Schema Validation */
+static void free_property_constraints(struct prop_constraints *pc)
+{
+ if (!pc)
+ return;
+
+ free(pc);
+}
+
+static struct prop_constraints*
+load_property_constraints(struct node *schema)
+{
+ struct property *p;
+ struct prop_constraints *pc;
+
+ assert(schema);
+
+ pc = xmalloc(sizeof(*pc));
+ memset(pc, 0, sizeof(*pc));
+
+ p = get_property(schema, name);
+ if (p)
+ pc-name = p-val.val;
+
+ return pc;
+}
+
+static int validate_properties(struct node *n,
+ struct node *schema,
+ struct node_list *path);
+
+static int validate_property(struct node *n,
+struct property *p,
+struct prop_constraints *pc,
+struct node *schema,
+struct node_list *path)
+{
+ int ret = 1;
+
+ assert(n);
+ assert(schema);
+ assert(pc);
+ assert(path);
+
+ free_property_constraints(pc);
+ return ret;
+}
+
+static int validate_properties(struct node *n,
+ struct node *schema,
+ struct node_list *path)
+{
+ struct property *p;
+ struct property *iter;
+ struct prop_constraints *pc;
+ int ret = 1;
+
+ assert(n);
+ assert(schema);
+ assert(path);
+
+ pc = load_property_constraints(schema);
+ assert(pc);
+
+ iter = n-proplist;
+ p = get_property_matching_pattern(iter, pc-name ?: schema-name);
+ ret = validate_property(n, p, pc, schema, path);
+
+ /* if other properties match the pattern */
+ while (iter p) {
+ p = get_property_matching_pattern(iter, schema-name);
+ if (p)
+ ret = validate_property(n, p, pc, schema, path);
+ else
+ break;
+ }
+
+ return ret;
+}
+
+static int validate_node(struct node *n,
+struct node_constraints *nc,
+struct node_list *path)
+{
+ struct node *iter;
+ int ret = 1;
+
+ assert(n);
+ assert(path);
+ assert(nc);
+ assert(nc-dt);
+
+ for (iter = nc-dt-children; iter; iter = iter-next_sibling)
+ ret = validate_properties(n, iter, path);
+
+ return ret;
+}
+
+static struct node_constraints *get_node_constraints_of(struct schema_db *db,
+ const char *compat,
+ int *i)
+{
+ int has_match;
+ struct node_constraints *n;
+
+ assert(db);
+ assert(compat);
+ assert(i);
+
+ for (; *i db-size; (*i)++) {
+ n = db-buffer[*i];
+
+
[RFC 01/15] scripts/dtc: fix most memory leaks in dtc
From: Fabien Parent fpar...@baylibre.com
There are a few memory leaks in dtc which until now were not that important
since they were all in the parser and only one instance of the parser was run
per instance of dtc. The following commits will add a validation of dts through
schema which have the same syntax as dts, i.e. the parser of dts will be reused
to parse schema. The consequence is that instead of having the parser running
only one time for an instance of the dtc process, the parser will run
many many times and thus the leak that were not important until now becomes
urgent to fix.
dtc-lexer: Do not duplicate the string which contains literals because the
string is directly converted afterward to an integer and is never used again.
livetree: Add a bunch of free helper functions to clean properly the dt.
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/dtc-lexer.l | 2 +-
scripts/dtc/dtc-lexer.lex.c_shipped | 2 +-
scripts/dtc/dtc.c | 1 +
scripts/dtc/dtc.h | 1 +
scripts/dtc/livetree.c | 108 +---
5 files changed, 105 insertions(+), 9 deletions(-)
diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
index 3b41bfc..4f63fbf 100644
--- a/scripts/dtc/dtc-lexer.l
+++ b/scripts/dtc/dtc-lexer.l
@@ -146,7 +146,7 @@ static int pop_input_file(void);
}
V1([0-9]+|0[xX][0-9a-fA-F]+)(U|L|UL|LL|ULL)? {
- yylval.literal = xstrdup(yytext);
+ yylval.literal = yytext;
DPRINT(Literal: '%s'\n, yylval.literal);
return DT_LITERAL;
}
diff --git a/scripts/dtc/dtc-lexer.lex.c_shipped
b/scripts/dtc/dtc-lexer.lex.c_shipped
index 2d30f41..5c0d27c 100644
--- a/scripts/dtc/dtc-lexer.lex.c_shipped
+++ b/scripts/dtc/dtc-lexer.lex.c_shipped
@@ -1054,7 +1054,7 @@ case 10:
YY_RULE_SETUP
#line 148 dtc-lexer.l
{
- yylval.literal = xstrdup(yytext);
+ yylval.literal = yytext;
DPRINT(Literal: '%s'\n, yylval.literal);
return DT_LITERAL;
}
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index a375683..215ae92 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -256,5 +256,6 @@ int main(int argc, char *argv[])
die(Unknown output format \%s\\n, outform);
}
+ free_dt(bi);
exit(0);
}
diff --git a/scripts/dtc/dtc.h b/scripts/dtc/dtc.h
index 3e42a07..9c45fd2 100644
--- a/scripts/dtc/dtc.h
+++ b/scripts/dtc/dtc.h
@@ -245,6 +245,7 @@ struct boot_info {
struct boot_info *build_boot_info(struct reserve_info *reservelist,
struct node *tree, uint32_t boot_cpuid_phys);
void sort_tree(struct boot_info *bi);
+void free_dt(struct boot_info *bi);
/* Checks */
diff --git a/scripts/dtc/livetree.c b/scripts/dtc/livetree.c
index b61465f..5c8692c 100644
--- a/scripts/dtc/livetree.c
+++ b/scripts/dtc/livetree.c
@@ -20,6 +20,10 @@
#include dtc.h
+static void free_node_list(struct node *n);
+static void free_node(struct node *n);
+static void free_property(struct property *p);
+
/*
* Tree building functions
*/
@@ -144,7 +148,7 @@ struct node *merge_nodes(struct node *old_node, struct node
*new_node)
/* Add new node labels to old node */
for_each_label_withdel(new_node-labels, l)
- add_label(old_node-labels, l-label);
+ add_label(old_node-labels, xstrdup(l-label));
/* Move properties from the new node to the old node. If there
* is a collision, replace the old value with the new */
@@ -156,7 +160,7 @@ struct node *merge_nodes(struct node *old_node, struct node
*new_node)
if (new_prop-deleted) {
delete_property_by_name(old_node, new_prop-name);
- free(new_prop);
+ free_property(new_prop);
continue;
}
@@ -165,7 +169,7 @@ struct node *merge_nodes(struct node *old_node, struct node
*new_node)
if (streq(old_prop-name, new_prop-name)) {
/* Add new labels to old property */
for_each_label_withdel(new_prop-labels, l)
- add_label(old_prop-labels, l-label);
+ add_label(old_prop-labels,
xstrdup(l-label));
old_prop-val = new_prop-val;
old_prop-deleted = 0;
@@ -191,7 +195,7 @@ struct node *merge_nodes(struct node *old_node, struct node
*new_node)
if (new_child-deleted) {
delete_node_by_name(old_node, new_child-name);
- free(new_child);
+ free_node(new_child);
[RFC 02/15] scripts/dtc: build schema index for dts validation
From: Fabien Parent fpar...@baylibre.com
Add the infrastructure for dts validation through schema. The code build
an index of all the schemas found in a path given by the user on the
command line. This index will be used for the validation of a dts, it will be
used to know if a schema exists for a particular node and where to find it.
The association between a node of a dts and a schema is made through the
compatible property of the former.
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
interrupts = 0x0 0x25 0x4;
ti,hwmods = timer1;
ti,timer-alwon;
};
A schema for this node would probably be something like this:
/dts-v1/;
/ {
compatible = ti,omap3430-timer;
...
};
The compatible property in the schema is specified through a regular
expression so if the schema must validate timers for every omap device,
something like this would probably be more appropriate:
compatible = ti,omap[0-9]+-timer;
It is possible to specify several compatible in a single schema like this:
compatible = ti,omap3430-timer, ti,omap4430-timer;
The following syntax is also available:
compatible {
description = A small description;
value = ti,omap4430-timer;
};
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/.gitignore| 2 +-
scripts/dtc/Makefile | 9 +-
scripts/dtc/dtc.c | 19 ++-
scripts/dtc/dtc.h | 11 ++
scripts/dtc/schema-test.c | 67 +++
scripts/dtc/schema.c | 288 ++
6 files changed, 390 insertions(+), 6 deletions(-)
create mode 100644 scripts/dtc/schema-test.c
create mode 100644 scripts/dtc/schema.c
diff --git a/scripts/dtc/.gitignore b/scripts/dtc/.gitignore
index 095acb4..ff556dd 100644
--- a/scripts/dtc/.gitignore
+++ b/scripts/dtc/.gitignore
@@ -2,4 +2,4 @@ dtc
dtc-lexer.lex.c
dtc-parser.tab.c
dtc-parser.tab.h
-
+schema-test
diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
index 2a48022..7da5209 100644
--- a/scripts/dtc/Makefile
+++ b/scripts/dtc/Makefile
@@ -1,15 +1,18 @@
# scripts/dtc makefile
-hostprogs-y:= dtc
+hostprogs-y:= dtc schema-test
always := $(hostprogs-y)
dtc-objs := dtc.o flattree.o fstree.o data.o livetree.o treesource.o \
- srcpos.o checks.o util.o
+ srcpos.o checks.o util.o schema.o
dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
+schema-test-objs := $(dtc-objs:dtc.o=) schema-test.o
+
# Source files need to get at the userspace version of libfdt_env.h to compile
HOSTCFLAGS_DTC := -I$(src) -I$(src)/libfdt
+HOST_LOADLIBES := -lpcre
HOSTCFLAGS_checks.o := $(HOSTCFLAGS_DTC)
HOSTCFLAGS_data.o := $(HOSTCFLAGS_DTC)
@@ -20,6 +23,8 @@ HOSTCFLAGS_livetree.o := $(HOSTCFLAGS_DTC)
HOSTCFLAGS_srcpos.o := $(HOSTCFLAGS_DTC)
HOSTCFLAGS_treesource.o := $(HOSTCFLAGS_DTC)
HOSTCFLAGS_util.o := $(HOSTCFLAGS_DTC)
+HOSTCFLAGS_schema.o := $(HOSTCFLAGS_DTC)
+HOSTCFLAGS_schema-test.o := $(HOSTCFLAGS_DTC)
HOSTCFLAGS_dtc-lexer.lex.o := $(HOSTCFLAGS_DTC)
HOSTCFLAGS_dtc-parser.tab.o := $(HOSTCFLAGS_DTC)
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index 215ae92..a7881f0 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -96,16 +96,21 @@ static void __attribute__ ((noreturn)) usage(void)
fprintf(stderr, \t-W [no-]checkname\n);
fprintf(stderr, \t-E [no-]checkname\n);
fprintf(stderr, \t\t\tenable or disable warnings and errors\n);
+ fprintf(stderr, \t-M schema folder);
+ fprintf(stderr,
+ \t\tCheck the dts using schemas from the specified folder\n);
exit(3);
}
int main(int argc, char *argv[])
{
struct boot_info *bi;
+ struct schema_db *sdb;
const char *inform = dts;
const char *outform = dts;
const char *outname = -;
const char *depname = NULL;
+ const char *schemadir = NULL;
int force = 0, sort = 0;
const char *arg;
int opt;
@@ -118,7 +123,7 @@ int main(int argc, char *argv[])
minsize= 0;
padsize= 0;
- while ((opt = getopt(argc, argv, hI:O:o:V:d:R:S:p:fqb:i:vH:sW:E:))
+ while ((opt = getopt(argc, argv, hI:O:o:V:d:R:S:p:fqb:i:vH:sW:E:M:))
!= EOF) {
switch (opt) {
case 'I':
@@ -130,6 +135,9 @@ int main(int argc, char *argv[])
case 'o':
outname = optarg;
break;
+ case 'M':
+ schemadir = optarg;
+ break;
case 'V':
outversion = strtol(optarg, NULL, 0);
break;
@@ -212,9 +220,14 @@ int main(int argc, char *argv[])
fprintf(depfile, %s:, outname);
}
- if (streq(inform, dts))
+ if (streq(inform, dts)) {
bi =
[RFC 15/15] scripts/dtc: add verbose options
From: Fabien Parent fpar...@baylibre.com
The verbose option '-B' will show additional messages in addition
to all validation errors. Right now the level 0 prints every nodes
which don't have at least one schema associated to it. Level 1
prints every properties which were not validated due to missing
constraints.
Activate the verbose mode by default into the Makefile.
Usage example:
dtc -M ./bindings -B 1 file.dts
A count of errors found so far as also been added and is printed
on each error.
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/Makefile.lib | 2 +-
scripts/dtc/dtc.c| 11 -
scripts/dtc/dtc.h| 1 +
scripts/dtc/schema.c | 124 ---
4 files changed, 118 insertions(+), 20 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 358dd69..ea1484e 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -264,7 +264,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
quiet_cmd_dtc = DTC $@
cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $ ; \
$(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \
- -M $(objtree)/bindings \
+ -M $(objtree)/bindings -B 1 \
-i $(dir $) $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
cat $(depfile).pre.tmp $(depfile).dtc.tmp $(depfile)
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index a7881f0..8fee7ca 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -99,6 +99,8 @@ static void __attribute__ ((noreturn)) usage(void)
fprintf(stderr, \t-M schema folder);
fprintf(stderr,
\t\tCheck the dts using schemas from the specified folder\n);
+ fprintf(stderr, \t-B number\n);
+ fprintf(stderr, \t\tLevel of verbosity from the schema validation\n);
exit(3);
}
@@ -111,7 +113,7 @@ int main(int argc, char *argv[])
const char *outname = -;
const char *depname = NULL;
const char *schemadir = NULL;
- int force = 0, sort = 0;
+ int force = 0, sort = 0, verbose = 0;
const char *arg;
int opt;
FILE *outf = NULL;
@@ -123,7 +125,7 @@ int main(int argc, char *argv[])
minsize= 0;
padsize= 0;
- while ((opt = getopt(argc, argv, hI:O:o:V:d:R:S:p:fqb:i:vH:sW:E:M:))
+ while ((opt = getopt(argc, argv, hI:O:o:V:d:R:S:p:fqb:i:vH:sW:E:M:B:))
!= EOF) {
switch (opt) {
case 'I':
@@ -192,6 +194,10 @@ int main(int argc, char *argv[])
parse_checks_option(false, true, optarg);
break;
+ case 'B':
+ verbose = strtol(optarg, NULL, 0);
+ break;
+
case 'h':
default:
usage();
@@ -223,6 +229,7 @@ int main(int argc, char *argv[])
if (streq(inform, dts)) {
bi = dt_from_source(arg);
if (schemadir) {
+ set_verbosity_level(verbose);
sdb = build_schema_db(schemadir);
validate_dt(sdb, bi);
free_schema_db(sdb);
diff --git a/scripts/dtc/dtc.h b/scripts/dtc/dtc.h
index 64fdc8a..a4731e0 100644
--- a/scripts/dtc/dtc.h
+++ b/scripts/dtc/dtc.h
@@ -293,6 +293,7 @@ int validate_dt(struct schema_db *db, struct boot_info *bi);
struct schema_db *build_schema_db(const char *dir);
void free_schema_db(struct schema_db *db);
void exit_on_schema_validation_failure(int exit);
+void set_verbosity_level(int verbosity);
void add_to_schema_db(struct schema_db *db, const char *file);
struct schema_db *new_schema_db(void);
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index e349e01..3a2f831 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -46,6 +46,8 @@
static const char *const SCHEMA_EXT = .schema;
static const char *const VALUE_PROPNAME = value;
static int exit_on_failure = 0;
+static int verbose;
+static int error_count;
struct str_list {
char *str;
@@ -57,6 +59,11 @@ struct node_list {
struct node_list *next;
};
+struct property_list {
+ struct property *property;
+ struct property_list *next;
+};
+
struct range {
uint32_t low;
uint32_t high;
@@ -236,7 +243,7 @@ static void dt_error(struct node_list *path,
assert(format);
- fprintf(stderr, FATAL ERROR);
+ fprintf(stderr, [%d] FATAL ERROR, ++error_count);
if (p) {
fprintf(stderr, in %s:%d:%d,
p-loc.file, p-loc.line, p-loc.col);
@@ -581,15 +588,42 @@ static int check_value(struct property *p, struct
prop_constraints *pc)
return 1;
}
+static void remove_from_property_list(struct property *p,
+ struct property_list **plist)
+{
+ struct
[RFC 05/15] scripts/dtc: check type on properties
From: Fabien Parent fpar...@baylibre.com
Add the ability to check if a property has the correct type. Right now dtc only
handles the two trivial types: integer array, string array. Since at the end
everything is an array of byte which may or may not be terminated by a null
byte this was enough.
A nice thing to add for the future would be to be able to specify the types
more precisely.
Add as well two test files for this feature.
/ {
compatible = abc;
abc = 0xa 0xb 0xc;
def = def, gef;
};
To check that the property abc is an integer array and that the property def
is a string array for the dts above one can use the following schema:
/ {
compatible = abc;
abc {
type = integer;
};
def {
type = string;
};
};
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/data.c | 22
scripts/dtc/dtc.h| 9 +++
scripts/dtc/schema-test.c| 5
scripts/dtc/schema.c | 44
scripts/dtc/tests/schemas/types-1.schema | 12 +
scripts/dtc/tests/schemas/types-2.schema | 7 +
scripts/dtc/tests/test1.dts | 10
7 files changed, 104 insertions(+), 5 deletions(-)
create mode 100644 scripts/dtc/tests/schemas/types-1.schema
create mode 100644 scripts/dtc/tests/schemas/types-2.schema
create mode 100644 scripts/dtc/tests/test1.dts
diff --git a/scripts/dtc/data.c b/scripts/dtc/data.c
index 4a40c5b..9e03718 100644
--- a/scripts/dtc/data.c
+++ b/scripts/dtc/data.c
@@ -75,6 +75,7 @@ struct data data_copy_escape_string(const char *s, int len)
char *q;
d = data_grow_for(empty_data, strlen(s)+1);
+ d.type = STRING;
q = d.val;
while (i len) {
@@ -93,6 +94,7 @@ struct data data_copy_escape_string(const char *s, int len)
struct data data_copy_file(FILE *f, size_t maxlen)
{
struct data d = empty_data;
+ d.type = STRING;
while (!feof(f) (d.len maxlen)) {
size_t chunksize, ret;
@@ -157,6 +159,7 @@ struct data data_merge(struct data d1, struct data d2)
struct marker *m2 = d2.markers;
d = data_append_markers(data_append_data(d1, d2.val, d2.len), m2);
+ d.type = d2.type ? d2.type : d1.type;
/* Adjust for the length of d1 */
for_each_marker(m2)
@@ -178,23 +181,30 @@ struct data data_append_integer(struct data d, uint64_t
value, int bits)
switch (bits) {
case 8:
value_8 = value;
- return data_append_data(d, value_8, 1);
+ d = data_append_data(d, value_8, 1);
+ break;
case 16:
value_16 = cpu_to_fdt16(value);
- return data_append_data(d, value_16, 2);
+ d = data_append_data(d, value_16, 2);
+ break;
case 32:
value_32 = cpu_to_fdt32(value);
- return data_append_data(d, value_32, 4);
+ d = data_append_data(d, value_32, 4);
+ break;
case 64:
value_64 = cpu_to_fdt64(value);
- return data_append_data(d, value_64, 8);
+ d = data_append_data(d, value_64, 8);
+ break;
default:
die(Invalid literal size (%d)\n, bits);
}
+
+ d.type = INTEGER;
+ return d;
}
struct data data_append_re(struct data d, const struct fdt_reserve_entry *re)
@@ -219,7 +229,9 @@ struct data data_append_addr(struct data d, uint64_t addr)
struct data data_append_byte(struct data d, uint8_t byte)
{
- return data_append_data(d, byte, 1);
+ d = data_append_data(d, byte, 1);
+ d.type = INTEGER;
+ return d;
}
struct data data_append_zeroes(struct data d, int len)
diff --git a/scripts/dtc/dtc.h b/scripts/dtc/dtc.h
index e61dde7..a9b8602 100644
--- a/scripts/dtc/dtc.h
+++ b/scripts/dtc/dtc.h
@@ -82,10 +82,19 @@ struct marker {
struct marker *next;
};
+enum datatype {
+ UNDEFINED,
+ BOOLEAN,
+ INTEGER,
+ STRING,
+};
+
struct data {
int len;
char *val;
struct marker *markers;
+
+ enum datatype type;
};
diff --git a/scripts/dtc/schema-test.c b/scripts/dtc/schema-test.c
index 0eb2499..57c86d0 100644
--- a/scripts/dtc/schema-test.c
+++ b/scripts/dtc/schema-test.c
@@ -18,6 +18,11 @@ struct schema_test {
};
static struct schema_test tests[] = {
+ /* Types */
+ {Types #1, tests/test1.dts,
+tests/schemas/types-1.schema, 1},
+ {Types #2, tests/test1.dts,
+tests/schemas/types-2.schema, 0},
};
int main(void)
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index b190241..c01cdee 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -33,6 +33,7 @@ struct node_list {
struct prop_constraints {
const
[RFC 10/15] scripts/dtc: add count limit on nodes
From: Fabien Parent fpar...@baylibre.com
Add the possibility to specify in a schema a count limit for the nodes matching
the schema:
- count: if there is a match between a dts and a schema then there must
be exactly X match between the dts and the schema at the end of the
validation process.
- max-count: if there is a match between a dts and a schema then there must
be at most X match between the dts and the schema at the end of the
validation process.
This can be used to check if a specific node appears the right amount of time
in the dts.
Add as well four test files for this feature.
/ {
timer1 {
compatible = ti,omap-4430-timer;
...
};
timer2 {
compatible = ti,omap-4430-timer;
...
};
};
If in the above dts there must be exactly two timer one can check this
constraints with the following schema:
/ {
compatible = ti,omap-4430-timer;
count = 2;
};
Note: If the dts doesn't specify any timer the dts will still be valid. To
ensure that the timer is really present 2 times one should might wants to
specify constraints on then children of a node, but this feature is not
yet available.
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/schema-test.c | 10
scripts/dtc/schema.c | 63 --
scripts/dtc/tests/schemas/nodes-count-1.schema | 5 ++
scripts/dtc/tests/schemas/nodes-count-2.schema | 5 ++
scripts/dtc/tests/schemas/nodes-count-3.schema | 5 ++
scripts/dtc/tests/schemas/nodes-count-4.schema | 5 ++
6 files changed, 89 insertions(+), 4 deletions(-)
create mode 100644 scripts/dtc/tests/schemas/nodes-count-1.schema
create mode 100644 scripts/dtc/tests/schemas/nodes-count-2.schema
create mode 100644 scripts/dtc/tests/schemas/nodes-count-3.schema
create mode 100644 scripts/dtc/tests/schemas/nodes-count-4.schema
diff --git a/scripts/dtc/schema-test.c b/scripts/dtc/schema-test.c
index a8a5664..128a265 100644
--- a/scripts/dtc/schema-test.c
+++ b/scripts/dtc/schema-test.c
@@ -65,6 +65,16 @@ static struct schema_test tests[] = {
tests/schemas/pattern-matching-1.schema, 1},
{Pattern Matching #2, tests/test1.dts,
tests/schemas/pattern-matching-2.schema, 0},
+
+ /* Nodes Count */
+ {Nodes Count #1, tests/test1.dts,
+tests/schemas/nodes-count-1.schema, 1},
+ {Nodes Count #2, tests/test1.dts,
+tests/schemas/nodes-count-2.schema, 1},
+ {Nodes Count #3, tests/test1.dts,
+tests/schemas/nodes-count-3.schema, 0},
+ {Nodes Count #4, tests/test1.dts,
+tests/schemas/nodes-count-4.schema, 0},
};
int main(void)
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index d96129f..b7cfb37 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -88,7 +88,10 @@ struct node_constraints {
struct boot_info *bi;
struct node *dt;
- const char *compatible;
+ char *compatible;
+ uint32_t count_requested;
+ uint32_t count;
+ uint32_t max_count;
};
struct schema_db {
@@ -657,6 +660,23 @@ static int validate_properties(struct node *n,
return ret;
}
+static void load_node_constraints(struct node_constraints *nc,
+ struct node *n)
+{
+ struct property *p;
+
+ assert(n);
+ assert(nc);
+
+ nc-count = 0;
+
+ p = get_property(n, count);
+ nc-count_requested = p ? prop_val_to_uint32(p, 0) : 0;
+
+ p = get_property(n, max-count);
+ nc-max_count = p ? prop_val_to_uint32(p, 0) : ULONG_MAX;
+}
+
static int validate_node(struct node *n,
struct node_constraints *nc,
struct node_list *path)
@@ -698,6 +718,7 @@ static struct node_constraints
*get_node_constraints_of(struct schema_db *db,
n-bi = dt_from_source(n-filepath);
n-dt = n-bi-dt;
}
+ n-count++;
(*i)++;
return n;
}
@@ -705,6 +726,33 @@ static struct node_constraints
*get_node_constraints_of(struct schema_db *db,
return NULL;
}
+static int check_nodes_count(struct schema_db *db)
+{
+ int i;
+ int ret = 1;
+ struct node_constraints *n;
+
+ for (i = 0; i db-size; i++) {
+ n = db-buffer[i];
+
+ if (n-count_requested) {
+ DT_ERROR_IF(n-count != n-count_requested, NULL, NULL,
+ There is %u instance of %s instead
+ of %u.\n,
+ n-count,
+ n-compatible,
+ n-count_requested);
+ } else {
+ DT_ERROR_IF(n-count n-max_count, NULL, NULL,
+ There is too
[RFC 06/15] scripts/dtc: check for required properties
From: Fabien Parent fpar...@baylibre.com
Add the ability to specify inside a schema that a property is required to be
present in the validated node. By default a property can be missing but one can
require its presence inside a node via the 'is-required' property.
Add as well two test files for this feature.
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
interrupts = 0x0 0x25 0x4;
ti,hwmods = timer1;
ti,timer-alwon;
};
To make the ti,hwmods a required property inside an omap timer, one can use the
following schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
ti,hwmods {
is-required;
};
};
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/schema-test.c| 6 ++
scripts/dtc/schema.c | 6 ++
scripts/dtc/tests/schemas/required-property-1.schema | 7 +++
scripts/dtc/tests/schemas/required-property-2.schema | 7 +++
4 files changed, 26 insertions(+)
create mode 100644 scripts/dtc/tests/schemas/required-property-1.schema
create mode 100644 scripts/dtc/tests/schemas/required-property-2.schema
diff --git a/scripts/dtc/schema-test.c b/scripts/dtc/schema-test.c
index 57c86d0..8ac4f58 100644
--- a/scripts/dtc/schema-test.c
+++ b/scripts/dtc/schema-test.c
@@ -18,6 +18,12 @@ struct schema_test {
};
static struct schema_test tests[] = {
+ /* Required Properties */
+ {Required Property #1, tests/test1.dts,
+tests/schemas/required-property-1.schema, 0},
+ {Required Property #2, tests/test1.dts,
+tests/schemas/required-property-2.schema, 1},
+
/* Types */
{Types #1, tests/test1.dts,
tests/schemas/types-1.schema, 1},
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index c01cdee..97ea5b0 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -34,6 +34,7 @@ struct node_list {
struct prop_constraints {
const char *name;
char *type;
+ int is_required;
};
struct node_constraints {
@@ -199,6 +200,8 @@ load_property_constraints(struct node *schema)
pc = xmalloc(sizeof(*pc));
memset(pc, 0, sizeof(*pc));
+ pc-is_required = get_property(schema, is-required) != NULL;
+
p = get_property(schema, name);
if (p)
pc-name = p-val.val;
@@ -255,6 +258,9 @@ static int validate_property(struct node *n,
assert(pc);
assert(path);
+ if (pc-is_required !p)
+ DT_ERROR(path, NULL, Missing property '%s'\n, schema-name);
+
if (!p)
goto end;
diff --git a/scripts/dtc/tests/schemas/required-property-1.schema
b/scripts/dtc/tests/schemas/required-property-1.schema
new file mode 100644
index 000..469fa5b
--- /dev/null
+++ b/scripts/dtc/tests/schemas/required-property-1.schema
@@ -0,0 +1,7 @@
+/dts-v1/;
+/ {
+ compatible = compat1;
+ abc {
+ is-required;
+ };
+};
diff --git a/scripts/dtc/tests/schemas/required-property-2.schema
b/scripts/dtc/tests/schemas/required-property-2.schema
new file mode 100644
index 000..35bdde1
--- /dev/null
+++ b/scripts/dtc/tests/schemas/required-property-2.schema
@@ -0,0 +1,7 @@
+/dts-v1/;
+/ {
+ compatible = compat1;
+ mypropstr {
+ is-required;
+ };
+};
--
1.8.1.2
--
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
[RFC 08/15] scripts/dtc: check array size
From: Fabien Parent fpar...@baylibre.com
Add constraints on array size:
- length: specify the exact length that an array must have.
- min-length: specify the minimum number of elements an array must have.
- max-length: specify the maximum number of elements an array must have.
Add as well four test files for the feature.
Usage example:
node {
compatible = array_size;
myarray = 0 1 2 3 4;
};
Schema:
/dts-v1/;
/ {
compatible = array_size;
myarray {
length = 5;
};
};
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/data.c| 5 +++
scripts/dtc/dtc.h | 1 +
scripts/dtc/schema-test.c | 10 ++
scripts/dtc/schema.c | 52 +++
scripts/dtc/tests/schemas/array-size-1.schema | 13 +++
scripts/dtc/tests/schemas/array-size-2.schema | 8 +
scripts/dtc/tests/schemas/array-size-3.schema | 8 +
scripts/dtc/tests/schemas/array-size-4.schema | 8 +
8 files changed, 105 insertions(+)
create mode 100644 scripts/dtc/tests/schemas/array-size-1.schema
create mode 100644 scripts/dtc/tests/schemas/array-size-2.schema
create mode 100644 scripts/dtc/tests/schemas/array-size-3.schema
create mode 100644 scripts/dtc/tests/schemas/array-size-4.schema
diff --git a/scripts/dtc/data.c b/scripts/dtc/data.c
index 9e03718..5284936 100644
--- a/scripts/dtc/data.c
+++ b/scripts/dtc/data.c
@@ -76,6 +76,7 @@ struct data data_copy_escape_string(const char *s, int len)
d = data_grow_for(empty_data, strlen(s)+1);
d.type = STRING;
+ d.array_size++;
q = d.val;
while (i len) {
@@ -95,6 +96,7 @@ struct data data_copy_file(FILE *f, size_t maxlen)
{
struct data d = empty_data;
d.type = STRING;
+ d.array_size++;
while (!feof(f) (d.len maxlen)) {
size_t chunksize, ret;
@@ -159,6 +161,7 @@ struct data data_merge(struct data d1, struct data d2)
struct marker *m2 = d2.markers;
d = data_append_markers(data_append_data(d1, d2.val, d2.len), m2);
+ d.array_size += d2.array_size;
d.type = d2.type ? d2.type : d1.type;
/* Adjust for the length of d1 */
@@ -204,6 +207,7 @@ struct data data_append_integer(struct data d, uint64_t
value, int bits)
}
d.type = INTEGER;
+ d.array_size++;
return d;
}
@@ -231,6 +235,7 @@ struct data data_append_byte(struct data d, uint8_t byte)
{
d = data_append_data(d, byte, 1);
d.type = INTEGER;
+ d.array_size++;
return d;
}
diff --git a/scripts/dtc/dtc.h b/scripts/dtc/dtc.h
index a9b8602..64fdc8a 100644
--- a/scripts/dtc/dtc.h
+++ b/scripts/dtc/dtc.h
@@ -95,6 +95,7 @@ struct data {
struct marker *markers;
enum datatype type;
+ size_t array_size;
};
diff --git a/scripts/dtc/schema-test.c b/scripts/dtc/schema-test.c
index 99a4142..bfc9e43 100644
--- a/scripts/dtc/schema-test.c
+++ b/scripts/dtc/schema-test.c
@@ -35,6 +35,16 @@ static struct schema_test tests[] = {
tests/schemas/types-1.schema, 1},
{Types #2, tests/test1.dts,
tests/schemas/types-2.schema, 0},
+
+ /* Array Size */
+ {Array Size #1, tests/test1.dts,
+tests/schemas/array-size-1.schema, 1},
+ {Array Size #2, tests/test1.dts,
+tests/schemas/array-size-2.schema, 0},
+ {Array Size #3, tests/test1.dts,
+tests/schemas/array-size-3.schema, 0},
+ {Array Size #4, tests/test1.dts,
+tests/schemas/array-size-4.schema, 0},
};
int main(void)
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index 95fc44b..95ad925 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -5,6 +5,7 @@
#include dirent.h
#include pcre.h
#include stdio.h
+#include limits.h
#define DT_ERROR(path, p, format, ...) \
do { \
@@ -36,6 +37,8 @@ struct prop_constraints {
char *type;
int is_required;
int can_be_inherited;
+ size_t min_length;
+ size_t max_length;
};
struct node_constraints {
@@ -73,6 +76,28 @@ static pcre *compile_pattern(const char *pattern)
return re;
}
+static uint32_t prop_val_to_uint32(struct property *p, int i)
+{
+ assert(p);
+ assert(i = 0);
+
+ switch (p-val.len / p-val.array_size) {
+ case 1:
+ return ((uint8_t *) p-val.val)[i];
+
+ case 2:
+ return fdt16_to_cpu(((uint16_t *) p-val.val)[i]);
+
+ case 4:
+ return fdt32_to_cpu(((uint32_t *) p-val.val)[i]);
+
+ default:
+ die(reach unreachable.);
+ }
+
+ return 0;
+}
+
static int get_next_string_offset(struct property *p, int offset)
{
assert(p);
@@ -203,6 +228,7 @@ load_property_constraints(struct node *schema)
pc-is_required = get_property(schema, is-required)
[RFC 04/15] scripts/dtc: add procedure to handle dts errors
From: Fabien Parent fpar...@baylibre.com
The parser was not keeping enough information to allow a good error reporting.
Source Location information has been added inside a property instance to be
able to precisely tell where an error happened when a property does not match
its constraints as specified inside a schema.
Add as well a routine to print error message using these informations in case
of validation error.
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/dtc-parser.tab.c_shipped | 595 +++
scripts/dtc/dtc-parser.y | 9 +
scripts/dtc/dtc.h| 7 +
scripts/dtc/schema.c | 69
4 files changed, 345 insertions(+), 335 deletions(-)
diff --git a/scripts/dtc/dtc-parser.tab.c_shipped
b/scripts/dtc/dtc-parser.tab.c_shipped
index ee1d8c3..d6d800a 100644
--- a/scripts/dtc/dtc-parser.tab.c_shipped
+++ b/scripts/dtc/dtc-parser.tab.c_shipped
@@ -1,8 +1,8 @@
-/* A Bison parser, made by GNU Bison 2.5. */
+/* A Bison parser, made by GNU Bison 2.7.12-4996. */
/* Bison implementation for Yacc-like parsers in C
- Copyright (C) 1984, 1989-1990, 2000-2011 Free Software Foundation, Inc.
+ Copyright (C) 1984, 1989-1990, 2000-2013 Free Software Foundation, Inc.
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
@@ -44,7 +44,7 @@
#define YYBISON 1
/* Bison version. */
-#define YYBISON_VERSION 2.5
+#define YYBISON_VERSION 2.7.12-4996
/* Skeleton name. */
#define YYSKELETON_NAME yacc.c
@@ -58,14 +58,11 @@
/* Pull parsers. */
#define YYPULL 1
-/* Using locations. */
-#define YYLSP_NEEDED 0
/* Copy the first part of user declarations. */
-
-/* Line 268 of yacc.c */
+/* Line 371 of yacc.c */
#line 21 dtc-parser.y
#include stdio.h
@@ -85,14 +82,16 @@ extern int treesource_error;
static unsigned long long eval_literal(const char *s, int base, int bits);
static unsigned char eval_char_literal(const char *s);
+/* Line 371 of yacc.c */
+#line 87 dtc-parser.tab.c
-/* Line 268 of yacc.c */
-#line 91 dtc-parser.tab.c
-
-/* Enabling traces. */
-#ifndef YYDEBUG
-# define YYDEBUG 0
-#endif
+# ifndef YY_NULL
+# if defined __cplusplus 201103L = __cplusplus
+# define YY_NULL nullptr
+# else
+# define YY_NULL 0
+# endif
+# endif
/* Enabling verbose error messages. */
#ifdef YYERROR_VERBOSE
@@ -102,11 +101,14 @@ static unsigned char eval_char_literal(const char *s);
# define YYERROR_VERBOSE 0
#endif
-/* Enabling the token table. */
-#ifndef YYTOKEN_TABLE
-# define YYTOKEN_TABLE 0
-#endif
+/* Enabling traces. */
+#ifndef YYDEBUG
+# define YYDEBUG 0
+#endif
+#if YYDEBUG
+extern int yydebug;
+#endif
/* Tokens. */
#ifndef YYTOKENTYPE
@@ -140,12 +142,10 @@ static unsigned char eval_char_literal(const char *s);
#endif
-
#if ! defined YYSTYPE ! defined YYSTYPE_IS_DECLARED
typedef union YYSTYPE
{
-
-/* Line 293 of yacc.c */
+/* Line 387 of yacc.c */
#line 40 dtc-parser.y
char *propnodename;
@@ -168,21 +168,36 @@ typedef union YYSTYPE
uint64_t integer;
-
-/* Line 293 of yacc.c */
-#line 174 dtc-parser.tab.c
+/* Line 387 of yacc.c */
+#line 173 dtc-parser.tab.c
} YYSTYPE;
# define YYSTYPE_IS_TRIVIAL 1
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
# define YYSTYPE_IS_DECLARED 1
#endif
+extern YYSTYPE yylval;
-/* Copy the second part of user declarations. */
+#ifdef YYPARSE_PARAM
+#if defined __STDC__ || defined __cplusplus
+int yyparse (void *YYPARSE_PARAM);
+#else
+int yyparse ();
+#endif
+#else /* ! YYPARSE_PARAM */
+#if defined __STDC__ || defined __cplusplus
+int yyparse (void);
+#else
+int yyparse ();
+#endif
+#endif /* ! YYPARSE_PARAM */
-/* Line 343 of yacc.c */
-#line 186 dtc-parser.tab.c
+
+/* Copy the second part of user declarations. */
+
+/* Line 390 of yacc.c */
+#line 201 dtc-parser.tab.c
#ifdef short
# undef short
@@ -235,24 +250,33 @@ typedef short int yytype_int16;
# if defined YYENABLE_NLS YYENABLE_NLS
# if ENABLE_NLS
# include libintl.h /* INFRINGES ON USER NAME SPACE */
-# define YY_(msgid) dgettext (bison-runtime, msgid)
+# define YY_(Msgid) dgettext (bison-runtime, Msgid)
# endif
# endif
# ifndef YY_
-# define YY_(msgid) msgid
+# define YY_(Msgid) Msgid
+# endif
+#endif
+
+#ifndef __attribute__
+/* This feature is available in gcc versions 2.5 and later. */
+# if (! defined __GNUC__ || __GNUC__ 2 \
+ || (__GNUC__ == 2 __GNUC_MINOR__ 5))
+# define __attribute__(Spec) /* empty */
# endif
#endif
/* Suppress unused-variable warnings by using E. */
#if ! defined lint || defined __GNUC__
-# define YYUSE(e) ((void) (e))
+# define YYUSE(E) ((void) (E))
#else
-# define YYUSE(e) /* empty */
+# define YYUSE(E) /* empty */
#endif
+
/* Identity function, used to suppress warnings about constant
[RFC 11/15] scripts/dtc: check for children nodes
From: Fabien Parent fpar...@baylibre.com
Add the ability to check if a node has some required children nodes.
Add as well two test files for this feature.
node {
compatible = comp;
subnode1 {
};
subnode2 {
};
abc {
};
};
One can check if 'node' has the following subnode 'subnode1', 'subnode2', and
'abc' with the schema below:
/dts-v1/;
/ {
compatible = comp;
children = abc, subnode[0-9];
};
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/schema-test.c | 6 +++
scripts/dtc/schema.c | 47 +++
scripts/dtc/tests/schemas/children-nodes-1.schema | 5 +++
scripts/dtc/tests/schemas/children-nodes-2.schema | 5 +++
scripts/dtc/tests/test1.dts | 4 ++
5 files changed, 67 insertions(+)
create mode 100644 scripts/dtc/tests/schemas/children-nodes-1.schema
create mode 100644 scripts/dtc/tests/schemas/children-nodes-2.schema
diff --git a/scripts/dtc/schema-test.c b/scripts/dtc/schema-test.c
index 128a265..9f1ce31 100644
--- a/scripts/dtc/schema-test.c
+++ b/scripts/dtc/schema-test.c
@@ -75,6 +75,12 @@ static struct schema_test tests[] = {
tests/schemas/nodes-count-3.schema, 0},
{Nodes Count #4, tests/test1.dts,
tests/schemas/nodes-count-4.schema, 0},
+
+ /* Children nodes */
+ {Children Nodes #1, tests/test1.dts,
+tests/schemas/children-nodes-1.schema, 1},
+ {Children Nodes #2, tests/test1.dts,
+tests/schemas/children-nodes-2.schema, 0},
};
int main(void)
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index b7cfb37..a454a19 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -47,6 +47,11 @@ static const char *const SCHEMA_EXT = .schema;
static const char *const VALUE_PROPNAME = value;
static int exit_on_failure = 0;
+struct str_list {
+ char *str;
+ struct str_list *next;
+};
+
struct node_list {
struct node *n;
struct node_list *next;
@@ -92,6 +97,7 @@ struct node_constraints {
uint32_t count_requested;
uint32_t count;
uint32_t max_count;
+ struct str_list *children;
};
struct schema_db {
@@ -664,6 +670,8 @@ static void load_node_constraints(struct node_constraints
*nc,
struct node *n)
{
struct property *p;
+ int i = 0;
+ struct str_list *iter;
assert(n);
assert(nc);
@@ -675,6 +683,15 @@ static void load_node_constraints(struct node_constraints
*nc,
p = get_property(n, max-count);
nc-max_count = p ? prop_val_to_uint32(p, 0) : ULONG_MAX;
+
+ p = get_property(n, children);
+ while (p i p-val.len i = 0) {
+ iter = xmalloc(sizeof(*iter));
+ iter-str = xstrdup(p-val.val + i);
+ iter-next = nc-children;
+ nc-children = iter;
+ i = get_next_string_offset(p, i);
+ }
}
static int validate_node(struct node *n,
@@ -682,7 +699,10 @@ static int validate_node(struct node *n,
struct node_list *path)
{
struct node *iter;
+ struct str_list *pattern;
int ret = 1;
+ pcre *re;
+ int has_child;
assert(n);
assert(path);
@@ -692,6 +712,27 @@ static int validate_node(struct node *n,
for (iter = nc-dt-children; iter; iter = iter-next_sibling)
ret = validate_properties(n, iter, path);
+ /* Check whether the node has all the required children nodes */
+ for (pattern = nc-children;
+pattern;
+pattern = pattern-next) {
+ re = compile_pattern(pattern-str);
+ if (!re)
+ die(Invalid pattern: %s\n, pattern-str);
+
+ has_child = 0;
+ for (iter = n-children; iter; iter = iter-next_sibling) {
+ has_child |= pcre_exec(re, 0, iter-name,
+ strlen(iter-name), 0, 0,
+ NULL, 0) = 0;
+ }
+
+ pcre_free(re);
+ DT_ERROR_IF(!has_child, path, NULL,
+ Missing child node '%s'\n, pattern-str);
+ }
+
+end:
return ret;
}
@@ -1021,9 +1062,15 @@ struct schema_db *build_schema_db(const char *dir)
static void free_node_constraints(struct node_constraints *nc)
{
+ struct str_list *iter, *iter_next;
+
if (!nc)
return;
+ for_each_safe(nc-children, iter, iter_next) {
+ free(iter-str);
+ }
+
pcre_free(nc-re_compat);
free_dt(nc-bi);
free(nc-filepath);
diff --git a/scripts/dtc/tests/schemas/children-nodes-1.schema
b/scripts/dtc/tests/schemas/children-nodes-1.schema
new file mode 100644
index 000..8f1cf9a
--- /dev/null
+++
[RFC 09/15] scripts/dtc: check value of properties
From: Fabien Parent fpar...@baylibre.com
Add the ability to check whether a property has a given value or not.
Add as well 7 test files for this feature.
abc {
prop1 = 0 1 2 3;
prop2 = value0, value1, value3;
};
To check whether an integer array contains value from a given range
use the following constraint:
prop1 {
type = integer;
value = 0x0 0xF;
};
To check whether a string array contains value that match a given pattern
use the following constraint:
prop2 {
type = string;
value = value[0-9];
};
To check whether a particular element of an array has the correct value one
can use the following constraint:
prop1 {
type = integer;
value@2 = 2;
};
or
prop2 {
type = string;
value@1 = value1;
};
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/schema-test.c | 20 ++
scripts/dtc/schema.c | 288 +
scripts/dtc/tests/schemas/integer-array-1.schema | 16 ++
scripts/dtc/tests/schemas/integer-array-2.schema | 9 +
scripts/dtc/tests/schemas/integer-array-3.schema | 8 +
.../dtc/tests/schemas/pattern-matching-1.schema| 10 +
.../dtc/tests/schemas/pattern-matching-2.schema| 10 +
scripts/dtc/tests/schemas/string-array-1.schema| 20 ++
scripts/dtc/tests/schemas/string-array-2.schema| 9 +
scripts/dtc/tests/test1.dts| 4 +
10 files changed, 394 insertions(+)
create mode 100644 scripts/dtc/tests/schemas/integer-array-1.schema
create mode 100644 scripts/dtc/tests/schemas/integer-array-2.schema
create mode 100644 scripts/dtc/tests/schemas/integer-array-3.schema
create mode 100644 scripts/dtc/tests/schemas/pattern-matching-1.schema
create mode 100644 scripts/dtc/tests/schemas/pattern-matching-2.schema
create mode 100644 scripts/dtc/tests/schemas/string-array-1.schema
create mode 100644 scripts/dtc/tests/schemas/string-array-2.schema
diff --git a/scripts/dtc/schema-test.c b/scripts/dtc/schema-test.c
index bfc9e43..a8a5664 100644
--- a/scripts/dtc/schema-test.c
+++ b/scripts/dtc/schema-test.c
@@ -45,6 +45,26 @@ static struct schema_test tests[] = {
tests/schemas/array-size-3.schema, 0},
{Array Size #4, tests/test1.dts,
tests/schemas/array-size-4.schema, 0},
+
+ /* String Array */
+ {String Array Values #1, tests/test1.dts,
+tests/schemas/string-array-1.schema, 1},
+ {String Array Values #2, tests/test1.dts,
+tests/schemas/string-array-2.schema, 0},
+
+ /* Integer Array */
+ {Integer Array Values #1, tests/test1.dts,
+tests/schemas/integer-array-1.schema, 1},
+ {Integer Array Values #2, tests/test1.dts,
+tests/schemas/integer-array-2.schema, 0},
+ {Integer Array Values #3, tests/test1.dts,
+tests/schemas/integer-array-3.schema, 0},
+
+ /* Pattern Matching */
+ {Pattern Matching #1, tests/test1.dts,
+tests/schemas/pattern-matching-1.schema, 1},
+ {Pattern Matching #2, tests/test1.dts,
+tests/schemas/pattern-matching-2.schema, 0},
};
int main(void)
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index 95ad925..d96129f 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -7,6 +7,26 @@
#include stdio.h
#include limits.h
+#define sorted_list_add(x, e) \
+ do { \
+ typeof(x) prev, i; \
+ if (!x) {\
+ x = e; \
+ break; \
+ } \
+ for (prev = x, i = x-next; \
+i i-id e-id; \
+prev = i, i = i-next) \
+ ; \
+ e-next = i; \
+ prev-next = e; \
+ } while (0)
+
+#define for_each_safe(list, iter, iter_next) \
+ for (iter = list, iter_next = list ? list-next : NULL;\
+iter; \
+iter = iter_next, iter_next = iter_next ? iter_next-next : NULL)
+
#define DT_ERROR(path, p, format, ...) \
do { \
dt_error(path, p, format, ##__VA_ARGS__); \
@@ -32,6 +52,21 @@ struct node_list {
struct node_list *next;
};
+struct range {
+ uint32_t low;
+ uint32_t high;
+ int id;
+
+ struct range *next;
+};
+
+struct pattern {
+ const char *text;
+ int id;
+
+ struct pattern *next;
+};
+
struct prop_constraints {
const char *name;
char *type;
@@ -39,6 +74,12 @@ struct prop_constraints {
int can_be_inherited;
size_t min_length;
size_t max_length;
+
+ union {
+ struct pattern *patterns;
+ struct range *ranges;
+ } value;
+ enum datatype value_type;
};
struct node_constraints {
@@ -207,11 +248,139 @@ static void dt_error(struct node_list *path,
exit(1);
}
+static
[RFC 12/15] scripts/dtc: check constraints on parents
From: Fabien Parent fpar...@baylibre.com
Add the ability to specify constraints on the parents of a node.
Add as well seven test files for this feature.
node {
compatible = abcomp;
abc = abc;
subnode {
compatible = comp;
abc = def;
};
};
The schema below tests whether 'subnode' has a parent named 'node' and whether
it has a compatible property equal to abcomp and a 'abc' property equal to
abc. In the case of the node above the constraints couldn't be check by
inheriting the properties via 'can-be-inherited' since they are overwritten
by the node 'subnode'.
/dts-v1/;
/ {
compatible = comp;
parents {
node {
compatible {
type = string;
value = abcomp;
};
abc {
type = string;
value = abc;
};
};
};
};
It is possible to set conditional constraints on parents of the following form:
if (node_compatible == compat1)
check_this_parent_constraints();
else if (node_compatible == compat2)
check_that_parent_constraints();
To do this one should put the parent constraints at the same place as the
compatible definition in a schema file.
/dts-v1/;
/ {
compatible {
value@0 {
value = compat1;
parents {
node {
myprop {
type = int;
value@0 = 0xf;
};
};
};
};
value@1 {
value = compat2;
parents {
node {
myprop {
type = int;
value@0 = 0xa;
};
};
};
};
};
};
This schema will check that if the compatible of a node is compat1 then it
must have a parent node node which has an integer array property myprop
which has as first element the value 0xf, otherwise if the node has the
compatible compat2 then the first element of the same property must have the
value 0xa.
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/schema-test.c | 16 +++
scripts/dtc/schema.c| 126 +++-
scripts/dtc/tests/schemas/parent-nodes-1.schema | 23 +
scripts/dtc/tests/schemas/parent-nodes-2.schema | 12 +++
scripts/dtc/tests/schemas/parent-nodes-3.schema | 14 +++
scripts/dtc/tests/schemas/parent-nodes-4.schema | 27 +
scripts/dtc/tests/schemas/parent-nodes-5.schema | 15 +++
scripts/dtc/tests/schemas/parent-nodes-6.schema | 13 +++
scripts/dtc/tests/schemas/parent-nodes-7.schema | 13 +++
9 files changed, 257 insertions(+), 2 deletions(-)
create mode 100644 scripts/dtc/tests/schemas/parent-nodes-1.schema
create mode 100644 scripts/dtc/tests/schemas/parent-nodes-2.schema
create mode 100644 scripts/dtc/tests/schemas/parent-nodes-3.schema
create mode 100644 scripts/dtc/tests/schemas/parent-nodes-4.schema
create mode 100644 scripts/dtc/tests/schemas/parent-nodes-5.schema
create mode 100644 scripts/dtc/tests/schemas/parent-nodes-6.schema
create mode 100644 scripts/dtc/tests/schemas/parent-nodes-7.schema
diff --git a/scripts/dtc/schema-test.c b/scripts/dtc/schema-test.c
index 9f1ce31..5075c24 100644
--- a/scripts/dtc/schema-test.c
+++ b/scripts/dtc/schema-test.c
@@ -81,6 +81,22 @@ static struct schema_test tests[] = {
tests/schemas/children-nodes-1.schema, 1},
{Children Nodes #2, tests/test1.dts,
tests/schemas/children-nodes-2.schema, 0},
+
+ /* Parent nodes */
+ {Parent Nodes #1, tests/test1.dts,
+tests/schemas/parent-nodes-1.schema, 1},
+ {Parent Nodes #2, tests/test1.dts,
+tests/schemas/parent-nodes-2.schema, 0},
+ {Parent Nodes #3, tests/test1.dts,
+tests/schemas/parent-nodes-3.schema, 0},
+ {Parent Nodes #4, tests/test1.dts,
+tests/schemas/parent-nodes-4.schema, 1},
+ {Parent Nodes #5, tests/test1.dts,
+tests/schemas/parent-nodes-5.schema, 0},
+ {Parent Nodes #6, tests/test1.dts,
+tests/schemas/parent-nodes-6.schema, 0},
+ {Parent Nodes #7, tests/test1.dts,
+tests/schemas/parent-nodes-7.schema, 1},
};
int main(void)
diff --git a/scripts/dtc/schema.c b/scripts/dtc/schema.c
index a454a19..e349e01 100644
--- a/scripts/dtc/schema.c
+++ b/scripts/dtc/schema.c
@@ -694,6 +694,123 @@ static void load_node_constraints(struct node_constraints
*nc,
}
}
+static struct node *find_parent_node(struct node *schema,
+struct node_list *path)
+{
+ struct property *p;
+ char *name;
+
+ if (!path)
+ return NULL;
+
+ assert(schema);
+ assert(path-n);
+
+ p = get_property(schema, name);
+ if (p) {
+ assert(p-val.type == STRING);
[RFC 13/15] bindings: OMAP: add new schema files
From: Fabien Parent fpar...@baylibre.com
Introduce a couple of real schema for OMAP DTS files. For the moment validate
only: MPU, DSP, INTC, IVA, TIME and COUNTER.
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
bindings/arm/omap/counter.schema | 28 +
bindings/arm/omap/dsp.schema | 18 ++
bindings/arm/omap/intc.schema| 48 +++
bindings/arm/omap/iva.schema | 38
bindings/arm/omap/l3-noc.schema | 38
bindings/arm/omap/mpu.schema | 19 ++
bindings/arm/omap/omap.schema| 62
bindings/arm/omap/timer.schema | 124 +++
8 files changed, 375 insertions(+)
create mode 100644 bindings/arm/omap/counter.schema
create mode 100644 bindings/arm/omap/dsp.schema
create mode 100644 bindings/arm/omap/intc.schema
create mode 100644 bindings/arm/omap/iva.schema
create mode 100644 bindings/arm/omap/l3-noc.schema
create mode 100644 bindings/arm/omap/mpu.schema
create mode 100644 bindings/arm/omap/omap.schema
create mode 100644 bindings/arm/omap/timer.schema
diff --git a/bindings/arm/omap/counter.schema b/bindings/arm/omap/counter.schema
new file mode 100644
index 000..63b0272
--- /dev/null
+++ b/bindings/arm/omap/counter.schema
@@ -0,0 +1,28 @@
+/**
+ * OMAP Counter-32K bindings
+ */
+
+/dts-v1/;
+
+/ {
+compatible {
+description = Must be 'ti,omap-counter32k' for OMAP controllers.;
+value = ti,omap-counter32k;
+};
+
+reg {
+description = Contains timer register address range (base address
+ and length).;
+is-required;
+type = integer;
+length = 2;
+};
+
+ti,hwmods {
+description = Name of the hwmod associated to the counter,
+ which is typically 'counter_32k'.;
+is-required;
+type = string;
+value = counter_32k;
+};
+};
diff --git a/bindings/arm/omap/dsp.schema b/bindings/arm/omap/dsp.schema
new file mode 100644
index 000..7087f60
--- /dev/null
+++ b/bindings/arm/omap/dsp.schema
@@ -0,0 +1,18 @@
+/**
+ * TI - DSP (Digital Signal Processor)
+ */
+
+/dts-v1/;
+
+/ {
+compatible {
+description = Should be 'ti,omap3-c64' for OMAP3 4;
+value = ti,omap3-c64;
+};
+
+ti,hwmods {
+is-required;
+type = string;
+value = dsp;
+};
+};
diff --git a/bindings/arm/omap/intc.schema b/bindings/arm/omap/intc.schema
new file mode 100644
index 000..564c80e
--- /dev/null
+++ b/bindings/arm/omap/intc.schema
@@ -0,0 +1,48 @@
+/**
+ * OMAP Interrupt Controller
+ *
+ * OMAP2/3 are using a TI interrupt controller that can support several
+ * configurable number of interrupts.
+ */
+
+/dts-v1/;
+
+/ {
+compatible {
+description = Must be 'ti,omap-counter32k' for OMAP controllers.;
+value = ti,omap2-intc;
+};
+
+interrupt-controller {
+description = Identifies the node as an interrupt controller;
+is-required;
+type = bool;
+};
+
+#interrupt-cells {
+description = Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a u32
+ and the value shall be 1.
+ The cell contains the interrupt number
+ in the range [0-128].;
+is-required;
+type = integer;
+value = 1;
+};
+
+ti,intc-size {
+description = Number of interrupts handled
+ by the interrupt controller;
+is-required;
+type = integer;
+length = 1;
+};
+
+reg {
+description = physical base address and size of the intc
+ registers map.;
+is-required;
+type = integer;
+length = 2;
+};
+};
diff --git a/bindings/arm/omap/iva.schema b/bindings/arm/omap/iva.schema
new file mode 100644
index 000..582c104
--- /dev/null
+++ b/bindings/arm/omap/iva.schema
@@ -0,0 +1,38 @@
+/**
+ * TI - IVA (Imaging and Video Accelerator) subsystem
+ *
+ * The IVA contain various audio, video or imaging HW accelerator
+ * depending of the version.
+ */
+
+/dts-v1/;
+
+/ {
+compatible {
+value@0 {
+description = for OMAP4;
+value = ti,ivahd;
+};
+
+value@1 {
+description = for OMAP3;
+value = ti,iva2.2;
+};
+
+value@2 {
+description = for OMAP2430;
+value = ti,iva2.1;
+};
+
+value@3 {
+description = for OMAP2420;
+value = ti,iva1;
+};
+};
+
+ti,hwmods {
+is-required;
+type = string;
+value = iva;
+};
+};
diff --git a/bindings/arm/omap/l3-noc.schema b/bindings/arm/omap/l3-noc.schema
new file mode 100644
index 000..0611c4d
--- /dev/null
+++ b/bindings/arm/omap/l3-noc.schema
@@ -0,0
[RFC 14/15] scripts/dtc: validate dts against schema bindings
From: Fabien Parent fpar...@baylibre.com Add the path of the bindings schema directory on the command line used for compiling the dts files. The dts files will be validated against all the matching schemas found. Signed-off-by: Fabien Parent fpar...@baylibre.com Signed-off-by: Benoit Cousson bcous...@baylibre.com --- scripts/Makefile.lib | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 49392ec..358dd69 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -264,6 +264,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb quiet_cmd_dtc = DTC $@ cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $ ; \ $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \ + -M $(objtree)/bindings \ -i $(dir $) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) ; \ cat $(depfile).pre.tmp $(depfile).dtc.tmp $(depfile) -- 1.8.1.2 -- 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
Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger
On Monday 23 September 2013 22:47:15 Sebastian Reichel wrote: On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote: On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote: On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote: It is not as simple as it looks. This is reason why I submited this patch long time after I submited bq2415x driver. Problem is that for rx51 is needed specific function which connect to two drivers (bq2415x and isp1704) plus it call specific rx51 board functions. Something which cannot be in DT (unless DT support C/ASM code). mh could isp1704 driver expose the data via the regulator framework? No, isp1704 is power supply driver and export data via power supply (sysfs) interface. It is not regulator but charger driver. well it does not charge the battery directly, but just provides a power line with 5 Volt and a specified amount of current to the system, doesn't it? No, isp1704 driver is doing fastcharger detection (and then export charger type via sysfs power supply) based on musb usb events. Real charging (enabling/disabling and setting properties) is done by bq24150a chip which has own power driver bq2415x_charger. As already wrote this is not simple and this is reason why I sent board data and functions only now... From my POV this is a candiate for the regulator framework: https://www.kernel.org/doc/Documentation/power/regulator/overv iew.txt -- Sebastian -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
Hi Santosh, On Tue, Aug 13, 2013 at 02:31:04PM +0100, Santosh Shilimkar wrote: On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote: On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote: On Friday 02 August 2013 11:48 AM, Will Deacon wrote: I think this an A9-specific register, which reads as 0 on UP A9 and reads as some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE is zero. What do we do here ? Should we document this in the code and proceed ? Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but I am open for any other alternative. The only other alternative I can think of is forcing people to have CONFIG_SMP=n, but that blows away single zImage for your platform. Yep which surely we don't want considering after so much effort we have it working first place. How about going ahead with assumption that PERIPH_BASE = 0 case doesn't work. It's been over a month and I can't think of anything better than this without jeopardising the single zImage effort. However, it also doesn't seem fair if we rule out the possibility of single zImage for future SoCs which use 0x0 as their PERIPH_BASE (I don't know of any at the moment). So how about we go ahead with this, but add a big fat comment to the code in head.S saying that, if a future SoC *does* use 0x0 as the PERIPH_BASE, then the check will need to be #ifdef'd or equivalent for the Aegis platform? Will -- 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
[PATCH] ARM: drop explicit selection of HAVE_CLK and CLKDEV_LOOKUP
CLKDEV_LOOKUP selects HAVE_CLK and COMMON_CLK selects CLKDEV_LOOKUP. So all symbols that select at least two of these symbols can be simplified. For imx, omap2 and ux500 some rearrangements were necessary before the simplification. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- arch/arm/Kconfig | 12 arch/arm/mach-highbank/Kconfig | 1 - arch/arm/mach-imx/Kconfig | 10 +- arch/arm/mach-omap2/Kconfig| 9 + arch/arm/mach-socfpga/Kconfig | 1 - arch/arm/mach-spear/Kconfig| 2 -- arch/arm/mach-tegra/Kconfig| 2 -- arch/arm/mach-u300/Kconfig | 1 - arch/arm/mach-ux500/Kconfig| 29 - arch/arm/mach-vexpress/Kconfig | 2 -- arch/arm/mach-vt8500/Kconfig | 1 - 11 files changed, 14 insertions(+), 56 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3230f4c..66164a0 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -360,7 +360,6 @@ config ARCH_AT91 bool Atmel AT91 select ARCH_REQUIRE_GPIOLIB select CLKDEV_LOOKUP - select HAVE_CLK select IRQ_DOMAIN select NEED_MACH_GPIO_H select NEED_MACH_IO_H if PCCARD @@ -374,7 +373,6 @@ config ARCH_CLPS711X bool Cirrus Logic CLPS711x/EP721x/EP731x-based select ARCH_REQUIRE_GPIOLIB select AUTO_ZRELADDR - select CLKDEV_LOOKUP select CLKSRC_MMIO select COMMON_CLK select CPU_ARM720T @@ -633,7 +631,6 @@ config ARCH_PXA config ARCH_MSM bool Qualcomm MSM select ARCH_REQUIRE_GPIOLIB - select CLKDEV_LOOKUP select CLKSRC_OF if OF select COMMON_CLK select GENERIC_CLOCKEVENTS @@ -651,7 +648,6 @@ config ARCH_SHMOBILE select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU if SMP select HAVE_ARM_TWD if SMP - select HAVE_CLK select HAVE_MACH_CLKDEV select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 @@ -708,7 +704,6 @@ config ARCH_S3C24XX select CLKSRC_SAMSUNG_PWM select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG - select HAVE_CLK select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS @@ -733,7 +728,6 @@ config ARCH_S3C64XX select CPU_V6 select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG - select HAVE_CLK select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_TCM @@ -756,7 +750,6 @@ config ARCH_S5P64X0 select CPU_V6 select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG - select HAVE_CLK select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS @@ -775,7 +768,6 @@ config ARCH_S5PC100 select CPU_V7 select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG - select HAVE_CLK select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS @@ -795,7 +787,6 @@ config ARCH_S5PV210 select CPU_V7 select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG - select HAVE_CLK select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS @@ -812,11 +803,9 @@ config ARCH_EXYNOS select ARCH_REQUIRE_GPIOLIB select ARCH_SPARSEMEM_ENABLE select ARM_GIC - select CLKDEV_LOOKUP select COMMON_CLK select CPU_V7 select GENERIC_CLOCKEVENTS - select HAVE_CLK select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS @@ -867,7 +856,6 @@ config ARCH_OMAP1 select CLKSRC_MMIO select GENERIC_CLOCKEVENTS select GENERIC_IRQ_CHIP - select HAVE_CLK select HAVE_IDE select IRQ_DOMAIN select NEED_MACH_IO_H if PCCARD diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig index 8e8437d..616408d 100644 --- a/arch/arm/mach-highbank/Kconfig +++ b/arch/arm/mach-highbank/Kconfig @@ -12,7 +12,6 @@ config ARCH_HIGHBANK select ARM_GIC select ARM_TIMER_SP804 select CACHE_L2X0 - select CLKDEV_LOOKUP select COMMON_CLK select CPU_V7 select GENERIC_CLOCKEVENTS diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 9f67338..0026a95 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -4,8 +4,8 @@ config ARCH_MXC select ARM_CPU_SUSPEND if PM select ARM_PATCH_PHYS_VIRT select AUTO_ZRELADDR if !ZBOOT_ROM - select CLKDEV_LOOKUP select CLKSRC_MMIO + select COMMON_CLK select GENERIC_ALLOCATOR select GENERIC_CLOCKEVENTS select GENERIC_IRQ_CHIP @@ -92,14 +92,12 @@ config MACH_MX27 config SOC_IMX1 bool
Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
On Tuesday 24 September 2013 01:08 PM, Will Deacon wrote: Hi Santosh, On Tue, Aug 13, 2013 at 02:31:04PM +0100, Santosh Shilimkar wrote: On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote: On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote: On Friday 02 August 2013 11:48 AM, Will Deacon wrote: I think this an A9-specific register, which reads as 0 on UP A9 and reads as some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE is zero. What do we do here ? Should we document this in the code and proceed ? Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but I am open for any other alternative. The only other alternative I can think of is forcing people to have CONFIG_SMP=n, but that blows away single zImage for your platform. Yep which surely we don't want considering after so much effort we have it working first place. How about going ahead with assumption that PERIPH_BASE = 0 case doesn't work. It's been over a month and I can't think of anything better than this without jeopardising the single zImage effort. However, it also doesn't seem fair if we rule out the possibility of single zImage for future SoCs which use 0x0 as their PERIPH_BASE (I don't know of any at the moment). So how about we go ahead with this, but add a big fat comment to the code in head.S saying that, if a future SoC *does* use 0x0 as the PERIPH_BASE, then the check will need to be #ifdef'd or equivalent for the Aegis platform? I agree. Updated patch end of the email. If you are fine with this version, will stick it into RMK's patch system. Regards, Santosh From 05b1b43324f3e8d10a38f78dbcbf7632d4c3530c Mon Sep 17 00:00:00 2001 From: Vaibhav Bedia vaibhav.be...@ti.com Date: Thu, 18 Jul 2013 13:01:53 -0400 Subject: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices The generic code is well equipped to differentiate between SMP and UP configurations.However, there are some devices which use Cortex-A9 MP core IP with 1 CPU as configuration. To let these SOCs to co-exist in a CONFIG_SMP=y build by leveraging the SMP_ON_UP support, we need to additionally check the number the cores in Cortex-A9 MPCore configuration. Without such a check in place, the startup code tries to execute ALT_SMP() set of instructions which lead to CPU faults. The issue was spotted on TI's Aegis device and this patch makes now the device work with omap2plus_defconfig which enables SMP by default. The change is kept limited to only Cortex-A9 MPCore detection code. Note that if any future SoC *does* use 0x0 as the PERIPH_BASE, then the SCU address check code needs to be #ifdef'd for for the Aegis platform. Cc: Will Deacon will.dea...@arm.com Cc: Russell King li...@arm.linux.org.uk Acked-by: Sricharan R r.sricha...@ti.com Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/kernel/head.S | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 2c7cc1e..476de57 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -487,7 +487,26 @@ __fixup_smp: mrc p15, 0, r0, c0, c0, 5 @ read MPIDR and r0, r0, #0xc000 @ multiprocessing extensions and teq r0, #0x8000 @ not part of a uniprocessor system? - moveq pc, lr @ yes, assume SMP + bne__fixup_smp_on_up@ no, assume UP + + @ Core indicates it is SMP. Check for Aegis SOC where a single + @ Cortex-A9 CPU is present but SMP operations fault. + mov r4, #0x4100 + orr r4, r4, #0xc000 + orr r4, r4, #0x0090 + teq r3, r4 @ Check for ARM Cortex-A9 + movne pc, lr @ Not ARM Cortex-A9, + + @ If a future SoC *does* use 0x0 as the PERIPH_BASE, then the + @ below address check will need to be #ifdef'd or equivalent + @ for the Aegis platform. + mrc p15, 4, r0, c15, c0 @ get SCU base address + teq r0, #0x0@ '0' on actual UP A9 hardware + beq __fixup_smp_on_up @ So its an A9 UP + ldr r0, [r0, #4]@ read SCU Config + and r0, r0, #0x3@ number of CPUs + teq r0, #0x0@ is 1? + movne pc, lr __fixup_smp_on_up: adr r0, 1f -- 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
RE: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
This patch - updates DT binding for selection of ecc-scheme - updates DT binding for detection of ELM h/w engine - removes following obselete ECC schemes OMAP_ECC_HAMMING_CODE_DEFAULT (S/W based 1-bit Hamming ECC) OMAP_ECC_HAMMING_CODE_HW_ROMCODE (H/W based 1-bit Hamming ECC scheme) - updates DT binding documentation for mtd/gpmc-nand Signed-off-by: Pekon Gupta pe...@ti.com --- Dear Olof and other DT Maintainers, This patch series has missed multiple merge windows, and much of the other development work on mtd/nand/omap driver is gated due to this. So, request you to please review this patch set and Ack it if all your mentioned concerns are resolved. With regards, pekon -- 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
Re: [PATCH] ARM: drop explicit selection of HAVE_CLK and CLKDEV_LOOKUP
* Uwe Kleine-König u.kleine-koe...@pengutronix.de [130924 10:50]: CLKDEV_LOOKUP selects HAVE_CLK and COMMON_CLK selects CLKDEV_LOOKUP. So all symbols that select at least two of these symbols can be simplified. For imx, omap2 and ux500 some rearrangements were necessary before the simplification. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de For the omap changes: Acked-by: Tony Lindgren t...@atomide.com -- 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
Re: [PATCH] ARM: drop explicit selection of HAVE_CLK and CLKDEV_LOOKUP
On 09/24, Uwe Kleine-K??nig wrote: CLKDEV_LOOKUP selects HAVE_CLK and COMMON_CLK selects CLKDEV_LOOKUP. So all symbols that select at least two of these symbols can be simplified. For imx, omap2 and ux500 some rearrangements were necessary before the simplification. Signed-off-by: Uwe Kleine-K??nig u.kleine-koe...@pengutronix.de For MSM: Acked-by: Stephen Boyd sb...@codeaurora.org -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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
Re: [PATCH] ARM: drop explicit selection of HAVE_CLK and CLKDEV_LOOKUP
On Tue, 2013-09-24 at 19:41 +0200, Uwe Kleine-König wrote: CLKDEV_LOOKUP selects HAVE_CLK and COMMON_CLK selects CLKDEV_LOOKUP. So all symbols that select at least two of these symbols can be simplified. For imx, omap2 and ux500 some rearrangements were necessary before the simplification. Signed-off-by: Uwe Kleine-Knig u.kleine-koe...@pengutronix.de --- For SOCFPGA: Acked-by: Dinh Nguyen dingu...@altera.com Thanks, Dinh -- 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
[PATCH v2 0/3] ARM: OMAP: convert N950/N9 to DT
Hi, This adds DTS for N950/N9 and removes the legacy board file. The following patches needs to be applied first: http://marc.info/?l=linux-omapm=137969869426861w=2 (the whole series) [PATCH 0/4] Clean up legacy platform data handling for omaps for v3.13 http://marc.info/?l=linux-omapm=137970770229676w=2 [PATCH] ARM: OMAP2: gpmc-onenand: fix sync mode setup with DT Change history: v2: Replace patch 1 HACK by using pdata-quirks v1: http://marc.info/?l=linux-omapm=137977135411888w=2 A. Aaro Koskinen (3): ARM: OMAP2: pdata-quirks: set internal clock source for MMC2 on N950/N9 ARM: dts: add minimal DT support for Nokia N950 N9 phones ARM: OMAP2: delete board-rm680 arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/omap3-n9.dts | 18 arch/arm/boot/dts/omap3-n950-n9.dtsi | 172 +++ arch/arm/boot/dts/omap3-n950.dts | 18 arch/arm/mach-omap2/Kconfig | 7 -- arch/arm/mach-omap2/Makefile | 1 - arch/arm/mach-omap2/board-rm680.c| 167 -- arch/arm/mach-omap2/pdata-quirks.c | 16 8 files changed, 226 insertions(+), 175 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-n9.dts create mode 100644 arch/arm/boot/dts/omap3-n950-n9.dtsi create mode 100644 arch/arm/boot/dts/omap3-n950.dts delete mode 100644 arch/arm/mach-omap2/board-rm680.c -- 1.8.4.rc3 -- 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
[PATCH v2 2/3] ARM: dts: add minimal DT support for Nokia N950 N9 phones
Add minimal DT support for Nokia N950 N9 phones. The same functionality
that is provided by the current board file should work: serial console,
USB, OneNAND and MMC.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/omap3-n9.dts | 18
arch/arm/boot/dts/omap3-n950-n9.dtsi | 172 +++
arch/arm/boot/dts/omap3-n950.dts | 18
4 files changed, 210 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-n9.dts
create mode 100644 arch/arm/boot/dts/omap3-n950-n9.dtsi
create mode 100644 arch/arm/boot/dts/omap3-n950.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e95af3f..3b611ba 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,6 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
+ omap3-n9.dtb \
+ omap3-n950.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
new file mode 100644
index 000..39828ce
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -0,0 +1,18 @@
+/*
+ * omap3-n9.dts - Device Tree file for Nokia N9
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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-n950-n9.dtsi
+
+/ {
+ model = Nokia N9;
+ compatible = nokia,omap3-n9, ti,omap3;
+};
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
new file mode 100644
index 000..56d6662
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -0,0 +1,172 @@
+/*
+ * omap3-n950-n9.dtsi - Device Tree file for Nokia N950 N9 (common stuff)
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include omap36xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+
+ vemmc: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = VEMMC;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ gpio = gpio5 29 0; /* gpio line 157 */
+ startup-delay-us = 150;
+ enable-active-high;
+ };
+};
+
+omap3_pmx_core {
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_cmd */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat0 */
+ 0x12e (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat1 */
+ 0x130 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat2 */
+ 0x132 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat3 */
+ ;
+ };
+};
+
+i2c1 {
+ clock-frequency = 290;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+twl {
+ compatible = ti,twl5031;
+};
+
+twl_gpio {
+ ti,pullups = 0x01; /* BIT(0) */
+ ti,pulldowns= 0x008106; /* BIT(1) | BIT(2) | BIT(8) | BIT(15) */
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ status = disabled;
+};
+
+mmc2 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc2_pins;
+ vmmc-supply = vemmc;
+ bus-width = 4;
+ ti,non-removable;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ mode = 3;
+ power = 50;
+};
+
+gpmc {
+ ranges = 0 0 0x0400 0x2000;
+
+ onenand@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0 0x2000;
+
+ gpmc,sync-read;
+ gpmc,sync-write;
+ gpmc,burst-length = 16;
+ gpmc,burst-read;
+ gpmc,burst-wrap;
+ gpmc,burst-write;
+ gpmc,device-width = 2;
+ gpmc,mux-add-data = 2;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 87;
+ gpmc,cs-wr-off-ns = 87;
+ gpmc,adv-on-ns
[PATCH v2 3/3] ARM: OMAP2: delete board-rm680
Delete board file for Nokia RM-680/RM-696 (N950/N9). DT-based booting
should be used for further development on this HW.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/mach-omap2/Kconfig | 7 --
arch/arm/mach-omap2/Makefile | 1 -
arch/arm/mach-omap2/board-rm680.c | 167 --
3 files changed, 175 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-rm680.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f6a1db1..6850bf9 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -310,13 +310,6 @@ config MACH_NOKIA_N8X0
select MACH_NOKIA_N810_WIMAX
select OMAP_PACKAGE_ZAC
-config MACH_NOKIA_RM680
- bool Nokia N950 (RM-680) / N9 (RM-696) phones
- depends on ARCH_OMAP3
- default y
- select MACH_NOKIA_RM696
- select OMAP_PACKAGE_CBB
-
config MACH_NOKIA_RX51
bool Nokia N900 (RX-51) phone
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f8d4a1b..1d2917b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -246,7 +246,6 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
-obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o sdram-nokia.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o sdram-nokia.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-peripherals.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-video.o
diff --git a/arch/arm/mach-omap2/board-rm680.c
b/arch/arm/mach-omap2/board-rm680.c
deleted file mode 100644
index 345e8c4..000
--- a/arch/arm/mach-omap2/board-rm680.c
+++ /dev/null
@@ -1,167 +0,0 @@
-/*
- * Board support file for Nokia N950 (RM-680) / N9 (RM-696).
- *
- * Copyright (C) 2010 Nokia
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/io.h
-#include linux/i2c.h
-#include linux/gpio.h
-#include linux/init.h
-#include linux/i2c/twl.h
-#include linux/platform_device.h
-#include linux/regulator/fixed.h
-#include linux/regulator/machine.h
-#include linux/regulator/consumer.h
-#include linux/platform_data/mtd-onenand-omap2.h
-#include linux/usb/phy.h
-
-#include asm/mach/arch.h
-#include asm/mach-types.h
-
-#include common.h
-#include mux.h
-#include gpmc.h
-#include mmc.h
-#include hsmmc.h
-#include sdram-nokia.h
-#include common-board-devices.h
-#include gpmc-onenand.h
-
-static struct regulator_consumer_supply rm680_vemmc_consumers[] = {
- REGULATOR_SUPPLY(vmmc, omap_hsmmc.1),
-};
-
-/* Fixed regulator for internal eMMC */
-static struct regulator_init_data rm680_vemmc = {
- .constraints = {
- .name = rm680_vemmc,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_STATUS
- | REGULATOR_CHANGE_MODE,
- },
- .num_consumer_supplies = ARRAY_SIZE(rm680_vemmc_consumers),
- .consumer_supplies = rm680_vemmc_consumers,
-};
-
-static struct fixed_voltage_config rm680_vemmc_config = {
- .supply_name= VEMMC,
- .microvolts = 290,
- .gpio = 157,
- .startup_delay = 150,
- .enable_high= 1,
- .init_data = rm680_vemmc,
-};
-
-static struct platform_device rm680_vemmc_device = {
- .name = reg-fixed-voltage,
- .dev= {
- .platform_data = rm680_vemmc_config,
- },
-};
-
-static struct platform_device *rm680_peripherals_devices[] __initdata = {
- rm680_vemmc_device,
-};
-
-/* TWL */
-static struct twl4030_gpio_platform_data rm680_gpio_data = {
- .pullups= BIT(0),
- .pulldowns = BIT(1) | BIT(2) | BIT(8) | BIT(15),
-};
-
-static struct twl4030_platform_data rm680_twl_data = {
- .gpio = rm680_gpio_data,
- /* add rest of the children here */
-};
-
-static void __init rm680_i2c_init(void)
-{
- omap3_pmic_get_config(rm680_twl_data, TWL_COMMON_PDATA_USB, 0);
- omap_pmic_init(1, 2900, twl5031, 7 + OMAP_INTC_START,
rm680_twl_data);
- omap_register_i2c_bus(2, 400, NULL, 0);
- omap_register_i2c_bus(3, 400, NULL, 0);
-}
-
-#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
- defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
-static struct omap_onenand_platform_data board_onenand_data[] = {
- {
- .gpio_irq = 65,
- .flags
[PATCH v2 1/3] ARM: OMAP2: pdata-quirks: set internal clock source for MMC2 on N950/N9
Set internal clock source for MMC2 on N950/N9.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/mach-omap2/pdata-quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 52b4bc3..1a7f492 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -16,6 +16,7 @@
#include common.h
#include common-board-devices.h
#include dss-common.h
+#include control.h
struct pdata_init {
const char *compatible;
@@ -62,6 +63,17 @@ static inline void omap_init_wl12xx_of(void)
}
#endif
+#ifdef CONFIG_ARCH_OMAP3
+static void __init hsmmc2_internal_input_clk(void)
+{
+ u32 reg;
+
+ reg = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
+ reg |= OMAP2_MMCSDIO2ADPCLKISEL;
+ omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
@@ -86,6 +98,10 @@ static void __init omap5_uevm_legacy_init(void)
#endif
static struct pdata_init pdata_quirks[] __initdata = {
+#ifdef CONFIG_ARCH_OMAP3
+ { nokia,omap3-n9, hsmmc2_internal_input_clk, },
+ { nokia,omap3-n950, hsmmc2_internal_input_clk, },
+#endif
#ifdef CONFIG_ARCH_OMAP4
{ ti,omap4-sdp, omap4_sdp_legacy_init, },
{ ti,omap4-panda, omap4_panda_legacy_init, },
--
1.8.4.rc3
--
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
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
On 09/23/2013 05:46 PM, Sebastian Reichel wrote: Hi, On Mon, Sep 23, 2013 at 02:35:35PM -0600, Stephen Warren wrote: On 09/15/2013 02:44 PM, Sebastian Reichel wrote: Add SSI device tree data for OMAP34xx and Nokia N900. ... +- ti,hwmods: Name of the hwmod associated to the controller, which + is ssi. I don't think we should add any more of that, for new bindings. That basically means not adding new drivers until hwmod is completly removed, since no new drivers not using DT are accepted anymore. hwmod still holds some information, which are not yet mapped to DT. Tony, is defining hwmod properties for new OMAP bindings what everyone is currently doing? I'm not sure how that will work with a stable DT ABI... I wonder if it makes sense not to define the ti,hwmods property in the binding document (so it doesn't become part of the ABI), but put it into the DTS file simply to make the current Linux code work? I'm not sure if that's any better though. +Required Port sub-node properties: +- compatible: Should be set to the following value + ti,omap3-ssi-port (applicable to OMAP34xx devices) Hmm. Is it really the case that there is 1 controller with n ports? Yes with n=2. Are the ports really dependent upon some shared resource? Yes and runtime power management. Couldn't the ports be represented as separate top-level SSI controllers? Maybe with some phandles. The current layout is cleaner IMHO. The ports are part of the controller and actually most boards only use one of them. In the original driver only the controller hat platform data with memory areas called port1_rx etc. If the HW block really does include 2 ports, then representing it as a single node in DT is fine; I was just making sure. +- interrupts: Contains the interrupt information for the port. +- interrupt-names: Contains the names of the interrupts. It's expected, +that mpu_irq0 and mpu_irq1 are provided. What exactly are those interrupts? MPU sounds like an external micro-controller/processor... +- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE +events for the port. This is an optional board-specific +property. If it's missing the port will not be +enabled. That also sounds like something that's a higher-level protocol, rather than whatever low-level transport SSI implements. Should this be part of a child node that represents the device attached to the SSI controller? Both the interrupts and the cawake-gpio are used as irqs for starting data transfers. As far as I understand it none of them are specific to the attached device. But are the interrupts and GPIO actually part of the HSI protocol itself, or something layered on top? While your particular board has them wired up, is it strictly necessary for all boards using HSI to have those IRQs/GPIOs? Does the SSI controller (or its ports) not need any clocks, resets, regulators, ...? The only other stuff needed is taken care of by hwmod, which can be seen in this patch: https://lkml.org/lkml/2013/9/15/97 It would be best to completely define the DT binding so that all required clocks etc. are already present in the DT. That way, the DT ABI won't change once people stop using hwmods. Tony, is that possible on OMAP at present, irrespective of whether those e.g. clock properties will actually be used by Linux? -- 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
DSS display-new custom enable/disable hooks
Hi, we're using connector-analog-tv driver to enable TV out on gta04 board. There is exception that we need to change some twl registers + some gpio when enable/disable TV output. My question is if there is some way how to do that or do we need to copy'n'paste code from connector-analog-tv driver and extend it for handling we need (let's call it hack)? Thanks, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- 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
Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information
* Stephen Warren swar...@wwwdotorg.org [130924 13:03]: On 09/23/2013 05:46 PM, Sebastian Reichel wrote: Hi, On Mon, Sep 23, 2013 at 02:35:35PM -0600, Stephen Warren wrote: On 09/15/2013 02:44 PM, Sebastian Reichel wrote: Add SSI device tree data for OMAP34xx and Nokia N900. ... +- ti,hwmods: Name of the hwmod associated to the controller, which + is ssi. I don't think we should add any more of that, for new bindings. That basically means not adding new drivers until hwmod is completly removed, since no new drivers not using DT are accepted anymore. hwmod still holds some information, which are not yet mapped to DT. Tony, is defining hwmod properties for new OMAP bindings what everyone is currently doing? I'm not sure how that will work with a stable DT ABI... I wonder if it makes sense not to define the ti,hwmods property in the binding document (so it doesn't become part of the ABI), but put it into the DTS file simply to make the current Linux code work? I'm not sure if that's any better though. There are still pieces of information in hwmod that is needed for PM to work for things like device autoidle and reset. The plan is to describe those with Linux generic bindings, but that's going to take a while. Clearly once we have those bindings, ti,hwmods is not needed and then the problem is how to support old .dtb files.. It would be best to completely define the DT binding so that all required clocks etc. are already present in the DT. That way, the DT ABI won't change once people stop using hwmods. Tony, is that possible on OMAP at present, irrespective of whether those e.g. clock properties will actually be used by Linux? Unfortunately not doable yet. For v3.13 we should have the clock bindings in place, but quite a bit of work still remains for the remaining hwmod pieces. Considering all this, we may be best off dropping ti,hwmods binding completely, and populate it based on DT auxdata or something similar. That means that old .dtb files won't work once we populate things from DT, but at least the binding issue would be sorted out. If anybody has better suggestions, let me know. Regards, Tony -- 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
Booting recent mainline on omap5-uevm
Hi, I have an OMAP5432 uEVM which I cannot get to boot with recent mainline (tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board (v6.0.0.7), which comes with 3.8.4 which works fine. I found this thread: http://marc.info/?l=fedora-armm=137717811815777 and tried using git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git and merging in for_3.11/out_of_tree/omap5_clk_data from ssantosh's tree as described, but with no luck. In all cases the boot hangs after the Starting kernel ... message. I enabled the low-level debugging options in the kernel but got no further messages. I'm using u-boot_2013.01.1.1 from the GLSDK, is that OK or do I need a more recent version? Is there a FAQ or wiki or something that describes what I need to do? Thanks, -- Paul -- 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
RE: Booting recent mainline on omap5-uevm
From: Paul Zimmerman Sent: Tuesday, September 24, 2013 1:21 PM Hi, I have an OMAP5432 uEVM which I cannot get to boot with recent mainline (tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board (v6.0.0.7), which comes with 3.8.4 which works fine. I found this thread: http://marc.info/?l=fedora-armm=137717811815777 and Wrong link, should have been http://marc.info/?l=linux-omapm=137515583214350. tried using git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git and merging in for_3.11/out_of_tree/omap5_clk_data from ssantosh's tree as described, but with no luck. In all cases the boot hangs after the Starting kernel ... message. I enabled the low-level debugging options in the kernel but got no further messages. I'm using u-boot_2013.01.1.1 from the GLSDK, is that OK or do I need a more recent version? Is there a FAQ or wiki or something that describes what I need to do? Thanks, -- Paul -- 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
Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger
Hi, On Tue, Sep 24, 2013 at 07:05:47PM +0200, Pali Rohár wrote: No, isp1704 driver is doing fastcharger detection (and then export charger type via sysfs power supply) based on musb usb events. Real charging (enabling/disabling and setting properties) is done by bq24150a chip which has own power driver bq2415x_charger. As already wrote this is not simple and this is reason why I sent board data and functions only now... Yes, I'm aware of this. Technically the isp1704 does not provide the 5 volt line, but for the system as a whole that fact does not really matter. The isp1704 can provide its functionality via the regulator API as a simple regulator device. It provides information about the power it can supply. The bq24150a on the other hand can just use the regulator via the consumer interface. The regulator framework provides capabilities for events: Regulators can notify consumers of external events -- Sebastian signature.asc Description: Digital signature
Re: new binutils needed for arm in 3.12-rc1
On 09/24/2013 07:11:38 AM, Måns Rullgård wrote: Rob Landley r...@landley.net writes: On 09/23/2013 06:59:17 PM, Pavel Machek wrote: During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. Um, my toolchain is using the last gplv2 snapshot of binutils out of git, which is just past 2.17 and can build armv7 (but not armv8). Binutils 2.12-2.22 is quite the jump. (11 years.) I'd except some thought to have gone into that? Possibly a mention of it? I seriously doubt that 2.12 still works at all (I doubt it can even be built on a modern system). In my experience, binutils older than 2.19 or so rarely works properly for ARM. I've been building every kernel release with 2.17 for several years, on a bunch of different architectures. Toolchain releases after that are GPLv3* and I can't distribute those binaries, so I can't ship prebuilt binary toolchains. (Lots of other people produce cross compilers, but nobody else seems to produce prebuilt statically linked _native_ compilers. It would be nice if they did.) What value is there in maintaining compatibility with a truly ancient binutils version anyway? What value is there in requiring the new toolchain? From what I could see of the commits it was micro-optimizations around memory barriers. *shrug* I can revert the patch locally, or patch the extra instruction into my toolchain. But I do object to changing the documentation globally for every architecture because one architecture did something they apparently never thought through (or they'd have commented in the commit that it requires a big toolchain version jump; pretty sure they didn't actually notice). Rob * The Free Software Foundation got so pissed that MacOS X and BSD and such were sticking with the last GPLv2 release of binutils that they deleted the binutils tarball off their website and replaced it with one including GPLv3 source code. Check the FTP site if you don't believe me. Some of us have it snapshotted though. In my case, I actually fished the last GPLv2 version out of source control, right before the license change was committed, because I wanted armv7 support.-- 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
Re: new binutils needed for arm in 3.12-rc1
On Tue, Sep 24, 2013 at 04:23:48PM -0500, Rob Landley wrote: What value is there in requiring the new toolchain? From what I could see of the commits it was micro-optimizations around memory barriers. *shrug* I can revert the patch locally, or patch the extra instruction into my toolchain. But I do object to changing the documentation globally for every architecture because one architecture did something they apparently never thought through (or they'd have commented in the commit that it requires a big toolchain version jump; pretty sure they didn't actually notice). Some of us are notoriously slow at updating our toolchains. I'm still using gcc 4.5.4 here, and people regard that as bordering on too old because of the amount of warnings it spits out. Binutils? I upgraded to 2.22 when I needed to fix a problem I was having with the previous binutils I was using (I think that was 2.18). I generally don't touch my toolchain unless there's a _reason_ I need to, and as I've already updated to 2.22, it's a normally a pretty safe bet that everyone else is already using 2.22 or later. One reason for this is that I don't want to be messing around trying to work out whether a bug I'm seeing is because of a toolchain problem or something in the kernel. I realised at the time that I'm going to got shouted at if I accepted the patches by a minority who wanted to keep their old toolchains, but I also realise that if I don't accept the patches, I'll get shouted at by another group. It's the classic damned if I do and damned if I don't. So I've chosen the lesser of the two weavels. Now, if you feel strongly about this, we _could_ introduce a CONFIG_OLD_BINUTILS and give everyone their cake - but it will be fragile. Not everyone will remember to get that right, because they'll be using the later binutils. Also, we already have an excessive number of potential breakage-inducing options and we certainly don't need another. Use IS_ENABLED() I hear you say. That won't get the one dsb instruction in some SoC code which was missed which will break the build on older toolchains. -- 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
Re: Booting recent mainline on omap5-uevm
On Tuesday 24 September 2013 04:30 PM, Paul Zimmerman wrote:
From: Paul Zimmerman
Sent: Tuesday, September 24, 2013 1:21 PM
Hi,
I have an OMAP5432 uEVM which I cannot get to boot with recent mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board (v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread: http://marc.info/?l=fedora-armm=137717811815777 and
Wrong link, should have been http://marc.info/?l=linux-omapm=137515583214350.
Its because of commit 03ab349ec{ARM: OMAP5: hwmod data: Add mailbox data} which
added hwmod data but DT data for mailbox is missing. Reverting that makes
things work. Looks like mailbox dt patches missed the last merge window.
The booting branch is pushed here [1] just in case you need it.
regards,
Santosh
[1]
https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=3.12/omap5
--
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
Re: Booting recent mainline on omap5-uevm
On 09/24/2013 05:24 PM, Santosh Shilimkar wrote:
On Tuesday 24 September 2013 04:30 PM, Paul Zimmerman wrote:
From: Paul Zimmerman
Sent: Tuesday, September 24, 2013 1:21 PM
Hi,
I have an OMAP5432 uEVM which I cannot get to boot with recent mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board (v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread: http://marc.info/?l=fedora-armm=137717811815777 and
Wrong link, should have been
http://marc.info/?l=linux-omapm=137515583214350.
Its because of commit 03ab349ec{ARM: OMAP5: hwmod data: Add mailbox data}
which
added hwmod data but DT data for mailbox is missing. Reverting that makes
things work. Looks like mailbox dt patches missed the last merge window.
Yeah, the boot sequence tries to enable and idle all the hwmods, and
this results in an error while initializing the mailbox hwmod during the
sysc configuration. This is because the OMAP5 hwmod data file no longer
has the omap_hwmod_addr_space defined in the hwmod_ocp_if data. Two ways
for now to get past is either revert the mailbox hwmod commit as above
or add the DT node [2].
I will be respinning the mailbox DT series very soon targeting 3.13, so
should not be an issue when OMAP5 boot is supported directly on mainline.
regards
Suman
The booting branch is pushed here [1] just in case you need it.
regards,
Santosh
[1]
https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=3.12/omap5
[2] http://marc.info/?l=linux-omapm=137582564017990w=2
--
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
Re: Booting recent mainline on omap5-uevm
On Tuesday 24 September 2013 07:48 PM, Suman Anna wrote:
On 09/24/2013 05:24 PM, Santosh Shilimkar wrote:
On Tuesday 24 September 2013 04:30 PM, Paul Zimmerman wrote:
From: Paul Zimmerman
Sent: Tuesday, September 24, 2013 1:21 PM
Hi,
I have an OMAP5432 uEVM which I cannot get to boot with recent mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board (v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread: http://marc.info/?l=fedora-armm=137717811815777 and
Wrong link, should have been
http://marc.info/?l=linux-omapm=137515583214350.
Its because of commit 03ab349ec{ARM: OMAP5: hwmod data: Add mailbox data}
which
added hwmod data but DT data for mailbox is missing. Reverting that makes
things work. Looks like mailbox dt patches missed the last merge window.
Yeah, the boot sequence tries to enable and idle all the hwmods, and
this results in an error while initializing the mailbox hwmod during the
sysc configuration. This is because the OMAP5 hwmod data file no longer
has the omap_hwmod_addr_space defined in the hwmod_ocp_if data. Two ways
for now to get past is either revert the mailbox hwmod commit as above
or add the DT node [2].
Would be good if you can get the mailbox dt node in rc cycles. But since
CCF is still missing if if that doesn't happen in rc's thats ok.
I will be respinning the mailbox DT series very soon targeting 3.13, so
should not be an issue when OMAP5 boot is supported directly on mainline.
Thanks
Regards,
Santosh
--
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
RE: Booting recent mainline on omap5-uevm
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Tuesday, September 24, 2013 4:48 PM
On 09/24/2013 05:24 PM, Santosh Shilimkar wrote:
On Tuesday 24 September 2013 04:30 PM, Paul Zimmerman wrote:
From: Paul Zimmerman
Sent: Tuesday, September 24, 2013 1:21 PM
Hi,
I have an OMAP5432 uEVM which I cannot get to boot with recent mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board (v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread: http://marc.info/?l=fedora-armm=137717811815777 and
Wrong link, should have been
http://marc.info/?l=linux-omapm=137515583214350.
Its because of commit 03ab349ec{ARM: OMAP5: hwmod data: Add mailbox data}
which
added hwmod data but DT data for mailbox is missing. Reverting that makes
things work. Looks like mailbox dt patches missed the last merge window.
Yeah, the boot sequence tries to enable and idle all the hwmods, and
this results in an error while initializing the mailbox hwmod during the
sysc configuration. This is because the OMAP5 hwmod data file no longer
has the omap_hwmod_addr_space defined in the hwmod_ocp_if data. Two ways
for now to get past is either revert the mailbox hwmod commit as above
or add the DT node [2].
I will be respinning the mailbox DT series very soon targeting 3.13, so
should not be an issue when OMAP5 boot is supported directly on mainline.
That's good info, but unfortunately it didn't work for me. I must have a
different problem, maybe I need a newer version of u-boot.
So there is no README or wiki that explains how to get Linux to boot on
this board? Is there perhaps a prebuilt SD card image somewhere with a
recent kernel that I can grab?
--
Paul
--
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
[PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
The GPIO OMAP controller pins can be used as IRQ and GPIO
independently so is necessary to keep track GPIO pins and
IRQ lines usage separately to make sure that the bank will
always be enabled while being used.
Also move gpio_is_input() definition in preparation for the
next patch that setups the controller's irq_chip driver when
a caller requests an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0ff4355..a4fe038 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -63,6 +63,7 @@ struct gpio_bank {
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
+ u32 irq_usage;
u32 dbck_enable_mask;
bool dbck_enabled;
struct device *dev;
@@ -86,6 +87,9 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
+#define LINE_USED(line, offset) (line (1 offset))
+
static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
return bank-chip.base + gpio_irq;
@@ -420,6 +424,13 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static int gpio_is_input(struct gpio_bank *bank, int mask)
+{
+ void __iomem *reg = bank-base + bank-regs-direction;
+
+ return __raw_readl(reg) mask;
+}
+
static int gpio_irq_type(struct irq_data *d, unsigned type)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
@@ -427,7 +438,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
int retval;
unsigned long flags;
- if (WARN_ON(!bank-mod_usage))
+ if (WARN_ON(!BANK_USED(bank)))
return -EINVAL;
#ifdef CONFIG_ARCH_OMAP1
@@ -447,6 +458,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
spin_lock_irqsave(bank-lock, flags);
retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
+ bank-irq_usage |= 1 GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
if (type (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
@@ -603,7 +615,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
* If this is the first gpio_request for the bank,
* enable the bank module.
*/
- if (!bank-mod_usage)
+ if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
spin_lock_irqsave(bank-lock, flags);
@@ -619,7 +631,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
__raw_writel(__raw_readl(reg) | (1 offset), reg);
}
- if (bank-regs-ctrl !bank-mod_usage) {
+ if (bank-regs-ctrl !BANK_USED(bank)) {
void __iomem *reg = bank-base + bank-regs-ctrl;
u32 ctrl;
@@ -654,7 +666,7 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned
offset)
bank-mod_usage = ~(1 offset);
- if (bank-regs-ctrl !bank-mod_usage) {
+ if (bank-regs-ctrl !BANK_USED(bank)) {
void __iomem *reg = bank-base + bank-regs-ctrl;
u32 ctrl;
@@ -672,7 +684,7 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned
offset)
* If this is the last gpio to be freed in the bank,
* disable the bank module.
*/
- if (!bank-mod_usage)
+ if (!BANK_USED(bank))
pm_runtime_put(bank-dev);
}
@@ -762,8 +774,10 @@ static void gpio_irq_shutdown(struct irq_data *d)
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
unsigned int gpio = irq_to_gpio(bank, d-hwirq);
unsigned long flags;
+ unsigned offset = GPIO_INDEX(bank, gpio);
spin_lock_irqsave(bank-lock, flags);
+ bank-irq_usage = ~(1 offset);
_reset_gpio(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
}
@@ -897,13 +911,6 @@ static int gpio_input(struct gpio_chip *chip, unsigned
offset)
return 0;
}
-static int gpio_is_input(struct gpio_bank *bank, int mask)
-{
- void __iomem *reg = bank-base + bank-regs-direction;
-
- return __raw_readl(reg) mask;
-}
-
static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank;
@@ -1400,7 +1407,7 @@ void omap2_gpio_prepare_for_idle(int pwr_mode)
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
- if (!bank-mod_usage || !bank-loses_context)
+ if (!BANK_USED(bank) || !bank-loses_context)
continue;
bank-power_mode = pwr_mode;
@@ -1414,7 +1421,7 @@ void omap2_gpio_resume_after_idle(void)
struct gpio_bank *bank;
[PATCH 2/2] gpio/omap: auto-setup a GPIO when used as an IRQ
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
driver won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 129 ++-
1 file changed, 83 insertions(+), 46 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a4fe038..89675f8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -424,6 +424,52 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ if (bank-regs-pinctrl) {
+ void __iomem *reg = bank-base + bank-regs-pinctrl;
+
+ /* Claim the pin for MPU */
+ __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is enabled, clocks are not gated */
+ ctrl = ~GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
+static void _disable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ void __iomem *base = bank-base;
+
+ if (bank-regs-wkup_en
+ !LINE_USED(bank-mod_usage, offset)
+ !LINE_USED(bank-irq_usage, offset)) {
+ /* Disable wake-up during idle for dynamic tick */
+ _gpio_rmw(base, bank-regs-wkup_en, 1 offset, 0);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is disabled, clocks are gated */
+ ctrl |= GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
static int gpio_is_input(struct gpio_bank *bank, int mask)
{
void __iomem *reg = bank-base + bank-regs-direction;
@@ -437,9 +483,10 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
unsigned gpio = 0;
int retval;
unsigned long flags;
+ unsigned offset;
- if (WARN_ON(!BANK_USED(bank)))
- return -EINVAL;
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
if (d-irq IH_MPUIO_BASE)
@@ -457,7 +504,16 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
return -EINVAL;
spin_lock_irqsave(bank-lock, flags);
- retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
+ offset = GPIO_INDEX(bank, gpio);
+ retval = _set_gpio_triggering(bank, offset, type);
+ if (!LINE_USED(bank-mod_usage, offset)) {
+ _enable_gpio_module(bank, offset);
+ _set_gpio_direction(bank, offset, 1);
+ } else if (!gpio_is_input(bank, 1 offset)) {
+ spin_unlock_irqrestore(bank-lock, flags);
+ return -EINVAL;
+ }
+
bank-irq_usage |= 1 GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
@@ -620,30 +676,14 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(bank-lock, flags);
/* Set trigger to none. You need to enable the desired trigger with
-* request_irq() or set_irq_type().
+* request_irq() or set_irq_type(). Only do this if the IRQ line has
+* not already been requested.
*/
- _set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
-
- if (bank-regs-pinctrl) {
- void __iomem *reg = bank-base + bank-regs-pinctrl;
-
- /* Claim the pin for MPU */
- __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ if (!LINE_USED(bank-irq_usage, offset)) {
+ _set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ _enable_gpio_module(bank, offset);
}
-
- if
[PATCH 2/2] gpio/omap: auto-setup a GPIO when used as an IRQ
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
driver won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 129 ++-
1 file changed, 83 insertions(+), 46 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a4fe038..89675f8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -424,6 +424,52 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0;
}
+static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ if (bank-regs-pinctrl) {
+ void __iomem *reg = bank-base + bank-regs-pinctrl;
+
+ /* Claim the pin for MPU */
+ __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is enabled, clocks are not gated */
+ ctrl = ~GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
+static void _disable_gpio_module(struct gpio_bank *bank, unsigned offset)
+{
+ void __iomem *base = bank-base;
+
+ if (bank-regs-wkup_en
+ !LINE_USED(bank-mod_usage, offset)
+ !LINE_USED(bank-irq_usage, offset)) {
+ /* Disable wake-up during idle for dynamic tick */
+ _gpio_rmw(base, bank-regs-wkup_en, 1 offset, 0);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ }
+
+ if (bank-regs-ctrl !BANK_USED(bank)) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is disabled, clocks are gated */
+ ctrl |= GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
+ }
+}
+
static int gpio_is_input(struct gpio_bank *bank, int mask)
{
void __iomem *reg = bank-base + bank-regs-direction;
@@ -437,9 +483,10 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
unsigned gpio = 0;
int retval;
unsigned long flags;
+ unsigned offset;
- if (WARN_ON(!BANK_USED(bank)))
- return -EINVAL;
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
if (d-irq IH_MPUIO_BASE)
@@ -457,7 +504,16 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
return -EINVAL;
spin_lock_irqsave(bank-lock, flags);
- retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
+ offset = GPIO_INDEX(bank, gpio);
+ retval = _set_gpio_triggering(bank, offset, type);
+ if (!LINE_USED(bank-mod_usage, offset)) {
+ _enable_gpio_module(bank, offset);
+ _set_gpio_direction(bank, offset, 1);
+ } else if (!gpio_is_input(bank, 1 offset)) {
+ spin_unlock_irqrestore(bank-lock, flags);
+ return -EINVAL;
+ }
+
bank-irq_usage |= 1 GPIO_INDEX(bank, gpio);
spin_unlock_irqrestore(bank-lock, flags);
@@ -620,30 +676,14 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(bank-lock, flags);
/* Set trigger to none. You need to enable the desired trigger with
-* request_irq() or set_irq_type().
+* request_irq() or set_irq_type(). Only do this if the IRQ line has
+* not already been requested.
*/
- _set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
-
- if (bank-regs-pinctrl) {
- void __iomem *reg = bank-base + bank-regs-pinctrl;
-
- /* Claim the pin for MPU */
- __raw_writel(__raw_readl(reg) | (1 offset), reg);
+ if (!LINE_USED(bank-irq_usage, offset)) {
+ _set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ _enable_gpio_module(bank, offset);
}
-
- if
Re: new binutils needed for arm in 3.12-rc1
On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote: On Tue, Sep 24, 2013 at 04:23:48PM -0500, Rob Landley wrote: What value is there in requiring the new toolchain? From what I could see of the commits it was micro-optimizations around memory barriers. *shrug* I can revert the patch locally, or patch the extra instruction into my toolchain. But I do object to changing the documentation globally for every architecture because one architecture did something they apparently never thought through (or they'd have commented in the commit that it requires a big toolchain version jump; pretty sure they didn't actually notice). Some of us are notoriously slow at updating our toolchains. ... Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM or some such provides a complete solution. Now, if you feel strongly about this, we _could_ introduce a CONFIG_OLD_BINUTILS and give everyone their cake - but it will be fragile. Not everyone will remember to get that right, because they'll be using the later binutils. Also, we already have an excessive number of potential breakage-inducing options and we certainly don't need another. I'm doing the regression testing either way, on several different architectures. (Although I tend to to only really do a thorough job quarterly when a new kernel comes out and it's time to make it work.) So I'm going to be doing something locally like this anyway, and if a CONFIG_OLD_BINUTILS is acceptable I might as well push it upstream. My use case is running all these targets under qemu, so it's not exactly performance-critical. :) Use IS_ENABLED() I hear you say. That won't get the one dsb instruction in some SoC code which was missed which will break the build on older toolchains. My regression test is my http://landley.net/aboriginal/about.html project, where I: 1) build cross compilers for ~15 different architecture variants (maybe half unique, the rest variants of the others). 2) Use them to build the smallest native development environment capable of reproducing itself from soruce code. 3) Boot it under qemu. 4) Build linux from scratch under the result. I've sometimes had it the whole mess automated from a cron job, but the server I had it on blew out its hard drive controller and I haven't bothered to set it up again... Next couple days are crazy but I'll try to get you a patch this weekend. Thanks, Rob-- 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
OMAP baseline test results for v3.12-rc2
Here are some basic OMAP test results for Linux v3.12-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.12-rc2/20130924152551/ Test summary Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Boot to userspace: skip ( 1/ 1): 5912osk Pass (11/11): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 3/ 5): 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 5): 3530es3beagle, 37xxevm PM: chip off via dynamic idle: FAIL ( 3/ 5): 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 5): 3530es3beagle, 37xxevm vmlinux object size (delta in bytes from test_v3.12-rc1 (272b98c6455f00884f0350f775c5342358ebb73f)): text data bsstotal kernel +784 -80 +776 omap1_defconfig +816 +240 +840 omap1_defconfig_1510innovator_only +75200 +752 omap1_defconfig_5912osk_only +708 -160 +692 omap2plus_defconfig +916 -160 +900 omap2plus_defconfig_2430sdp_only +780 +160 +796 omap2plus_defconfig_cpupm +236 -80 +228 omap2plus_defconfig_n800_multi_omap2xxx +236 -80 +228 omap2plus_defconfig_n800_only_a +708 -160 +692 omap2plus_defconfig_no_pm +708 -160 +692 omap2plus_defconfig_omap2_4_only +772 -160 +756 omap2plus_defconfig_omap3_4_only +6320 -264 +368 rmk_omap3430_ldp_allnoconfig +54400 +544 rmk_omap3430_ldp_oldconfig +6800 -280 +400 rmk_omap4430_sdp_allnoconfig Boot-time memory difference (delta in bytes from test_v3.12-rc1 (272b98c6455f00884f0350f775c5342358ebb73f)) avail rsrvd high freed board kconfig (no differences) -- 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
Re: new binutils needed for arm in 3.12-rc1
On Tue, 24 Sep 2013, Rob Landley wrote: On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote: Now, if you feel strongly about this, we _could_ introduce a CONFIG_OLD_BINUTILS and give everyone their cake - but it will be fragile. Not everyone will remember to get that right, because they'll be using the later binutils. Also, we already have an excessive number of potential breakage-inducing options and we certainly don't need another. I'm doing the regression testing either way, on several different architectures. (Although I tend to to only really do a thorough job quarterly when a new kernel comes out and it's time to make it work.) So I'm going to be doing something locally like this anyway, and if a CONFIG_OLD_BINUTILS is acceptable I might as well push it upstream. If you are convinced you have no choice but to stick to old binutils, I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. This is more in line with being future proof rather than stuck into the past. It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. Nicolas -- 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
Re: [PATCH 00/10] pwm-backlight: Add GPIO and power supply support
On Tue, Sep 24, 2013 at 11:00:24AM +0200, Thierry Reding wrote: On Tue, Sep 24, 2013 at 05:14:46PM +0900, Simon Horman wrote: [ Cc: Olof Johansson, Kevin Hilman and Arnd Bergman: arm-soc maintainers ] On Mon, Sep 23, 2013 at 11:40:57PM +0200, Thierry Reding wrote: This series adds the ability to specify a GPIO and a power supply to enable a backlight. Patch 1 refactors the power on and power off sequences into separate functions in preparation for subsequent patches. Patch 2 adds an optional GPIO to enable a backlight. This patch only includes the field within the platform data so that it can be properly setup before actually being put to use. Patches 3 to 7 convert all users of the pwm-backlight driver to use the new field. For most of them, this just initializes the field to -1, marking the field as unused. Patch 8 uses the new field within the pwm-backlight driver and at the same time allows it to be parsed from device tree. Patch 9 implements support for an optional power supply. This relies on the regulator core to return a dummy regulator when no supply has been otherwise setup so the driver doesn't have to handle that specially nor require all users to be updated. Patch 10 adds a way to keep a backlight turned off at boot. This is useful when hooking up a backlight with a subsystem such as DRM which has more explicit semantics as to when a backlight should be turned on. Due to the dependencies within the series, I propose to take all these patches through the PWM tree, so I'll need acks from OMAP, PXA, Samsung, shmobile and Unicore32 maintainers. I received some feedback regarding shmobile conflicts when arm-soc was merged between v3.11 and v3.12-rc1. With this in mind I now have a strong preference for changes inside arch/arm/mach-shmobile/ to be taken through my renesas tree and thus more importantly through arm-soc if possible. I understand. Unfortunately the nature of patche series such as this is that they require the whole series to be applied atomically (or at least in a very specific order). So the patch that uses the new enable_gpio field can only be applied after all previous patches. The only reasonable way to ensure that is to take all of the patches through one tree. Furthermore this patch is tiny (it adds a single line) and touches code that's unlikely to be modified by anyone else. But if it makes you more comfortable, I could provide a stable branch that contains this series for you to merge into the shmobile tree. That should enable you to handle all conflict resolution prior to submitting to arm-soc. After some further thought I have reasoned that: 1. It is only a one line change on the shmobile side 2. It is to a file that is not seeing much chainge and in a block of code that is seeing even less change. And thus the chance of a conflict is small. With this in mind I will ack the shmobile patch. -- 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
Re: [PATCH 06/10] ARM: shmobile: Initialize PWM backlight enable_gpio field
On Mon, Sep 23, 2013 at 11:41:03PM +0200, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 7f8f607..6ccb854 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -423,6 +423,7 @@ static struct platform_pwm_backlight_data
pwm_backlight_data = {
.max_brightness = 255,
.dft_brightness = 255,
.pwm_period_ns = 3, /* 30kHz */
+ .enable_gpio = -1,
};
static struct platform_device pwm_backlight_device = {
Acked-by: Simon Horman horms+rene...@verge.net.au
--
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
