Re: [PATCH 2/2] ARM: OMAP2+: clocks: Pass static parent pointers to common clock core
On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote: > * Rajendra Nayak [130315 05:31]: >> On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote: >>> * Rajendra Nayak [130314 05:44]: OMAP clock inits happen quite early, even before the slab is available. As part of the clock init, the common clock core tries to cache parent pointers (if not passed by the caller registering the clock) which fails in case of OMAP since the slab isn't initied. Without CONFIG_DEBUG_SLAB enabled, this just results in the common clock core retrying the caching attempt at some point later. However with CONFIG_DEBUG_SLAB enabled this results in a BUG() as reported in the link below by Tony.. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html Fix this by passing static parent pointers to the common clock core while registering clocks. >>> >>> I wonder if we could easily fix this by initializing only some of the >>> clocks that early? >> >> We actually don't need any clocks that early (I mean even before slab init) >> We only need them before timer init. > > Yes and only the timer clocks at that point. The others could be initialized > later on so we get console error messages without having to turn on DEBUG_LL > and earlyprintk. but that wouldn't be possible with the hwmod dependency on clocks. We would need to move the hwmod inits further down too. > >> This isn't something specific to OMAP so I started looking at what others >> in drivers/clk seem to do. >> >> I found imx, spear, mvebu all do their clk inits within .init_time callbacks. >> tegra seems to even do it within .init_irq callback. >> >> Either one would work for us too :) > > Well I suggest init_irq as that's when we need the first clocks for timer. For which platforms? I instead see them being needed only by init_timer, so was thinking thats a better place instead. For the -rc fix to fix the crash with DEBUG_SLAB, is it fine if I move *all* clock inits down to init_timer (or init_irq). Splitting clocks alone would not work for now, without hwmod being moved down also. > > 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
[PATCH] mmc: omap_hsmmc: Prevent potential NULL dereference
of_get_hsmmc_pdata() may return NULL, thus ensure pdata is not NULL
before dereference it.
Signed-off-by: Axel Lin
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc58078..a8f9717 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1774,7 +1774,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
if (match) {
pdata = of_get_hsmmc_pdata(&pdev->dev);
- if (match->data) {
+ if (pdata && match->data) {
const u16 *offsetp = match->data;
pdata->reg_offset = *offsetp;
}
--
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
[GIT PULL v2] ARM: omap2: twl-common update
Hi Tony, I have rebased the branch on 3.9-rc3 tag. Is it still possible to send this for 3.9? Regards, Péter --- The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://gitorious.org/omap-audio/linux-audio.git peter/upstream/for-tony for you to fetch changes up to 282f21df32df9a01c66d68e7009150ffc69e4e0c: omap2: twl-common: Add default power configuration (2013-03-18 11:08:12 +0100) Matthias Brugger (1): omap2: twl-common: Add default power configuration arch/arm/mach-omap2/twl-common.c | 38 ++ arch/arm/mach-omap2/twl-common.h | 1 + 2 files changed, 39 insertions(+) -- 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 0/8] ARM: dts: Various OMAP2+ device-tree updates
Hi Anil, On 03/17/2013 10:35 AM, Anil Kumar wrote: > Hi Benoit, > > On Fri, Mar 15, 2013 at 8:00 PM, Benoit Cousson wrote: >> Hi Jon, >> >> On 03/15/2013 02:57 PM, Jon Hunter wrote: >>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. >>> >>> The DMA, PMU and OMAP3430 SDP board changes have been sent before >>> individually but re-sending here as a complete series for v3.10. >>> >>> This is based upon Benoit's for_3.10/dts branch [1]. Branch available >>> here [2]. >>> >>> V2 changes: >>> - Rebased on Benoit's for_3.10/dts branch >>> - Squashed patches adding support for OMAP3430 SDP board and patch >>> to add flash support for OMAP3430 SDP board. >>> >>> [1] >>> http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts >>> [2] git://github.com/jonhunter/linux.git omap-dt-for-v3.10 >> >> Thanks for the repost. I've just applied your branch in my for_3.10/dts >> branch. > > I think you missed below patch which is needed for gpmc nand to work fine. > Without this patch nand will not work on OMAP3430 SDP board. > > Jon Hunter:- > ARM: OMAP2+: Fix-up gpmc merge error Well, that patch is not part of Jon's series and it looks like it was posted for 3.9-rc3. BTW, Paul W is just reporting a regression about that patch. Anyway, I'll rebase on top of -rc3 to get the latest fixes. 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
[PATCH 0/2] omap serial fix.
The first patch is a rearrangement of a macro "OMAP_MAX_HSUART_PORTS" to a header file so that it can be used in other file. The second patch fixes the wakeup from uart issue while using "no_console_suspend" in the bootargs. These patches are developed on 3.8 custom kernel containing omap5 supend/resume support. Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Sourav Poddar (2): driver: serial-omap: move max uart count into generic header file. arm: mach-omap2: prevent UART console idle on suspend while using "no_console_suspend" arch/arm/mach-omap2/omap_device.c | 36 - drivers/tty/serial/omap-serial.c |2 - include/linux/platform_data/serial-omap.h |1 + 3 files changed, 36 insertions(+), 3 deletions(-) -- 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] driver: serial-omap: move max uart count into generic header file.
OMAP_MAX_HSUART_PORTS is moved to omap_serial header file.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
---
drivers/tty/serial/omap-serial.c |2 --
include/linux/platform_data/serial-omap.h |1 +
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 5722eaf..4c2ba9f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,8 +43,6 @@
#include
#include
-#define OMAP_MAX_HSUART_PORTS 6
-
#define UART_BUILD_REVISION(x, y) (((x) << 8) | (y))
#define OMAP_UART_REV_42 0x0402
diff --git a/include/linux/platform_data/serial-omap.h
b/include/linux/platform_data/serial-omap.h
index ff9b0aa..92c48c2 100644
--- a/include/linux/platform_data/serial-omap.h
+++ b/include/linux/platform_data/serial-omap.h
@@ -29,6 +29,7 @@
* is used as console uart.
*/
#define OMAP_SERIAL_NAME "ttyO"
+#define OMAP_MAX_HSUART_PORTS 6
struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
--
1.7.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 2/2] arm: mach-omap2: prevent UART console idle on suspend while using "no_console_suspend"
With dt boot on omap5, uart wakeup after suspend is non functional while using
"no_console_suspend" in the bootargs. With "no_console_suspend" used, od->flags
should be ORed with "OMAP_DEVICE_NO_IDLE_ON_SUSPEND", thereby not allowing the
console
to idle in the suspend path. For non-dt case, this was taken care by platform
data.
Tested on omap5430evm, omap4430sdp.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
---
arch/arm/mach-omap2/omap_device.c | 35 ++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index e065daa..ed3404c 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -88,6 +88,7 @@
#include
#include
#include
+#include
#include "omap_device.h"
#include "omap_hwmod.h"
@@ -96,6 +97,11 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT 1
+#define MAX_UART_HWMOD_NAME_LEN 16
+
+static u8 no_console_suspend;
+static u8 console_uart_num;
+
static int omap_early_device_register(struct platform_device *pdev);
static struct omap_device_pm_latency omap_default_latency[] = {
@@ -307,6 +313,12 @@ static void _add_hwmod_clocks_clkdev(struct omap_device
*od,
_add_clkdev(od, oh->opt_clks[i].role, oh->opt_clks[i].clk);
}
+static char *cmdline_find_option(char *str)
+{
+ extern char *saved_command_line;
+
+ return strstr(saved_command_line, str);
+}
/**
* omap_device_build_from_dt - build an omap_device with multiple hwmods
@@ -331,6 +343,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
struct device_node *node = pdev->dev.of_node;
const char *oh_name;
int oh_cnt, i, ret = 0;
+ static u8 console_uart_id;
oh_cnt = of_property_count_strings(node, "ti,hwmods");
if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
@@ -372,7 +385,13 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
r->name = dev_name(&pdev->dev);
}
- if (of_get_property(node, "ti,no_idle_on_suspend", NULL))
+ if (no_console_suspend && !strncmp(oh->name, "uart", 4)) {
+ if (console_uart_num == console_uart_id)
+ omap_device_disable_idle_on_suspend(pdev);
+ else
+ console_uart_id++;
+ }
+ else if (of_get_property(node, "ti,no_idle_on_suspend", NULL))
omap_device_disable_idle_on_suspend(pdev);
pdev->dev.pm_domain = &omap_device_pm_domain;
@@ -1256,7 +1275,21 @@ static struct notifier_block platform_nb = {
static int __init omap_device_init(void)
{
+ int i;
+ char uart_name[MAX_UART_HWMOD_NAME_LEN];
+
bus_register_notifier(&platform_bus_type, &platform_nb);
+
+ if (cmdline_find_option("no_console_suspend")) {
+ no_console_suspend = true;
+ for (i = 0; i < OMAP_MAX_HSUART_PORTS; i++) {
+ snprintf(uart_name, MAX_UART_HWMOD_NAME_LEN,
+ "%s%d", OMAP_SERIAL_NAME, i);
+ if (cmdline_find_option(uart_name))
+ console_uart_num = i;
+ }
+ }
+
return 0;
}
core_initcall(omap_device_init);
--
1.7.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 v2 06/23] ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes
On 03/15/2013 06:12 PM, Tony Lindgren wrote:
> Hi,
>
> I think you can get rid of quite a bit more of the repeated data for
> most boards, see below.
>
> * Roger Quadros [130315 08:21]:
>> Add 2 platform devices for 'nop-usb-xceiv'. These will be used
>> as PHYs for HS USB ports 1 and 2 so provide binding information
>> for them.
>>
>> Use usbhs_init_phys() to register the PHY's RESET regulators.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/mach-omap2/board-3430sdp.c | 47
>> ++
>> 1 files changed, 41 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
>> b/arch/arm/mach-omap2/board-3430sdp.c
>> index ce812de..5584682 100644
>> --- a/arch/arm/mach-omap2/board-3430sdp.c
>> +++ b/arch/arm/mach-omap2/board-3430sdp.c
>> @@ -21,6 +21,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -445,16 +446,37 @@ static void enable_board_wakeup_source(void)
>> OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
>> }
>>
>> +/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
>> +static struct platform_device hsusb1_phy_device = {
>> +.name = "nop_usb_xceiv",
>> +.id = 1,
>> +};
>> +
>> +/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
>> +static struct platform_device hsusb2_phy_device = {
>> +.name = "nop_usb_xceiv",
>> +.id = 2,
>> +};
>
> Please allocate these in the common ehci platform init code
> so you don't have to repeat the same nop_usb_xceiv for each
> board-*.c file. If you need to override these, then you can
> pass something instead of NULL to the init function.
OK. I think there is nothing to be overridden except the
platform_data. But that I can pass into via phy_data structure below.
>
>> +static struct usbhs_phy_data phy_data[] __initdata = {
>> +{
>> +.port = 1,
>> +.reset_gpio = 57,
>> +.vcc_gpio = -EINVAL,
>> +.phy_id = "nop_usb_xceiv.1",
>> +},
>> +{
>> +.port = 2,
>> +.reset_gpio = 61,
>> +.vcc_gpio = -EINVAL,
>> +.phy_id = "nop_usb_xceiv.2",
>> +},
>> +};
>
> This is OK as it's the board specific data needed. If it's the
> same for many boards, then you might want to add some init function
> for the default case.
To keep it simple I'll leave this the way it is. There is nothing
much that can be kept common. If reset_gpio and vcc_gpio is not used
then the data structure is not required at all.
>
>> +static struct platform_device *sdp3430_devices[] __initdata = {
>> +&hsusb1_phy_device,
>> +&hsusb2_phy_device,
>> +};
>
> It then seems that this can be in the common ehci platform init
> code for most cases.
OK.
>
>> static void __init omap_3430sdp_init(void)
>> {
>> int gpio_pendown;
>> @@ -606,6 +633,14 @@ static void __init omap_3430sdp_init(void)
>> board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
>> sdp3430_display_init();
>> enable_board_wakeup_source();
>> +
>> +platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
>> +/* PHY on HSUSB Port 1 i.e. index 0 */
>> +usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
>> +/* PHY on HSUSB Port 2 i.e. index 1 */
>> +usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
>
> And this part too in most cases.
Yes.
>
>> +usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
>> usbhs_init(&usbhs_bdata);
>> }
>
cheers,
-roger
--
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 4/4] ARM: OMAP3: Beagle: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3beagle.c | 32 +-
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index c3558f9..5382215 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -277,6 +278,21 @@ 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 nop_usb_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,
+ },
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -318,9 +334,11 @@ static int beagle_twl_gpio_setup(struct device *dev,
}
dvi_panel.power_down_gpio = beagle_config.dvi_pd_gpio;
- gpio_request_one(gpio + TWL4030_GPIO_MAX, beagle_config.usb_pwr_level,
- "nEN_USB_PWR");
+ /* TWL4030_GPIO_MAX i.e. LED_GPO controls HS USB Port 2 power */
+ phy_data[0].vcc_gpio = gpio + TWL4030_GPIO_MAX;
+ phy_data[0].vcc_polarity = beagle_config.usb_pwr_level;
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
return 0;
}
@@ -453,15 +471,7 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 147,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -543,7 +553,9 @@ static void __init omap3_beagle_init(void)
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
usbhs_init(&usbhs_bdata);
+
board_nand_init(omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions), NAND_CS,
NAND_BUSWIDTH_16, NULL);
--
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 2/4] ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys()
This helper allows board support code to add the PHY's
VCC and RESET regulators which are GPIO controlled as well
as the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/usb-host.c | 177 +++-
arch/arm/mach-omap2/usb.h |9 ++
2 files changed, 184 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 5706bdc..49a2c3f 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,8 +22,12 @@
#include
#include
#include
-
-#include
+#include
+#include
+#include
+#include
+#include
+#include
#include "soc.h"
#include "omap_device.h"
@@ -526,3 +530,172 @@ void __init usbhs_init(struct usbhs_omap_platform_data
*pdata)
}
#endif
+
+/* Template for PHY regulators */
+static struct regulator_consumer_supply hsusb_reg_supplies[] = {
+ { /* .supply & .dev_name filled later */ },
+};
+
+static struct regulator_init_data hsusb_reg_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb_reg_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb_reg_supplies),
+};
+
+static struct fixed_voltage_config hsusb_reg_config = {
+ /* .supply_name filled later */
+ .microvolts = 330,
+ .gpio = -1, /* updated later */
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1, /* updated later */
+ .enabled_at_boot = 0, /* keep in RESET */
+ /* .init_data filled later */
+};
+
+static struct platform_device_info hsusb_reg_pdev_info = {
+ .name = "reg-fixed-voltage",
+ .id = PLATFORM_DEVID_AUTO,
+};
+
+static const char *reset_supply = "reset";
+static const char *vcc_supply = "vcc";
+static const char *nop_name = "nop_usb_xceiv"; /* NOP PHY driver */
+
+int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)
+{
+ struct regulator_consumer_supply *supplies;
+ struct regulator_init_data *reg_data;
+ struct fixed_voltage_config *config;
+ char *supply_name;
+ int i, len;
+ struct platform_device *pdev;
+ char *phy_id;
+
+ /* the phy_id will be something like "nop_usb_xceiv.1" */
+ len = strlen(nop_name) + 3; /* 3 -> ".1" and NULL terminator */
+
+ for (i = 0; i < num_phys; i++) {
+
+ if (!phy->port) {
+ pr_err("%s: Invalid port 0. Must start from 1\n",
+ __func__);
+ continue;
+ }
+
+ /* do we need a NOP PHY device ? */
+ if (!gpio_is_valid(phy->reset_gpio) &&
+ !gpio_is_valid(phy->vcc_gpio))
+ continue;
+
+ /* create a NOP PHY device */
+ pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
+ if (!pdev)
+ return -ENOMEM;
+
+ pdev->id = phy->port;
+ pdev->name = nop_name;
+ pdev->dev.platform_data = phy->platform_data;
+
+ phy_id = kmalloc(len, GFP_KERNEL);
+ if (!phy_id)
+ return -ENOMEM;
+
+ scnprintf(phy_id, len, "nop_usb_xceiv.%d\n",
+ pdev->id);
+
+ if (platform_device_register(pdev)) {
+ pr_err("%s: Failed to register device %s\n",
+ __func__, phy_id);
+ continue;
+ }
+
+ usb_bind_phy("ehci-omap.0", phy->port - 1, phy_id);
+
+ /* Do we need RESET regulator ? */
+ if (!gpio_is_valid(phy->reset_gpio))
+ goto check_vcc;
+
+ supplies = kmemdup(hsusb_reg_supplies,
+ ARRAY_SIZE(hsusb_reg_supplies) *
+ sizeof(struct regulator_consumer_supply),
+ GFP_KERNEL);
+ if (!supplies)
+ return -ENOMEM;
+
+ supplies->supply = reset_supply;
+ supplies->dev_name = phy_id;
+
+ reg_data = kmemdup(&hsusb_reg_data, sizeof(hsusb_reg_data),
+ GFP_KERNEL);
+ if (!reg_data)
+ return -ENOMEM;
+
+ reg_data->consumer_supplies = supplies;
+
+ config = kmemdup(&hsusb_reg_config, sizeof(hsusb_reg_config),
+ GFP_KERNEL);
+ if (!config)
+ return -ENOMEM;
+
+ supply_name = kmalloc(13, GFP_KERNEL);
+ if (!supply_name)
+ return -ENOMEM;
+
+ scnprintf(supply_name, 13, "hsusb%d_reset", phy->port);
+ config->supply_name = supply_name;
+ config->gpi
[PATCH v3 0/4] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Tony, I've revised the patches based on your comments. For now I've just adapted Panda and Beagleboard. If this looks OK then I can adapt the other boards as well. cheers, -roger Roger Quadros (4): usb: phy: nop: Add some parameters to platform data ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys() ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes ARM: OMAP3: Beagle: Adapt to ehci-omap changes arch/arm/mach-omap2/board-omap3beagle.c | 32 -- arch/arm/mach-omap2/board-omap4panda.c | 55 -- arch/arm/mach-omap2/usb-host.c | 177 ++- arch/arm/mach-omap2/usb.h |9 ++ include/linux/usb/nop-usb-xceiv.h |5 + 5 files changed, 232 insertions(+), 46 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
[PATCH v3 3/4] ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device name.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap4panda.c | 55 ---
1 files changed, 21 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b02c2f0..a71ad34 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -132,6 +133,22 @@ static struct platform_device btwilink_device = {
.id = -1,
};
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct nop_usb_xceiv_platform_data hsusb1_phy_data = {
+ /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+ .clk_rate = 1920,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = GPIO_HUB_NRESET,
+ .vcc_gpio = GPIO_HUB_POWER,
+ .vcc_polarity = 1,
+ .platform_data = &hsusb1_phy_data,
+ },
+};
+
static struct platform_device *panda_devices[] __initdata = {
&leds_gpio,
&wl1271_device,
@@ -142,49 +159,19 @@ static struct platform_device *panda_devices[] __initdata
= {
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = false,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
-};
-
-static struct gpio panda_ehci_gpios[] __initdata = {
- { GPIO_HUB_POWER, GPIOF_OUT_INIT_LOW, "hub_power" },
- { GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, "hub_nreset" },
};
static void __init omap4_ehci_init(void)
{
int ret;
- struct clk *phy_ref_clk;
/* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
- phy_ref_clk = clk_get(NULL, "auxclk3_ck");
- if (IS_ERR(phy_ref_clk)) {
- pr_err("Cannot request auxclk3\n");
- return;
- }
- clk_set_rate(phy_ref_clk, 1920);
- clk_prepare_enable(phy_ref_clk);
-
- /* disable the power to the usb hub prior to init and reset phy+hub */
- ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
- if (ret) {
- pr_err("Unable to initialize EHCI power/reset\n");
- return;
- }
-
- gpio_export(GPIO_HUB_POWER, 0);
- gpio_export(GPIO_HUB_NRESET, 0);
- gpio_set_value(GPIO_HUB_NRESET, 1);
+ ret = clk_add_alias("main_clk", "nop_usb_xceiv.1", "auxclk3_ck", NULL);
+ if (ret)
+ pr_err("Failed to add main_clk alias to auxclk3_ck\n");
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
-
- /* enable power to hub */
- gpio_set_value(GPIO_HUB_POWER, 1);
}
static struct omap_musb_board_data musb_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
[PATCH v3 1/4] usb: phy: nop: Add some parameters to platform data
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.
Signed-off-by: Roger Quadros
Acked-by: Felipe Balbi
---
include/linux/usb/nop-usb-xceiv.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index 28884c7..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -5,6 +5,11 @@
struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
+ unsigned long clk_rate;
+
+ /* if set fails with -EPROBE_DEFER if can't get regulator */
+ unsigned int needs_vcc:1;
+ unsigned int needs_reset:1;
};
#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE) &&
defined(MODULE))
--
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 0/2] omap serial fix.
Hi, On Monday 18 March 2013 04:24 PM, Sourav Poddar wrote: The first patch is a rearrangement of a macro "OMAP_MAX_HSUART_PORTS" to a header file so that it can be used in other file. The second patch fixes the wakeup from uart issue while using "no_console_suspend" in the bootargs. These patches are developed on 3.8 custom kernel containing omap5 supend/resume support. Adding a bit more information, These patches are not omap5 specific and required for omap4 also. For OMAP5 testing purpose, I used 3.8 based internal tree. First patch gets applied cleanly on 3.9-rc3. Resending the second patch rebased on 3.9-rc3, as there is a small merge conflict. Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Sourav Poddar (2): driver: serial-omap: move max uart count into generic header file. arm: mach-omap2: prevent UART console idle on suspend while using "no_console_suspend" arch/arm/mach-omap2/omap_device.c | 36 - drivers/tty/serial/omap-serial.c |2 - include/linux/platform_data/serial-omap.h |1 + 3 files changed, 36 insertions(+), 3 deletions(-) -- 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/Resend 2/2] arm: mach-omap2: prevent UART console idle on suspend while using "no_console_suspend"
With dt boot, uart wakeup after suspend is non functional on omap4/5 while using
"no_console_suspend" in the bootargs. With "no_console_suspend" used, od->flags
should be ORed with "OMAP_DEVICE_NO_IDLE_ON_SUSPEND", thereby not allowing the
console
to idle in the suspend path. For non-dt case, this was taken care by platform
data.
Tested on omap5430evm, omap4430sdp.
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
---
arch/arm/mach-omap2/omap_device.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 381be7a..71f5a73 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -35,11 +35,17 @@
#include
#include
#include
+#include
#include "soc.h"
#include "omap_device.h"
#include "omap_hwmod.h"
+#define MAX_UART_HWMOD_NAME_LEN 16
+
+static u8 no_console_suspend;
+static u8 console_uart_num;
+
/* Private functions */
static void _add_clkdev(struct omap_device *od, const char *clk_alias,
@@ -108,6 +114,12 @@ static void _add_hwmod_clocks_clkdev(struct omap_device
*od,
_add_clkdev(od, oh->opt_clks[i].role, oh->opt_clks[i].clk);
}
+static char *cmdline_find_option(char *str)
+{
+ extern char *saved_command_line;
+
+ return strstr(saved_command_line, str);
+}
/**
* omap_device_build_from_dt - build an omap_device with multiple hwmods
@@ -129,6 +141,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
struct device_node *node = pdev->dev.of_node;
const char *oh_name;
int oh_cnt, i, ret = 0;
+ static u8 console_uart_id;
oh_cnt = of_property_count_strings(node, "ti,hwmods");
if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
@@ -170,7 +183,12 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
r->name = dev_name(&pdev->dev);
}
- if (of_get_property(node, "ti,no_idle_on_suspend", NULL))
+ if (no_console_suspend && !strncmp(oh->name, "uart", 4)) {
+ if (console_uart_num == console_uart_id)
+ omap_device_disable_idle_on_suspend(pdev);
+ else
+ console_uart_id++;
+ } else if (of_get_property(node, "ti,no_idle_on_suspend", NULL))
omap_device_disable_idle_on_suspend(pdev);
pdev->dev.pm_domain = &omap_device_pm_domain;
@@ -838,7 +856,21 @@ static struct notifier_block platform_nb = {
static int __init omap_device_init(void)
{
+ int i;
+ char uart_name[MAX_UART_HWMOD_NAME_LEN];
+
bus_register_notifier(&platform_bus_type, &platform_nb);
+
+ if (cmdline_find_option("no_console_suspend")) {
+ no_console_suspend = true;
+ for (i = 0; i < OMAP_MAX_HSUART_PORTS; i++) {
+ snprintf(uart_name, MAX_UART_HWMOD_NAME_LEN,
+ "%s%d", OMAP_SERIAL_NAME, i);
+ if (cmdline_find_option(uart_name))
+ console_uart_num = i;
+ }
+ }
+
return 0;
}
omap_core_initcall(omap_device_init);
--
1.7.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 V3 10/18] ARM: OMAP2+: Add function to read GPMC settings from device-tree
On 03/17/2013 12:24 AM, Ezequiel Garcia wrote:
> Hi Jon,
>
> I have some tiny nitpicks...
>
> On Fri, Mar 15, 2013 at 10:21:08AM -0500, Jon Hunter wrote:
>> Adds a function to read the various GPMC chip-select settings from
>> device-tree and store them in the gpmc_settings structure.
>>
>> Update the GPMC device-tree binding documentation to describe these
>> options.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 23 ++
>> arch/arm/mach-omap2/gpmc.c| 49
>> +
>> arch/arm/mach-omap2/gpmc.h|2 +
>> 3 files changed, 74 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> index 5ddb2e9..6fde1cf 100644
>> --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> @@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x:
>> - gpmc,wr-access
>> - gpmc,wr-data-mux-bus
>>
>> +GPMC chip-select settings properties for child nodes. All are optional.
>> +
>> +- gpmc,burst-length Page/burst length. Must be 4, 8 or 16.
>> +- gpmc,burst-wrap Enables wrap bursting
>> +- gpmc,burst-read Enables read page/burst mode
>> +- gpmc,burst-write Enables write page/burst mode
>> +- gpmc,device-nand Device is NAND
>> +- gpmc,device-width Total width of device(s) connected to a GPMC
>> +chip-select in bytes. The GPMC supports 8-bit
>> +and 16-bit devices and so this property must be
>> +1 or 2.
>> +- gpmc,mux-add-data Address and data multiplexing configuration.
>> +Valid values are 1 for address-address-data
>> +multiplexing mode and 2 for address-data
>> +multiplexing mode.
>> +- gpmc,sync-readEnables synchronous read. Defaults to asynchronous
>> +is this is not set.
>> +- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous
>> +is this is not set.
>> +- gpmc,wait-pin Wait-pin used by client. Must be less than
>> +"gpmc,num-waitpins".
>> +- gpmc,wait-on-read Enables wait monitoring on reads.
>> +- gpmc,wait-on-writeEnables wait monitoring on writes.
>>
>> Example for an AM33xx board:
>>
>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>> index 3ec1937..1e7eef3 100644
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -1190,6 +1190,55 @@ static struct of_device_id gpmc_dt_ids[] = {
>> };
>> MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
>>
>> +/**
>> + * gpmc_read_settings_dt - read gpmc settings from device-tree
>> + * @np: pointer to device-tree node for a gpmc child device
>> + * @p: pointer to gpmc settings structure
>> + *
>> + * Reads the GPMC settings for a GPMC child device from device-tree and
>> + * stores them in the GPMC settings structure passed. The GPMC settings
>> + * structure is initialise to zero by this function and so any previously
>
> s/initialise/initialized ?
Thanks will add the "d". However, "initialise" is correct British
English ;-)
>> + * stored settings will be clearer.
>
> s/clearer/cleared ?
>
> I'm not an english native speaker,
> so please bare with me if I'm wrong on these...
You are right here too. Will fix thanks!
Jon
--
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 V3 02/18] ARM: OMAP2+: Add variable to store number of GPMC waitpins
On 03/16/2013 03:59 PM, Ezequiel Garcia wrote:
> Hi Jon,
>
> On Fri, Mar 15, 2013 at 10:21:00AM -0500, Jon Hunter wrote:
>> The GPMC has wait-pin signals that can be assigned to a chip-select
>> to monitor the ready signal of an external device. Add a variable to
>> indicate the total number of wait-pins for a given device. This will
>> allow us to detect if the wait-pin being selected is valid or not.
>>
>> When booting with device-tree read the number of wait-pins from the
>> device-tree blob. When device-tree is not used set the number of
>> wait-pins to 4 which is valid for OMAP2-5 devices. Newer devices
>> that have less wait-pins (such as AM335x) only support booting with
>> device-tree and so hard-coding the wait-pin number when not using
>> device-tree is fine.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> arch/arm/mach-omap2/gpmc.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>> index ef655d9..88a261c 100644
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -108,6 +108,8 @@
>> #define GPMC_HAS_WR_ACCESS 0x1
>> #define GPMC_HAS_WR_DATA_MUX_BUS0x2
>>
>> +#define GPMC_NR_WAITPINS4
>> +
>> /* XXX: Only NAND irq has been considered,currently these are the only ones
>> used
>> */
>> #define GPMC_NR_IRQ 2
>> @@ -153,6 +155,7 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
>> static DEFINE_SPINLOCK(gpmc_mem_lock);
>> /* Define chip-selects as reserved by default until probe completes */
>> static unsigned int gpmc_cs_map = ((1 << GPMC_CS_NUM) - 1);
>> +static unsigned int gpmc_nr_waitpins;
>> static struct device *gpmc_dev;
>> static int gpmc_irq;
>> static resource_size_t phys_base, mem_size;
>> @@ -1297,6 +1300,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>> if (!of_id)
>> return 0;
>>
>> +ret = of_property_read_u32(pdev->dev.of_node, "gpmc,num-waitpins",
>> + &gpmc_nr_waitpins);
>> +if (ret < 0) {
>> +pr_err("%s: number of wait pins not found!\n", __func__);
>> +return ret;
>> +}
>> +
>> for_each_node_by_name(child, "nand") {
>> ret = gpmc_probe_nand_child(pdev, child);
>> if (ret < 0) {
>> @@ -1372,6 +1382,12 @@ static int gpmc_probe(struct platform_device *pdev)
>> if (gpmc_setup_irq() < 0)
>> dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
>>
>> +/* Now the GPMC is initialised, unreserve the chip-selects */
>> +gpmc_cs_map = 0;
>
> The above seems to be a remanent of another patch.
> I think you already sent that one, right?
Good catch. I will fix this up.
Jon
--
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: commit 6797b4f causes boot hangs with nfsroot
On 03/17/2013 08:57 PM, Paul Walmsley wrote:
> Hi Jon,
>
> On Sat, 16 Mar 2013, Paul Walmsley wrote:
>
>> Looks like commit 6797b4fe0e554ce71f47038fd929c9ca929a9f3c ("ARM: OMAP2+:
>> Prevent potential crash if GPMC probe fails") causes hangs on boot. I
>> suspect it may only occur when the root filesystem is on NFS over
>> GPMC-based Ethernet.
>
> Looks like you sent a patch for this a month ago and it just now got
> merged with v3.9-rc3 as commit 31d9adca82ce65e5c99d045b5fd917c702b6fce3
> ("ARM: OMAP2+: Fix broken gpmc support"). Thanks for fixing this promptly
> and sorry about the extra noise,
Yes I see that just got merged last week so we should be good now.
Cheers
Jon
--
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 V3 12/18] ARM: OMAP2+: Add additional GPMC timing parameters
On 03/15/2013 10:21 AM, Jon Hunter wrote:
> Some of the GPMC timings parameters are currently missing from the GPMC
> device-tree binding. Add these parameters to the binding documentation
> as well as code to read them.
>
> The existing code in gpmc_read_timings_dt() is checking the value of
> of_property_read_u32() and only is successful storing the value read
> in the gpmc_timings structure. Checking the return value in this case
> is not necessary and we can simply read the value, if present, and
> store directly in the gpmc_timings structure. Therefore, simplify the
> code by removing these checks.
>
> The comment in the gpmc_read_timings_dt() function, "only for OMAP3430"
> is also incorrect as it is applicable to all OMAP3+ devices. So correct
> this too.
>
> Signed-off-by: Jon Hunter
> ---
> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 25 +-
> arch/arm/mach-omap2/gpmc.c| 93
> ++---
> 2 files changed, 66 insertions(+), 52 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> index 6fde1cf..a63bd93 100644
> --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> @@ -56,10 +56,27 @@ Timing properties for child nodes. All are optional and
> default to 0.
> - gpmc,oe-off: Deassertion time
>
> Access time and cycle time timings corresponding to GPMC_CONFIG5:
> - - gpmc,page-burst-access: Multiple access word delay
> - - gpmc,access: Start-cycle to first data valid delay
> - - gpmc,rd-cycle:Total read cycle time
> - - gpmc,wr-cycle:Total write cycle time
> + - gpmc,page-burst-access: Multiple access word delay
> + - gpmc,access: Start-cycle to first data valid delay
> + - gpmc,rd-cycle:Total read cycle time
> + - gpmc,wr-cycle:Total write cycle time
> + - gpmc,bus-turnaround: Turn-around time between successive
> accesses
> + - gpmc,cycle2cycle-delay: Delay between chip-select pulses
> + - gpmc,clk-activation: GPMC clock activation time
> + - gpmc,wait-monitoring: Start of wait monitoring with regard to valid
> + data
What units are these in? If in nanoseconds, can you append "-ns"
> +
> +Boolean timing parameters. If property is present parameter enabled and
> +disabled if omitted:
> + - gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock
> + - gpmc,cs-extra-delay: CS signal is delayed by half GPMC clock
> + - gpmc,cycle2cycle-diffcsen:Add "cycle2cycle-delay" between
> successive
> + accesses to a different CS
> + - gpmc,cycle2cycle-samecsen:Add "cycle2cycle-delay" between
> successive
> + accesses to the same CS
> + - gpmc,oe-extra-delay: OE signal is delayed by half GPMC clock
> + - gpmc,we-extra-delay: WE signal is delayed by half GPMC clock
> + - gpmc,time-para-granularity: Multiply all access times by 2
>
> The following are only applicable to OMAP3+ and AM335x:
> - gpmc,wr-access
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 85b1a35..c928a8c 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1274,67 +1274,64 @@ void gpmc_read_settings_dt(struct device_node *np,
> struct gpmc_settings *p)
> static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
> struct gpmc_timings *gpmc_t)
> {
> - u32 val;
> -
> memset(gpmc_t, 0, sizeof(*gpmc_t));
>
> /* minimum clock period for syncronous mode */
> - if (!of_property_read_u32(np, "gpmc,sync-clk", &val))
> - gpmc_t->sync_clk = val;
> + of_property_read_u32(np, "gpmc,sync-clk", &gpmc_t->sync_clk);
>
> /* chip select timtings */
> - if (!of_property_read_u32(np, "gpmc,cs-on", &val))
> - gpmc_t->cs_on = val;
> -
> - if (!of_property_read_u32(np, "gpmc,cs-rd-off", &val))
> - gpmc_t->cs_rd_off = val;
> -
> - if (!of_property_read_u32(np, "gpmc,cs-wr-off", &val))
> - gpmc_t->cs_wr_off = val;
> + of_property_read_u32(np, "gpmc,cs-on", &gpmc_t->cs_on);
> + of_property_read_u32(np, "gpmc,cs-rd-off", &gpmc_t->cs_rd_off);
> + of_property_read_u32(np, "gpmc,cs-wr-off", &gpmc_t->cs_wr_off);
>
> /* ADV signal timings */
> - if (!of_property_read_u32(np, "gpmc,adv-on", &val))
> - gpmc_t->adv_on = val;
> -
> - if (!of_property_read_u32(np, "gpmc,adv-rd-off", &val))
> - gpmc_t->adv_rd_off = val;
> -
> - if (!of_property_read_u32(np, "gpmc,adv-wr-off", &val))
> - gpmc_t->adv_wr_off = val;
> + of_property_read_u32(np, "gpmc,adv-on", &gpmc_t->adv_on);
> + of_property_read_u32(np, "gpmc,adv-rd-off", &gpmc_t->a
Re: [PATCH V3 12/18] ARM: OMAP2+: Add additional GPMC timing parameters
On 03/18/2013 09:07 AM, Rob Herring wrote:
> On 03/15/2013 10:21 AM, Jon Hunter wrote:
>> Some of the GPMC timings parameters are currently missing from the GPMC
>> device-tree binding. Add these parameters to the binding documentation
>> as well as code to read them.
>>
>> The existing code in gpmc_read_timings_dt() is checking the value of
>> of_property_read_u32() and only is successful storing the value read
>> in the gpmc_timings structure. Checking the return value in this case
>> is not necessary and we can simply read the value, if present, and
>> store directly in the gpmc_timings structure. Therefore, simplify the
>> code by removing these checks.
>>
>> The comment in the gpmc_read_timings_dt() function, "only for OMAP3430"
>> is also incorrect as it is applicable to all OMAP3+ devices. So correct
>> this too.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 25 +-
>> arch/arm/mach-omap2/gpmc.c| 93
>> ++---
>> 2 files changed, 66 insertions(+), 52 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> index 6fde1cf..a63bd93 100644
>> --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> @@ -56,10 +56,27 @@ Timing properties for child nodes. All are optional and
>> default to 0.
>> - gpmc,oe-off: Deassertion time
>>
>> Access time and cycle time timings corresponding to GPMC_CONFIG5:
>> - - gpmc,page-burst-access: Multiple access word delay
>> - - gpmc,access: Start-cycle to first data valid delay
>> - - gpmc,rd-cycle: Total read cycle time
>> - - gpmc,wr-cycle: Total write cycle time
>> + - gpmc,page-burst-access: Multiple access word delay
>> + - gpmc,access: Start-cycle to first data valid delay
>> + - gpmc,rd-cycle: Total read cycle time
>> + - gpmc,wr-cycle: Total write cycle time
>> + - gpmc,bus-turnaround: Turn-around time between successive
>> accesses
>> + - gpmc,cycle2cycle-delay: Delay between chip-select pulses
>> + - gpmc,clk-activation: GPMC clock activation time
>> + - gpmc,wait-monitoring:Start of wait monitoring with regard to valid
>> +data
>
> What units are these in? If in nanoseconds, can you append "-ns"
These are cycles. I can update the comment to reflect that.
>> +
>> +Boolean timing parameters. If property is present parameter enabled and
>> +disabled if omitted:
>> + - gpmc,adv-extra-delay:ADV signal is delayed by half GPMC clock
>> + - gpmc,cs-extra-delay: CS signal is delayed by half GPMC clock
>> + - gpmc,cycle2cycle-diffcsen: Add "cycle2cycle-delay" between
>> successive
>> +accesses to a different CS
>> + - gpmc,cycle2cycle-samecsen: Add "cycle2cycle-delay" between
>> successive
>> +accesses to the same CS
>> + - gpmc,oe-extra-delay: OE signal is delayed by half GPMC clock
>> + - gpmc,we-extra-delay: WE signal is delayed by half GPMC clock
>> + - gpmc,time-para-granularity: Multiply all access times by 2
>>
>> The following are only applicable to OMAP3+ and AM335x:
>> - gpmc,wr-access
>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>> index 85b1a35..c928a8c 100644
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -1274,67 +1274,64 @@ void gpmc_read_settings_dt(struct device_node *np,
>> struct gpmc_settings *p)
>> static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
>> struct gpmc_timings *gpmc_t)
>> {
>> -u32 val;
>> -
>> memset(gpmc_t, 0, sizeof(*gpmc_t));
>>
>> /* minimum clock period for syncronous mode */
>> -if (!of_property_read_u32(np, "gpmc,sync-clk", &val))
>> -gpmc_t->sync_clk = val;
>> +of_property_read_u32(np, "gpmc,sync-clk", &gpmc_t->sync_clk);
>>
>> /* chip select timtings */
>> -if (!of_property_read_u32(np, "gpmc,cs-on", &val))
>> -gpmc_t->cs_on = val;
>> -
>> -if (!of_property_read_u32(np, "gpmc,cs-rd-off", &val))
>> -gpmc_t->cs_rd_off = val;
>> -
>> -if (!of_property_read_u32(np, "gpmc,cs-wr-off", &val))
>> -gpmc_t->cs_wr_off = val;
>> +of_property_read_u32(np, "gpmc,cs-on", &gpmc_t->cs_on);
>> +of_property_read_u32(np, "gpmc,cs-rd-off", &gpmc_t->cs_rd_off);
>> +of_property_read_u32(np, "gpmc,cs-wr-off", &gpmc_t->cs_wr_off);
>>
>> /* ADV signal timings */
>> -if (!of_property_read_u32(np, "gpmc,adv-on", &val))
>> -gpmc_t->adv_on = val;
>> -
>> -if (!of_property_read_u32(np, "gpmc,adv-rd-off", &val))
>> -gpmc_t->adv_rd_off = val;
>> -
>> -if (!of_property_read_u32(np, "gpmc,adv-wr-off", &val))
>> -
Re: [PATCH 00/50] staging: omap-thermal: several code refactoring
Greg, Dan, On 16-03-2013 12:16, Greg KH wrote: On Sat, Mar 16, 2013 at 08:46:03AM -0400, Eduardo Valentin wrote: Hello Dan, On 16-03-2013 05:05, Dan Carpenter wrote: I've reviewed this set. I hate to make people redo whole patchset sets, and I hate re-reviewing code. Obviously, I don't really like the bunny hop patches and I'm trying to discourage that going forward. ;P But I wouldn't say it's a "Redo the whole thing" kind of problem. Could just resend patch 33 and 47? You should probably be able to redo those without changing the rest. I could of course change them if the comment is better clarified. As I mentioned as reply to one of your comments, those changes are following what is suggested in CodingStyle file. I can of course send a diff on top of 33, to fix the introduce bug. For 47, I'm not sure the comment is fully applicable. As I've taken all of these already (sorry Dan, I was fast and I didn't review them as well as you did), you will have to just send incremental patches on top of the whole series in order for me to be able to apply them. No issues here, I am going to send soon incremental patches, copying Dan, to fix the above mentioned issues on 33 and 47. thanks, greg k-h -- 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 0/8] staging: [omap,ti-soc]-thermal: fixes and renaming
Hi Greg,
I am sending extra patches on omap-thermal driver, under staging.
There are couple of fixes based on Dan Carpenter's review on
the last patch set I sent. On top of these, there are some
changes on the naming convention for this driver. This rename
is based on previous review cycles that this driver has got.
Besides, it must support other chip families, apart from OMAP,
that's mainly why there is a big rename on this patch set.
And as usual, there are couple of extra fixes.
All these are based on your staging/staging-next branch.
For those interested in testing and trying the driver, these patches are
also available, as usual, here:
g...@gitorious.org:thermal-framework/thermal-framework.git
thermal_work/omap/ti-thermal-rename
https://git.gitorious.org/thermal-framework/thermal-framework.git
thermal_work/omap/ti-thermal-rename
BR,
Eduardo Valentin (8):
staging: omap-thermal: fix return value
staging: omap-thermal: use spin_lock_irqsave inside IRQ handler
staging: omap-thermal: rename bg_ptr to bgp
staging: rename omap-thermal driver to ti-soc-thermal
staging: ti-soc-thermal: make unexported functions local
staging: ti-soc-thermal: split writable data from readonly data
stating: ti-soc-thermal: use sizeof(*pointer) while allocating
staging: ti-soc-thermal: fix several kernel-doc warnings and error
drivers/staging/Kconfig|2 +-
drivers/staging/Makefile |2 +-
drivers/staging/omap-thermal/Makefile |5 -
drivers/staging/omap-thermal/omap-bandgap.c| 1300
drivers/staging/omap-thermal/omap-thermal-common.c | 338 -
.../{omap-thermal => ti-soc-thermal}/Kconfig | 14 +-
drivers/staging/ti-soc-thermal/Makefile|5 +
.../staging/{omap-thermal => ti-soc-thermal}/TODO |0
.../omap4-thermal-data.c | 68 +-
.../omap4xxx-bandgap.h |0
.../omap5-thermal-data.c | 20 +-
.../omap5xxx-bandgap.h |0
.../omap_bandgap.txt |0
drivers/staging/ti-soc-thermal/ti-bandgap.c| 1299 +++
.../omap-bandgap.h => ti-soc-thermal/ti-bandgap.h} | 181 ++--
drivers/staging/ti-soc-thermal/ti-thermal-common.c | 338 +
.../omap-thermal.h => ti-soc-thermal/ti-thermal.h} | 30 +-
17 files changed, 1803 insertions(+), 1799 deletions(-)
delete mode 100644 drivers/staging/omap-thermal/Makefile
delete mode 100644 drivers/staging/omap-thermal/omap-bandgap.c
delete mode 100644 drivers/staging/omap-thermal/omap-thermal-common.c
rename drivers/staging/{omap-thermal => ti-soc-thermal}/Kconfig (82%)
create mode 100644 drivers/staging/ti-soc-thermal/Makefile
rename drivers/staging/{omap-thermal => ti-soc-thermal}/TODO (100%)
rename drivers/staging/{omap-thermal => ti-soc-thermal}/omap4-thermal-data.c
(85%)
rename drivers/staging/{omap-thermal => ti-soc-thermal}/omap4xxx-bandgap.h
(100%)
rename drivers/staging/{omap-thermal => ti-soc-thermal}/omap5-thermal-data.c
(96%)
rename drivers/staging/{omap-thermal => ti-soc-thermal}/omap5xxx-bandgap.h
(100%)
rename drivers/staging/{omap-thermal => ti-soc-thermal}/omap_bandgap.txt (100%)
create mode 100644 drivers/staging/ti-soc-thermal/ti-bandgap.c
rename drivers/staging/{omap-thermal/omap-bandgap.h =>
ti-soc-thermal/ti-bandgap.h} (75%)
create mode 100644 drivers/staging/ti-soc-thermal/ti-thermal-common.c
rename drivers/staging/{omap-thermal/omap-thermal.h =>
ti-soc-thermal/ti-thermal.h} (72%)
--
1.7.7.1.488.ge8e1c
--
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/8] staging: omap-thermal: fix return value
Return the proper error value in _omap_bandgap_read_threshold. Cc: Dan Carpenter Signed-off-by: Eduardo Valentin diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index 33bfe3b..cb7aa35 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -566,7 +566,7 @@ int _omap_bandgap_read_threshold(struct omap_bandgap *bg_ptr, int id, *val = temp; exit: - return 0; + return ret; } /*** Exposed APIs ***/ -- 1.7.7.1.488.ge8e1c -- 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 2/8] staging: omap-thermal: use spin_lock_irqsave inside IRQ handler
Even if the IRQ is not firing because it is ONE_SHOT and disable
at INTC level, the IRQ handler must use spin_lock_irqsave.
It is necessary to disable IRQs from the current
CPU while it is holding a spin_lock which is need.
Cc: Dan Carpenter
Signed-off-by: Eduardo Valentin
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index cb7aa35..a4ac06c 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -168,9 +168,10 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int
irq, void *data)
struct omap_bandgap *bg_ptr = data;
struct temp_sensor_registers *tsr;
u32 t_hot = 0, t_cold = 0, ctrl;
+ unsigned long flags;
int i;
- spin_lock(&bg_ptr->lock);
+ spin_lock_irqsave(&bg_ptr->lock, flags);
for (i = 0; i < bg_ptr->conf->sensor_count; i++) {
tsr = bg_ptr->conf->sensors[i].registers;
ctrl = omap_bandgap_readl(bg_ptr, tsr->bgap_status);
@@ -209,7 +210,7 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int irq,
void *data)
if (bg_ptr->conf->report_temperature)
bg_ptr->conf->report_temperature(bg_ptr, i);
}
- spin_unlock(&bg_ptr->lock);
+ spin_unlock_irqrestore(&bg_ptr->lock, flags);
return IRQ_HANDLED;
}
--
1.7.7.1.488.ge8e1c
--
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 3/8] staging: omap-thermal: rename bg_ptr to bgp
Use a shorter name to bandgap pointer.
Cc: Benoit
Signed-off-by: Eduardo Valentin
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index a4ac06c..89361fe 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -46,28 +46,28 @@
/**
* omap_bandgap_readl() - simple read helper function
- * @bg_ptr: pointer to omap_bandgap structure
+ * @bgp: pointer to omap_bandgap structure
* @reg: desired register (offset) to be read
*
* Helper function to read bandgap registers. It uses the io remapped area.
* Returns the register value.
*/
-static u32 omap_bandgap_readl(struct omap_bandgap *bg_ptr, u32 reg)
+static u32 omap_bandgap_readl(struct omap_bandgap *bgp, u32 reg)
{
- return readl(bg_ptr->base + reg);
+ return readl(bgp->base + reg);
}
/**
* omap_bandgap_writel() - simple write helper function
- * @bg_ptr: pointer to omap_bandgap structure
+ * @bgp: pointer to omap_bandgap structure
* @val: desired register value to be written
* @reg: desired register (offset) to be written
*
* Helper function to write bandgap registers. It uses the io remapped area.
*/
-static void omap_bandgap_writel(struct omap_bandgap *bg_ptr, u32 val, u32 reg)
+static void omap_bandgap_writel(struct omap_bandgap *bgp, u32 val, u32 reg)
{
- writel(val, bg_ptr->base + reg);
+ writel(val, bgp->base + reg);
}
/**
@@ -76,38 +76,38 @@ static void omap_bandgap_writel(struct omap_bandgap
*bg_ptr, u32 val, u32 reg)
* RMW_BITS() - used to read, modify and update bandgap bitfields.
*The value passed will be shifted.
*/
-#define RMW_BITS(bg_ptr, id, reg, mask, val) \
+#define RMW_BITS(bgp, id, reg, mask, val) \
do { \
struct temp_sensor_registers *t;\
u32 r; \
\
- t = bg_ptr->conf->sensors[(id)].registers; \
- r = omap_bandgap_readl(bg_ptr, t->reg); \
+ t = bgp->conf->sensors[(id)].registers; \
+ r = omap_bandgap_readl(bgp, t->reg);\
r &= ~t->mask; \
r |= (val) << __ffs(t->mask); \
- omap_bandgap_writel(bg_ptr, r, t->reg); \
+ omap_bandgap_writel(bgp, r, t->reg);\
} while (0)
/*** Basic helper functions ***/
/**
* omap_bandgap_power() - controls the power state of a bandgap device
- * @bg_ptr: pointer to omap_bandgap structure
+ * @bgp: pointer to omap_bandgap structure
* @on: desired power state (1 - on, 0 - off)
*
* Used to power on/off a bandgap device instance. Only used on those
* that features tempsoff bit.
*/
-static int omap_bandgap_power(struct omap_bandgap *bg_ptr, bool on)
+static int omap_bandgap_power(struct omap_bandgap *bgp, bool on)
{
int i;
- if (!OMAP_BANDGAP_HAS(bg_ptr, POWER_SWITCH))
+ if (!OMAP_BANDGAP_HAS(bgp, POWER_SWITCH))
goto exit;
- for (i = 0; i < bg_ptr->conf->sensor_count; i++)
+ for (i = 0; i < bgp->conf->sensor_count; i++)
/* active on 0 */
- RMW_BITS(bg_ptr, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
+ RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
exit:
return 0;
@@ -115,7 +115,7 @@ exit:
/**
* omap_bandgap_read_temp() - helper function to read sensor temperature
- * @bg_ptr: pointer to omap_bandgap structure
+ * @bgp: pointer to omap_bandgap structure
* @id: bandgap sensor id
*
* Function to concentrate the steps to read sensor temperature register.
@@ -123,16 +123,16 @@ exit:
* it might be needed to freeze the bandgap state machine, before fetching
* the register value.
*/
-static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id)
+static u32 omap_bandgap_read_temp(struct omap_bandgap *bgp, int id)
{
struct temp_sensor_registers *tsr;
u32 temp, reg;
- tsr = bg_ptr->conf->sensors[id].registers;
+ tsr = bgp->conf->sensors[id].registers;
reg = tsr->temp_sensor_ctrl;
- if (OMAP_BANDGAP_HAS(bg_ptr, FREEZE_BIT)) {
- RMW_BITS(bg_ptr, id, bgap_mask_ctrl, mask_freeze_mask, 1);
+ if (OMAP_BANDGAP_HAS(bgp, FREEZE_BIT)) {
+ RMW_BITS(bgp, id, bgap_mask_ctrl, mask_freeze_mask, 1);
/*
* In case we cannot read from cur_dtemp / dtemp_0,
* then we read from the last valid temp read
@@ -141,11 +141,11 @@ static u32 omap_bandgap_read_temp(struct omap_bandgap
*bg_ptr, int id)
}
/* read temperature */
- temp = omap_bandgap_readl(bg_ptr, reg);
+ temp = omap_bandg
[PATCH 5/8] staging: ti-soc-thermal: make unexported functions local
Move _ti_bandgap_write_threshold and _ti_bandgap_read_threshold to static
area, as they are local functions.
Signed-off-by: Eduardo Valentin
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index 6a0b1ac..c850e13 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c
@@ -477,8 +477,8 @@ exit:
* Validates the mCelsius range and update the requested threshold.
* Call this function only if bandgap features HAS(TALERT).
*/
-int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
- bool hot)
+static int _ti_bandgap_write_threshold(struct ti_bandgap *bgp, int id, int val,
+ bool hot)
{
struct temp_sensor_data *ts_data;
struct temp_sensor_registers *tsr;
@@ -531,8 +531,8 @@ exit:
* This function can be used to read t_hot or t_cold, depending on @hot value.
* Call this function only if bandgap features HAS(TALERT).
*/
-int _ti_bandgap_read_threshold(struct ti_bandgap *bgp, int id, int *val,
- bool hot)
+static int _ti_bandgap_read_threshold(struct ti_bandgap *bgp, int id, int *val,
+ bool hot)
{
struct temp_sensor_registers *tsr;
u32 temp, mask;
--
1.7.7.1.488.ge8e1c
--
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 6/8] staging: ti-soc-thermal: split writable data from readonly data
This patch changes the data structures of this driver so
that readonly data can reside only in the conf pointer.
Now each register has a struct to hold its configuration info,
to be used base on chip version for instance, and a
struct of values to be written, like register shadow and priv data.
Signed-off-by: Eduardo Valentin
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index c850e13..b74e847 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c
@@ -249,7 +249,7 @@ static irqreturn_t ti_bandgap_tshut_irq_handler(int irq,
void *data)
static
int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
{
- struct ti_bandgap_data *conf = bgp->conf;
+ const struct ti_bandgap_data *conf = bgp->conf;
int ret = 0;
/* look up for temperature in the table and return the temperature */
@@ -277,7 +277,7 @@ exit:
static
int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long temp, int *adc)
{
- struct ti_bandgap_data *conf = bgp->conf;
+ const struct ti_bandgap_data *conf = bgp->conf;
const int *conv_table = bgp->conf->conv_table;
int high, low, mid, ret = 0;
@@ -726,7 +726,7 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int
id, void *data)
if (ret)
return ret;
- bgp->conf->sensors[id].data = data;
+ bgp->regval[id].data = data;
return 0;
}
@@ -745,7 +745,7 @@ void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp,
int id)
if (ret)
return ERR_PTR(ret);
- return bgp->conf->sensors[id].data;
+ return bgp->regval[id].data;
}
/*** Helper functions used during device initialization ***/
@@ -913,6 +913,14 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
if (of_id)
bgp->conf = of_id->data;
+ /* register shadow for context save and restore */
+ bgp->regval = devm_kzalloc(&pdev->dev, sizeof(*bgp->regval) *
+ bgp->conf->sensor_count, GFP_KERNEL);
+ if (!bgp) {
+ dev_err(&pdev->dev, "Unable to allocate mem for driver ref\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
i = 0;
do {
void __iomem *chunk;
@@ -1149,7 +1157,7 @@ static int ti_bandgap_save_ctxt(struct ti_bandgap *bgp)
struct temp_sensor_registers *tsr;
struct temp_sensor_regval *rval;
- rval = &bgp->conf->sensors[i].regval;
+ rval = &bgp->regval[i];
tsr = bgp->conf->sensors[i].registers;
if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
@@ -1182,7 +1190,7 @@ static int ti_bandgap_restore_ctxt(struct ti_bandgap *bgp)
struct temp_sensor_regval *rval;
u32 val = 0;
- rval = &bgp->conf->sensors[i].regval;
+ rval = &bgp->regval[i];
tsr = bgp->conf->sensors[i].registers;
if (TI_BANDGAP_HAS(bgp, COUNTER))
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.h
b/drivers/staging/ti-soc-thermal/ti-bandgap.h
index 00d7596..66bbd07 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.h
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.h
@@ -30,6 +30,13 @@
/**
* DOC: bandgap driver data structure
* ==
+ *
+ * +--++
+ * | struct temp_sensor_regval |
+ * +---+
+ * * (Array of)
+ * |
+ * |
* +---+ +-+
* | struct ti_bandgap |-->| struct device * |
* ++--+ +-+
@@ -44,14 +51,14 @@
* * (Array of)
* ++--+
* | +--+--+ +-+ |
- * | | struct ti_temp_sensor |-->| struct temp_sensor_data | |
+ * | | struct ti_temp_sensor |-->| struct temp_sensor_data | |
* | +-+ +++ |
* || |
- * |+--+ |
- * |V V |
- * | +--+- --+ ++-+ |
- * | | struct temp_sensor_regval | | struct temp_sensor_registers | |
- * | +---+ +--+ |
+ * |+ |
+ * |V |
+ * | +--+---+ |
+ * | | struct temp_sensor_registers | |
+ * | +--+
[PATCH 7/8] stating: ti-soc-thermal: use sizeof(*pointer) while allocating
Follow Documentation/CodingStyle and use sizeof(*pointer)
instead of sizeof(struct type).
Signed-off-by: Eduardo Valentin
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index b74e847..4382c0c 100644
--- a/drivers/staging/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c
@@ -902,8 +902,7 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
return ERR_PTR(-EINVAL);
}
- bgp = devm_kzalloc(&pdev->dev, sizeof(struct ti_bandgap),
- GFP_KERNEL);
+ bgp = devm_kzalloc(&pdev->dev, sizeof(*bgp), GFP_KERNEL);
if (!bgp) {
dev_err(&pdev->dev, "Unable to allocate mem for driver ref\n");
return ERR_PTR(-ENOMEM);
--
1.7.7.1.488.ge8e1c
--
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 8/8] staging: ti-soc-thermal: fix several kernel-doc warnings and error
This patch updates the documentation to remove all warnings and errors reported by scripts/kernel-doc. Most are missing arguments due to wrong format. Cc: Nishanth Menon Signed-off-by: Eduardo Valentin diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c b/drivers/staging/ti-soc-thermal/ti-bandgap.c index 4382c0c..ca1b02d 100644 --- a/drivers/staging/ti-soc-thermal/ti-bandgap.c +++ b/drivers/staging/ti-soc-thermal/ti-bandgap.c @@ -341,6 +341,7 @@ exit: /** * ti_bandgap_unmask_interrupts() - unmasks the events of thot & tcold * @bgp: struct ti_bandgap pointer + * @id: bandgap sensor id * @t_hot: hot temperature value to trigger alert signal * @t_cold: cold temperature value to trigger alert signal * @@ -572,9 +573,9 @@ exit: /** * ti_bandgap_read_thot() - reads sensor current thot - * @bgp - pointer to bandgap instance - * @id - sensor id - * @thot - resulting current thot value + * @bgp: pointer to bandgap instance + * @id: sensor id + * @thot: resulting current thot value * * returns 0 on success or the proper error code */ @@ -585,9 +586,9 @@ int ti_bandgap_read_thot(struct ti_bandgap *bgp, int id, int *thot) /** * ti_bandgap_write_thot() - sets sensor current thot - * @bgp - pointer to bandgap instance - * @id - sensor id - * @val - desired thot value + * @bgp: pointer to bandgap instance + * @id: sensor id + * @val: desired thot value * * returns 0 on success or the proper error code */ @@ -598,9 +599,9 @@ int ti_bandgap_write_thot(struct ti_bandgap *bgp, int id, int val) /** * ti_bandgap_read_tcold() - reads sensor current tcold - * @bgp - pointer to bandgap instance - * @id - sensor id - * @tcold - resulting current tcold value + * @bgp: pointer to bandgap instance + * @id: sensor id + * @tcold: resulting current tcold value * * returns 0 on success or the proper error code */ @@ -611,9 +612,9 @@ int ti_bandgap_read_tcold(struct ti_bandgap *bgp, int id, int *tcold) /** * ti_bandgap_write_tcold() - sets the sensor tcold - * @bgp - pointer to bandgap instance - * @id - sensor id - * @val - desired tcold value + * @bgp: pointer to bandgap instance + * @id: sensor id + * @val: desired tcold value * * returns 0 on success or the proper error code */ @@ -624,9 +625,9 @@ int ti_bandgap_write_tcold(struct ti_bandgap *bgp, int id, int val) /** * ti_bandgap_read_update_interval() - read the sensor update interval - * @bgp - pointer to bandgap instance - * @id - sensor id - * @interval - resulting update interval in miliseconds + * @bgp: pointer to bandgap instance + * @id: sensor id + * @interval: resulting update interval in miliseconds * * returns 0 on success or the proper error code */ @@ -656,9 +657,9 @@ int ti_bandgap_read_update_interval(struct ti_bandgap *bgp, int id, /** * ti_bandgap_write_update_interval() - set the update interval - * @bgp - pointer to bandgap instance - * @id - sensor id - * @interval - desired update interval in miliseconds + * @bgp: pointer to bandgap instance + * @id: sensor id + * @interval: desired update interval in miliseconds * * returns 0 on success or the proper error code */ @@ -682,9 +683,9 @@ int ti_bandgap_write_update_interval(struct ti_bandgap *bgp, /** * ti_bandgap_read_temperature() - report current temperature - * @bgp - pointer to bandgap instance - * @id - sensor id - * @temperature - resulting temperature + * @bgp: pointer to bandgap instance + * @id: sensor id + * @temperature: resulting temperature * * returns 0 on success or the proper error code */ @@ -714,9 +715,9 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp, int id, /** * ti_bandgap_set_sensor_data() - helper function to store thermal * framework related data. - * @bgp - pointer to bandgap instance - * @id - sensor id - * @data - thermal framework related data to be stored + * @bgp: pointer to bandgap instance + * @id: sensor id + * @data: thermal framework related data to be stored * * returns 0 on success or the proper error code */ @@ -734,8 +735,8 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap *bgp, int id, void *data) /** * ti_bandgap_get_sensor_data() - helper function to get thermal * framework related data. - * @bgp - pointer to bandgap instance - * @id - sensor id + * @bgp: pointer to bandgap instance + * @id: sensor id * * returns data stored by set function with sensor id on success or NULL */ @@ -877,16 +878,15 @@ static int ti_bandgap_talert_init(struct ti_bandgap *bgp, return 0; } +static const struct of_device_id of_ti_bandgap_match[]; /** * ti_bandgap_build() - parse DT and setup a struct ti_bandgap - * @bgp: pointer to struct ti_bandgap * @pdev: pointer to device struct platform_device * * Used to read the device tree properties accordingly to the bandgap * matching version. Based on bandgap version and its capabilities it * will build a struct ti_bandgap out of the required DT entries. */ -static const struct of_device
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
Hi Santosh,
On Mon, Mar 18, 2013 at 06:51:30AM +, Santosh Shilimkar wrote:
> On Friday 15 March 2013 10:30 AM, Will Deacon wrote:
> > Furthermore, I was under the impression that hw_breakpoint did actually
> > work on panda, which implies that a cold boot *does* manage to reset the
> > registers (can you please confirm this by looking in your dmesg during
> > boot?). In that case, it seems as though a PM cycle is powering down a
> > bunch of debug logic that was powered up during boot, and then we trip over
> > because we can't access the register bank.
> >
> Actually it seems to be without PM. Thanks to analysis from Lokesh, the issue
> can be seen even with just suspend or cpu hotplug. So cold boot as such is
> fine.
Right, so what you're saying is that monitor-mode hardware debug only works
until the first pm/suspend/hotplug operation, then it's dead in the water?
> > The proper solution to this problem requires us to establish exactly what is
> > turning off the debug registers, and then having an OMAP PM notifier to
> > enable it again. Assuming this has always been the case, I expect hardware
> > debug across PM fails silently with older kernels.
> >
> This has been always the case it seems with CPU power cycle.
> After the CPU is power cycled, 'DBGAUTHSTATUS' reads '0xaa' rather
> than '0xaf' which means 'DBGEN = 0' and hence code fails to enable
> monitor mode. This happens on both secure and GP devices and it can not
> be patched since the secure code is ROM'ed. We didn't notice so far
> because hw_breakpoint support was not default enabled on OMAP till the
> multi-platform build.
That really sucks :( Does this affect all OMAP-based boards?
> >> I was also wondering whether we should just warn once rather
> >> than continuous warnings in the notifier. Patch is end of the
> >> email.
> >
> > Could do, but I'd like to see a fix for the real issue before we simply hide
> > the warnings :)
> >
> Agree here too. As evident above, the feature won't work on OMAP4
> devices with PM and hence some solution is needed.
>
> What you think of below ?
Comments inline...
>
> From d74b4264f6a5967b0f7ada96aad77ab0ac30dbed Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar
> Date: Mon, 18 Mar 2013 11:59:04 +0530
> Subject: [PATCH] ARM: hw_breakpoints: Check for CPU debug availability before
> enabling it
>
> CPU debug features like hardware break, watchpoints can be used only when
> the debug mode is enabled and available for non-secure mode.
>
> Hence check 'DBGAUTHSTATUS.DBGEN' before proceeding to enable the
> features.
>
> Thanks to Will for pointers and Lokesh for the analysis of the issue on
> OMAP4 where after a CPU power cycle, debug mode gets disabled.
>
> Cc: Will Deacon
>
> Tested-by: Lokesh Vutla
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/kernel/hw_breakpoint.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
> index 96093b7..683a7cf 100644
> --- a/arch/arm/kernel/hw_breakpoint.c
> +++ b/arch/arm/kernel/hw_breakpoint.c
> @@ -930,6 +930,14 @@ static void reset_ctrl_regs(void *unused)
> int i, raw_num_brps, err = 0, cpu = smp_processor_id();
> u32 val;
>
> + /* Check if we have access to CPU debug features */
> + ARM_DBG_READ(c7, c14, 6, val);
> + if ((val & 0x1) == 0) {
> + pr_warn_once("CPU %d debug is unavailable\n", cpu);
> + cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu));
> + return;
> + }
There are a few of problems here:
1. That is only checking for non-secure access, which precludes
running Linux in secure mode.
2. DBGAUTHSTATUS accesses are UNPREDICTABLE when the double-lock is
set for v7.1 processors.
3. DBGAUTHSTATUS doesn't exist in ARMv6.
4. CPUs without the security extensions have DBGAUTHSTATUS.NSE == 0
5. Accessing DBGAUTHSTATUS requires DBGEN to be driven high.
Assuming that your pr_warn_once is emitted, this implies that
DBGEN is driven high from cold boot, yet the NSE bit is low,
implying that DBGEN is also low. That's contradictory, so I have
no idea what's going on...
Apart from that, it's fine!
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
Re: [PATCH V4] ARM: dts: add minimal DT support for DevKit8000.
Hi Anil, On 03/17/2013 06:23 AM, Anil Kumar wrote: > Hi Benoit, > > On Thu, Mar 7, 2013 at 12:21 PM, Benoit Cousson wrote: >> Hi, >> >> On 03/06/2013 06:53 PM, Tony Lindgren wrote: >>> * Anil Kumar [130305 18:40]: Hi Tony, >> From: linux-arm-kernel [mailto:linux-arm-kernel- >> boun...@lists.infradead.org] On Behalf Of Anil Kumar >> Sent: Wednesday, February 27, 2013 8:03 AM >> To: devicetree-disc...@lists.ozlabs.org; linux-omap@vger.kernel.org; >> linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org >> Cc: li...@arm.linux.org.uk; Cousson, Benoit; Tony Lindgren; Grant >> Likely; Anil Kumar; tho...@tomweber.eu >> Subject: Re: FW: [PATCH V4] ARM: dts: add minimal DT support for >> DevKit8000. >> >> Hi, >>> >>> DevKit8000 is a beagle board clone from Timll, sold by >>> armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D, >>> S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and >>> JTAG interface. >>> >>> This patch adds the basic DT support for devkit8000. At this time, >> Information >>> of twl4030 (PMIC), MMC1, I2C1 and leds are added. >>> >>> Signed-off-by: Anil Kumar >>> Tested-by: Thomas Weber >> >> Gentle Ping. As there are no review comments on this patch, >> Could you please pull this patch ? Gentle Ping. This patch also got Reviewed-by: Manish Badarkhe and as patch "ARM: dts: omap3-devkit8000: Enable audio support" has already got "Acked-by: Peter Ujfalusi " but it is on the top of this patch. So, Could you please pull this patch in one of your omap branch? or you want me to do rebase this patch on top of v3.9-rc1 ? >>> >>> Let's wait for Benoit to queue it as he has a bunch of .dts >>> changesfor_3.10/dts already >>> applied. Too bad we missed v3.9 merge window for those, but hopefully >>> we can get them queued early for v3.10. >> >> Yep, sorry for having missed 3.9, I was a little bit sick at the wrong >> moment :-( >> >> I'm starting queuing the pending patches, and should have enough to push >> to you just after Linaro Connect. > > I think you missed below patch which is needed for gpmc nand to work fine. > > Jon Hunter:- > ARM: OMAP2+: Fix-up gpmc merge error > > I have re based my changes on top of your repository to make pull > easier for you. > I hope you will pull these changes for 3.10. > > The following changes since Commit a7f7881de9c0b58de3b3aea8f01a8aef906d4ade > > are available in the git repository at: > > git://gitorious.org/devkit8000-for_3-10/devkit8000-for_3-10.git > branch for_3.10/dts > > for you to fetch changes up to Commit 975abc8b2e7ec4ff7324d726c9775958945ccc5e Thanks, I pulled the patches and rebased that on top of -rc3 to get the missing fix from Jon. I cleaned as well some changelog / subject and pushed then in my for_3.10/dts branch. 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
OMAP baseline test results for v3.9-rc3
Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
Test summary
Build:
FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
omap2plus_defconfig_2430sdp_only
Pass (13/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
omap1_defconfig_1510innovator_only,
omap2plus_defconfig, omap2plus_defconfig_cpupm,
omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig
rmk_omap4430_sdp_oldconfig
Boot to userspace:
FAIL ( 1/11): am335xbone
Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
5912osk, cmt3517
PM ret, suspend:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM ret, dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM off, suspend:
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
PM off, dynamic idle:
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
Failing tests: fixed by posted patches
--
Build:
* omap1_defconfig_5912osk_only: implicit declaration of function
'cpu_is_omap15xx'
- Fixed by Aaro: http://www.spinics.net/lists/linux-omap/msg87523.html
PM:
* 4460pandaes: CORE, L3INIT didn't enter target state
- Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
(ARM: OMAP4: clock/hwmod data: start to remove some IP block control
"clocks")
- Fixed by "ARM: OMAP4: PM: fix PM regression introduced by recent clock
cleanup"
- http://www.spinics.net/lists/arm-kernel/msg224419.html
Failing tests: needing investigation
Build:
* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link
errors
Boot tests:
* 3517EVM & CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
Boot warnings:
* 2430sdp & 37xxevm: nasty lock warning due to NFS root
- Cause unknown
- Breaks most remaining tests
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
- Longstanding issue; does not occur on the 3517EVM
PM tests:
* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
- need to doublecheck wakeup dependencies
- (am assuming it's still there; userspace problems prevent the test
from running, probably due to the lock warning)
* 2430sdp: power domains not entering retention
- Cause unknown
- (am assuming it's still there; userspace problems prevent the test
from running, probably due to the lock warning)
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate ("debug ignore_loglevel")
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter reports this does not appear with the same X-loader/bootloader
on his 4430ES2.3 Panda, so could be ES-level dependent
vmlinux object size
(delta in bytes from test_v3.9-rc2
(f6161aa153581da4a3867a2d1a7caf4be19b6ec9)):
text data bsstotal kernel
+72 -640 +8 n800_multi_omap2xxx
+56 -640 -8 n800_only_a
+5606576 +359420 +121728 +6087724 omap1_defconfig
+108+25920+2700 omap1_defconfig_1510innovator_only
+640+25680+3208 omap2plus_defconfig
+704+25600+3264 omap2plus_defconfig_cpupm
+704+25600+3264 omap2plus_defconfig_no_pm
+640+25600+3200 omap2plus_defconfig_omap2_4_only
+628+25760+3204 omap2p
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
On Monday 18 March 2013 08:37 PM, Will Deacon wrote:
> Hi Santosh,
>
> On Mon, Mar 18, 2013 at 06:51:30AM +, Santosh Shilimkar wrote:
>> On Friday 15 March 2013 10:30 AM, Will Deacon wrote:
>>> Furthermore, I was under the impression that hw_breakpoint did actually
>>> work on panda, which implies that a cold boot *does* manage to reset the
>>> registers (can you please confirm this by looking in your dmesg during
>>> boot?). In that case, it seems as though a PM cycle is powering down a
>>> bunch of debug logic that was powered up during boot, and then we trip over
>>> because we can't access the register bank.
>>>
>> Actually it seems to be without PM. Thanks to analysis from Lokesh, the issue
>> can be seen even with just suspend or cpu hotplug. So cold boot as such is
>> fine.
>
> Right, so what you're saying is that monitor-mode hardware debug only works
> until the first pm/suspend/hotplug operation, then it's dead in the water?
>
>>> The proper solution to this problem requires us to establish exactly what is
>>> turning off the debug registers, and then having an OMAP PM notifier to
>>> enable it again. Assuming this has always been the case, I expect hardware
>>> debug across PM fails silently with older kernels.
>>>
>> This has been always the case it seems with CPU power cycle.
>> After the CPU is power cycled, 'DBGAUTHSTATUS' reads '0xaa' rather
>> than '0xaf' which means 'DBGEN = 0' and hence code fails to enable
>> monitor mode. This happens on both secure and GP devices and it can not
>> be patched since the secure code is ROM'ed. We didn't notice so far
>> because hw_breakpoint support was not default enabled on OMAP till the
>> multi-platform build.
>
> That really sucks :( Does this affect all OMAP-based boards?
>
All OMAP4 based boards..
I was also wondering whether we should just warn once rather
than continuous warnings in the notifier. Patch is end of the
email.
>>>
>>> Could do, but I'd like to see a fix for the real issue before we simply hide
>>> the warnings :)
>>>
>> Agree here too. As evident above, the feature won't work on OMAP4
>> devices with PM and hence some solution is needed.
>>
>> What you think of below ?
>
> Comments inline...
>
>>
>> From d74b4264f6a5967b0f7ada96aad77ab0ac30dbed Mon Sep 17 00:00:00 2001
>> From: Santosh Shilimkar
>> Date: Mon, 18 Mar 2013 11:59:04 +0530
>> Subject: [PATCH] ARM: hw_breakpoints: Check for CPU debug availability before
>> enabling it
>>
>> CPU debug features like hardware break, watchpoints can be used only when
>> the debug mode is enabled and available for non-secure mode.
>>
>> Hence check 'DBGAUTHSTATUS.DBGEN' before proceeding to enable the
>> features.
>>
>> Thanks to Will for pointers and Lokesh for the analysis of the issue on
>> OMAP4 where after a CPU power cycle, debug mode gets disabled.
>>
>> Cc: Will Deacon
>>
>> Tested-by: Lokesh Vutla
>> Signed-off-by: Santosh Shilimkar
>> ---
>> arch/arm/kernel/hw_breakpoint.c |8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/kernel/hw_breakpoint.c
>> b/arch/arm/kernel/hw_breakpoint.c
>> index 96093b7..683a7cf 100644
>> --- a/arch/arm/kernel/hw_breakpoint.c
>> +++ b/arch/arm/kernel/hw_breakpoint.c
>> @@ -930,6 +930,14 @@ static void reset_ctrl_regs(void *unused)
>> int i, raw_num_brps, err = 0, cpu = smp_processor_id();
>> u32 val;
>>
>> +/* Check if we have access to CPU debug features */
>> +ARM_DBG_READ(c7, c14, 6, val);
>> +if ((val & 0x1) == 0) {
>> +pr_warn_once("CPU %d debug is unavailable\n", cpu);
>> +cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu));
>> +return;
>> +}
>
> There are a few of problems here:
>
> 1. That is only checking for non-secure access, which precludes
> running Linux in secure mode.
>
We can check bit 4 as well to take care linux running in secure mode.
> 2. DBGAUTHSTATUS accesses are UNPREDICTABLE when the double-lock is
> set for v7.1 processors.
>
> 3. DBGAUTHSTATUS doesn't exist in ARMv6.
>
We cans skip the code for these versions like...
if (!ARM_DEBUG_ARCH_V7_ECP14 == get_debug_arch())
goto skip_dbgsts_read;
> 4. CPUs without the security extensions have DBGAUTHSTATUS.NSE == 0
>
Which bit is that ? I don't find this bit in Cortex-A9 docs. With all
these checks, may be a separate function like 'is_debug_available()'
would be better.
> 5. Accessing DBGAUTHSTATUS requires DBGEN to be driven high.
> Assuming that your pr_warn_once is emitted, this implies that
> DBGEN is driven high from cold boot, yet the NSE bit is low,
> implying that DBGEN is also low. That's contradictory, so I have
> no idea what's going on...
>
Me neither. The warning is emitted at least.
> Apart from that, it's fine!
>
If you agree, I can update patch accordingly.
BTW, do you have any better trick to take care of
above scenra
Re: [PATCH V3 12/18] ARM: OMAP2+: Add additional GPMC timing parameters
On 03/18/2013 09:32 AM, Jon Hunter wrote: > > On 03/18/2013 09:07 AM, Rob Herring wrote: >> On 03/15/2013 10:21 AM, Jon Hunter wrote: >>> Some of the GPMC timings parameters are currently missing from the GPMC >>> device-tree binding. Add these parameters to the binding documentation >>> as well as code to read them. >>> >>> The existing code in gpmc_read_timings_dt() is checking the value of >>> of_property_read_u32() and only is successful storing the value read >>> in the gpmc_timings structure. Checking the return value in this case >>> is not necessary and we can simply read the value, if present, and >>> store directly in the gpmc_timings structure. Therefore, simplify the >>> code by removing these checks. >>> >>> The comment in the gpmc_read_timings_dt() function, "only for OMAP3430" >>> is also incorrect as it is applicable to all OMAP3+ devices. So correct >>> this too. >>> >>> Signed-off-by: Jon Hunter >>> --- >>> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 25 +- >>> arch/arm/mach-omap2/gpmc.c| 93 >>> ++--- >>> 2 files changed, 66 insertions(+), 52 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt >>> b/Documentation/devicetree/bindings/bus/ti-gpmc.txt >>> index 6fde1cf..a63bd93 100644 >>> --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt >>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt >>> @@ -56,10 +56,27 @@ Timing properties for child nodes. All are optional and >>> default to 0. >>> - gpmc,oe-off:Deassertion time >>> >>> Access time and cycle time timings corresponding to GPMC_CONFIG5: >>> - - gpmc,page-burst-access: Multiple access word delay >>> - - gpmc,access:Start-cycle to first data valid delay >>> - - gpmc,rd-cycle: Total read cycle time >>> - - gpmc,wr-cycle: Total write cycle time >>> + - gpmc,page-burst-access: Multiple access word delay >>> + - gpmc,access:Start-cycle to first data valid delay >>> + - gpmc,rd-cycle: Total read cycle time >>> + - gpmc,wr-cycle: Total write cycle time >>> + - gpmc,bus-turnaround:Turn-around time between successive >>> accesses >>> + - gpmc,cycle2cycle-delay: Delay between chip-select pulses >>> + - gpmc,clk-activation:GPMC clock activation time >>> + - gpmc,wait-monitoring: Start of wait monitoring with regard to valid >>> + data >> >> What units are these in? If in nanoseconds, can you append "-ns" > > These are cycles. I can update the comment to reflect that. Sorry these are nanoseconds. I will update the properties to reflect that. Jon -- 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: OMAP baseline test results for v3.9-rc3
You are not planning any resources to solve this ?
You are listing this for a number of months now. It is time to solve them.
On Mon, Mar 18, 2013 at 5:38 PM, Paul Walmsley wrote:
>
> Here are some basic OMAP test results for Linux v3.9-rc3.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
>
>
> Test summary
>
>
> Build:
> FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
> omap2plus_defconfig_2430sdp_only
> Pass (13/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
> omap1_defconfig_1510innovator_only,
> omap2plus_defconfig, omap2plus_defconfig_cpupm,
> omap2plus_defconfig_no_pm,
> omap2plus_defconfig_omap2_4_only,
> omap2plus_defconfig_omap3_4_only,
> rmk_omap3430_ldp_allnoconfig,
> rmk_omap3430_ldp_oldconfig,
> rmk_omap4430_sdp_allnoconfig
> rmk_omap4430_sdp_oldconfig
>
> Boot to userspace:
> FAIL ( 1/11): am335xbone
> Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
> 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
> 5912osk, cmt3517
>
> PM ret, suspend:
> FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
> Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
>
> PM ret, dynamic idle:
> FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
> Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
>
> PM off, suspend:
> FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
> Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
>
> PM off, dynamic idle:
> FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
> Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
>
>
> Failing tests: fixed by posted patches
> --
>
> Build:
>
> * omap1_defconfig_5912osk_only: implicit declaration of function
> 'cpu_is_omap15xx'
> - Fixed by Aaro: http://www.spinics.net/lists/linux-omap/msg87523.html
>
> PM:
>
> * 4460pandaes: CORE, L3INIT didn't enter target state
> - Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
> (ARM: OMAP4: clock/hwmod data: start to remove some IP block control
> "clocks")
> - Fixed by "ARM: OMAP4: PM: fix PM regression introduced by recent clock
> cleanup"
> - http://www.spinics.net/lists/arm-kernel/msg224419.html
>
> Failing tests: needing investigation
>
>
> Build:
>
> * am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link
> errors
>
> Boot tests:
>
> * 3517EVM & CM-T3517: boot hangs with NFS root
> - Likely some Kconfig, board file, and PM issues with EMAC
> - Longstanding bug
>
> Boot warnings:
>
> * 2430sdp & 37xxevm: nasty lock warning due to NFS root
> - Cause unknown
> - Breaks most remaining tests
>
> * CM-T3517: L3 in-band error with IPSS during boot
> - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
> - Longstanding issue; does not occur on the 3517EVM
>
> PM tests:
>
> * 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
> - need to doublecheck wakeup dependencies
> - (am assuming it's still there; userspace problems prevent the test
> from running, probably due to the lock warning)
>
> * 2430sdp: power domains not entering retention
> - Cause unknown
> - (am assuming it's still there; userspace problems prevent the test
> from running, probably due to the lock warning)
>
> * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
>
> * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
>
> * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
> - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
> per discussion with Tero Kristo
> - Likely dependent on the bootloader version
> - fails with 2012.07-00136-g755de79
>
> * 4460pandaes: chip not entering retention in dynamic idle
> - Presumably 4430es2panda also fails this
> - Suspend-to-RAM enters full chip retention
>
> * 3730 Beagle XM: does not serial wake from off-idle suspend when console
> UART doesn't clock-gate ("debug ignore_loglevel")
> - Cause unknown
> - Not yet part of the automated test suite
> - Re-tested at v3.7; still failing:
>
> http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
>
> Other:
>
> * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
> - Unknown cause; could be due to the lack of hierarchical enable/disable
> in hwmod code
> - Jon Hunter reports this does not appear with the same X-loader/bootloader
> on his 4430ES2.3 Panda, so could be ES-level dependent
>
>
> vmlinux object size
> (delta in bytes from test_v3.9-rc2
> (f6161aa153581da4a3867a2d1a7caf4be19b6ec9)):
>text data bsstotal kernel
> +72 -640 +8 n800_multi_omap2xxx
> +56 -640 -8 n800_on
Re: OMAP baseline test results for v3.9-rc3
On Mon, 18 Mar 2013, Anca Emanuel wrote: > You are not planning any resources to solve this ? > You are listing this for a number of months now. It is time to solve them. Absolutely, thanks for volunteering! Patches welcome. - 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: [RFC] Kbuild support for ARM FIT images
On Fri 2013-02-22 08:00:44, Olof Johansson wrote: > On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: > > Any comments on this approach? Is it better to merge mkfitsrc.sh with > > mkuboot.sh? > > I know this was discussed quite extensively yesterday, but here is my take on > it: > > Given the recent complications from multiplatform, we really saw a strong > reason to _not_ do the final boot wrapping in the kernel build system. > Produce the zImage and the DTB files, and have a surrounding script that > bundles the two in a format that your particular device needs. > > Most distros have scripts to handle the "make install" step of a kernel build. > That's where this belongs, not in the actual build step. Not sure I agree here: 1) zImage was designed to boot from floppy, without any kind of bootloader on i386 2) There are no distributions on many embedded systems. And no good place where to store the scripts. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH 2/2] ARM: OMAP2+: clocks: Pass static parent pointers to common clock core
* Rajendra Nayak [130318 01:25]: > On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote: > > * Rajendra Nayak [130315 05:31]: > >> On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote: > >>> * Rajendra Nayak [130314 05:44]: > OMAP clock inits happen quite early, even before the slab is available. > As part of the clock init, the common clock core tries to cache parent > pointers (if not passed by the caller registering the clock) which > fails in case of OMAP since the slab isn't initied. > Without CONFIG_DEBUG_SLAB enabled, this just results in the common clock > core > retrying the caching attempt at some point later. > However with CONFIG_DEBUG_SLAB enabled this results in a BUG() as > reported > in the link below by Tony.. > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html > > Fix this by passing static parent pointers to the common clock core > while registering clocks. > >>> > >>> I wonder if we could easily fix this by initializing only some of the > >>> clocks that early? > >> > >> We actually don't need any clocks that early (I mean even before slab init) > >> We only need them before timer init. > > > > Yes and only the timer clocks at that point. The others could be initialized > > later on so we get console error messages without having to turn on DEBUG_LL > > and earlyprintk. > > but that wouldn't be possible with the hwmod dependency on clocks. We would > need to move the hwmod inits further down too. > > > > >> This isn't something specific to OMAP so I started looking at what others > >> in drivers/clk seem to do. > >> > >> I found imx, spear, mvebu all do their clk inits within .init_time > >> callbacks. > >> tegra seems to even do it within .init_irq callback. > >> > >> Either one would work for us too :) > > > > Well I suggest init_irq as that's when we need the first clocks for timer. > > For which platforms? I instead see them being needed only by init_timer, so > was thinking thats a better place instead. > > For the -rc fix to fix the crash with DEBUG_SLAB, is it fine if I move *all* > clock inits down to init_timer (or init_irq). Sounds good to me for the -rc series. How about initialize omap_clk_init() function pointer in the SoC specific omap*_init_early() then just call omap_clk_init() in timer_init? > Splitting clocks alone would not work for now, without hwmod being moved down > also. Good point. For the -rc series the sounds like your suggestion is the least intrusive fix and also gets us started removing few more early boot time dependencies. 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: [PATCH 1/8] staging: omap-thermal: fix return value
Thanks. Acked-by: Dan Carpenter regards, dan carpenter -- 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 v3 0/4] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros [130318 05:55]: > Hi Tony, > > I've revised the patches based on your comments. For now I've just > adapted Panda and Beagleboard. > If this looks OK then I can adapt the other boards as well. Thanks yes looks good to me now. 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] Kbuild support for ARM FIT images
On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote: > On Fri 2013-02-22 08:00:44, Olof Johansson wrote: > > On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: > > > Any comments on this approach? Is it better to merge mkfitsrc.sh with > > > mkuboot.sh? > > > > I know this was discussed quite extensively yesterday, but here is my take > > on > > it: > > > > Given the recent complications from multiplatform, we really saw a strong > > reason to _not_ do the final boot wrapping in the kernel build system. > > Produce the zImage and the DTB files, and have a surrounding script that > > bundles the two in a format that your particular device needs. > > > > Most distros have scripts to handle the "make install" step of a kernel > > build. > > That's where this belongs, not in the actual build step. > > Not sure I agree here: > > 1) zImage was designed to boot from floppy, without any kind of > bootloader on i386 zImage on x86 != zImage on ARM. They only share the fact that they're both compressed and self-extracting. ARM has never supported any kind of floppy based boot - mainly because floppies have never been "executable" like they are on x86; all that previous boot loaders ever did was load the kernel into RAM using some method and call address 0, with a data structure (formerly struct params, later atags) at a fixed address, later passing that address to the kernel. The best floppies got was being able to run a script or load an executable off the floppy under the ROM'd OS, and our zImage itself doesn't fit the format required for that. Our zImage has always been just a pure straight binary compressed kernel format. Nothing more. -- 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: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
On Mon, Mar 18, 2013 at 03:46:28PM +, Santosh Shilimkar wrote:
> On Monday 18 March 2013 08:37 PM, Will Deacon wrote:
> > That really sucks :( Does this affect all OMAP-based boards?
> >
> All OMAP4 based boards..
Brilliant. Is there any way that the secure code can be fixed in future
products?
> >> + /* Check if we have access to CPU debug features */
> >> + ARM_DBG_READ(c7, c14, 6, val);
> >> + if ((val & 0x1) == 0) {
> >> + pr_warn_once("CPU %d debug is unavailable\n", cpu);
> >> + cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu));
> >> + return;
> >> + }
> >
> > There are a few of problems here:
> >
> > 1. That is only checking for non-secure access, which precludes
> >running Linux in secure mode.
> >
> We can check bit 4 as well to take care linux running in secure mode.
It still doesn't help unless we know whether Linux is running secure or
non-secure.
> > 2. DBGAUTHSTATUS accesses are UNPREDICTABLE when the double-lock is
> >set for v7.1 processors.
> >
> > 3. DBGAUTHSTATUS doesn't exist in ARMv6.
> >
> We cans skip the code for these versions like...
> if (!ARM_DEBUG_ARCH_V7_ECP14 == get_debug_arch())
> goto skip_dbgsts_read;
Sure, I was just pointing out that the code needs fixing for this.
> > 4. CPUs without the security extensions have DBGAUTHSTATUS.NSE == 0
> >
> Which bit is that ? I don't find this bit in Cortex-A9 docs. With all
> these checks, may be a separate function like 'is_debug_available()'
> would be better.
NSE is bit 0 (the one you're checking).
>
> > 5. Accessing DBGAUTHSTATUS requires DBGEN to be driven high.
> >Assuming that your pr_warn_once is emitted, this implies that
> >DBGEN is driven high from cold boot, yet the NSE bit is low,
> >implying that DBGEN is also low. That's contradictory, so I have
> >no idea what's going on...
> >
> Me neither. The warning is emitted at least.
Any chance you could follow up with your firmware/hardware guys about this
please? I'd really like to understand how we end up in this state in case we
can do something in the architecture to stop it from happening in future.
> > Apart from that, it's fine!
> >
> If you agree, I can update patch accordingly.
> BTW, do you have any better trick to take care of
> above scenraio ?
Well, we could just add the warn_once prints but that doesn't stop debug
from breaking after the first pm/suspend/hotplug operation.
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
Re: OMAP baseline test results for v3.9-rc3
On Mon, 18 Mar 2013, Paul Walmsley wrote: > On Mon, 18 Mar 2013, Anca Emanuel wrote: > > > You are not planning any resources to solve this ? > > You are listing this for a number of months now. It is time to solve them. > > Absolutely, thanks for volunteering! Patches welcome. Also, if you are a TI customer, you can probably contact your TI rep and put pressure on them to put more resources into their upstream kernel support. - 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 1/8] staging: omap-thermal: fix return value
Dan, On 18-03-2013 12:39, Dan Carpenter wrote: Thanks. Acked-by: Dan Carpenter regards, dan carpenter Thanks for taking the time to check this code. Eduardo -- 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] Kbuild support for ARM FIT images
On Mon 2013-03-18 16:44:26, Russell King - ARM Linux wrote: > On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote: > > On Fri 2013-02-22 08:00:44, Olof Johansson wrote: > > > On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: > > > > Any comments on this approach? Is it better to merge mkfitsrc.sh with > > > > mkuboot.sh? > > > > > > I know this was discussed quite extensively yesterday, but here is my > > > take on > > > it: > > > > > > Given the recent complications from multiplatform, we really saw a strong > > > reason to _not_ do the final boot wrapping in the kernel build system. > > > Produce the zImage and the DTB files, and have a surrounding script that > > > bundles the two in a format that your particular device needs. > > > > > > Most distros have scripts to handle the "make install" step of a kernel > > > build. > > > That's where this belongs, not in the actual build step. > > > > Not sure I agree here: > > > > 1) zImage was designed to boot from floppy, without any kind of > > bootloader on i386 > > zImage on x86 != zImage on ARM. > > They only share the fact that they're both compressed and self-extracting. > > ARM has never supported any kind of floppy based boot - mainly because > floppies have never been "executable" like they are on x86; all that > previous boot loaders ever did was load the kernel into RAM using > some Yes, I know. That's why I said "on i386". What I wanted to say is that kernel build traditionaly produced something useful, something bootloader can actually boot. Currently, make uImage produces u-boot image. Please keep that capability. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] Kbuild support for ARM FIT images
On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote: > What I wanted to say is that kernel build traditionaly produced > something useful, something bootloader can actually boot. Currently, > make uImage produces u-boot image. Please keep that capability. Unfortunately, there is a fundamental problem with uImage. It encodes the load address, and that is utterly incompatible with the goal of having a kernel image which boots on multiple platforms. uImage isn't going anywhere for the time being, but you will find that: a) recent kernels will just wrap the zImage without a DTB, so appended DTBs can't be used with it b) it won't work with MULTIPLATFORM-enabled kernels, unless you provide make with a LOADADDR= argument to tell it where the uImage is to be loaded - which is platform specific. (b) fundamentally can't be solved in kbuild. If you want to use uImage with multiple platforms from the same zImage, then you need to generate multiple uImage files with different load addresses. That's purely - and solely - down to the dysfunctional uImage format. -- 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] Kbuild support for ARM FIT images
On Mon 2013-03-18 17:57:46, Russell King - ARM Linux wrote: > On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote: > > What I wanted to say is that kernel build traditionaly produced > > something useful, something bootloader can actually boot. Currently, > > make uImage produces u-boot image. Please keep that capability. > > Unfortunately, there is a fundamental problem with uImage. It encodes > the load address, and that is utterly incompatible with the goal of > having a kernel image which boots on multiple platforms. > > uImage isn't going anywhere for the time being, but you will find > that: > > a) recent kernels will just wrap the zImage without a DTB, so >appended DTBs can't be used with it > b) it won't work with MULTIPLATFORM-enabled kernels, unless you >provide make with a LOADADDR= argument to tell it where the >uImage is to be loaded - which is platform specific. > > (b) fundamentally can't be solved in kbuild. If you want to use > uImage with multiple platforms from the same zImage, then you need > to generate multiple uImage files with different load addresses. > That's purely - and solely - down to the dysfunctional uImage format. I know. uImage is not perfect. But solution should be "adopt a better format" (ARM FIT?), not "drop support for making useful images altogether" as Olof proposed before. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 03/18/2013 12:04 PM, Pavel Machek wrote: > On Mon 2013-03-18 17:57:46, Russell King - ARM Linux wrote: >> On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote: >>> What I wanted to say is that kernel build traditionaly produced >>> something useful, something bootloader can actually boot. Currently, >>> make uImage produces u-boot image. Please keep that capability. >> >> Unfortunately, there is a fundamental problem with uImage. It encodes >> the load address, and that is utterly incompatible with the goal of >> having a kernel image which boots on multiple platforms. >> >> uImage isn't going anywhere for the time being, but you will find >> that: >> >> a) recent kernels will just wrap the zImage without a DTB, so >>appended DTBs can't be used with it >> b) it won't work with MULTIPLATFORM-enabled kernels, unless you >>provide make with a LOADADDR= argument to tell it where the >>uImage is to be loaded - which is platform specific. >> >> (b) fundamentally can't be solved in kbuild. If you want to use >> uImage with multiple platforms from the same zImage, then you need >> to generate multiple uImage files with different load addresses. >> That's purely - and solely - down to the dysfunctional uImage format. > > I know. uImage is not perfect. But solution should be "adopt a better > format" (ARM FIT?), not "drop support for making useful images > altogether" as Olof proposed before. Raw zImage /is/ the useful format that should be adopted. -- 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: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote: > On Fri 2013-02-22 08:00:44, Olof Johansson wrote: > > On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: > > > Any comments on this approach? Is it better to merge mkfitsrc.sh with > > > mkuboot.sh? > > > > I know this was discussed quite extensively yesterday, but here is my take > > on > > it: > > > > Given the recent complications from multiplatform, we really saw a strong > > reason to _not_ do the final boot wrapping in the kernel build system. > > Produce the zImage and the DTB files, and have a surrounding script that > > bundles the two in a format that your particular device needs. > > > > Most distros have scripts to handle the "make install" step of a kernel > > build. > > That's where this belongs, not in the actual build step. > > Not sure I agree here: Lets try and stop this again here. I think perhaps the KVM tool example is instructive here. For the various reasons that close association with the kernel can be helpful for things (the exposure and ease of being found), it would be nice if the tooling to expand single kernel image into single "bootable" image was with the kernel. But it's not a requirement. And it's not even necessarily the best for the tooling either. So, lets drop the idea of getting this into the kernel and if people really do wish to extend FIT such that we can easily spit out a FIT image that works on omap* and tegra* or what have you, and add a FIT parser to GRUB, great, get to work. No need to be tied to the kernel for this. -- Tom signature.asc Description: Digital signature
Re: [PATCH 1/2] driver: serial-omap: move max uart count into generic header file.
Sourav Poddar writes:
> OMAP_MAX_HSUART_PORTS is moved to omap_serial header file.
Why?
You started to explain it in the cover letter, but a full description
belongs here for the permanent git history.
Kevin
> Cc: Santosh Shilimkar
> Cc: Felipe Balbi
> Cc: Rajendra nayak
> Signed-off-by: Sourav Poddar
> ---
> drivers/tty/serial/omap-serial.c |2 --
> include/linux/platform_data/serial-omap.h |1 +
> 2 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index 5722eaf..4c2ba9f 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -43,8 +43,6 @@
> #include
> #include
>
> -#define OMAP_MAX_HSUART_PORTS6
> -
> #define UART_BUILD_REVISION(x, y)(((x) << 8) | (y))
>
> #define OMAP_UART_REV_42 0x0402
> diff --git a/include/linux/platform_data/serial-omap.h
> b/include/linux/platform_data/serial-omap.h
> index ff9b0aa..92c48c2 100644
> --- a/include/linux/platform_data/serial-omap.h
> +++ b/include/linux/platform_data/serial-omap.h
> @@ -29,6 +29,7 @@
> * is used as console uart.
> */
> #define OMAP_SERIAL_NAME "ttyO"
> +#define OMAP_MAX_HSUART_PORTS 6
>
> struct omap_uart_port_info {
> booldma_enabled;/* To specify DMA Mode */
--
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/8] staging: omap-thermal: use spin_lock_irqsave inside IRQ handler
On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote: > Even if the IRQ is not firing because it is ONE_SHOT and disable > at INTC level, the IRQ handler must use spin_lock_irqsave. > It is necessary to disable IRQs from the current > CPU while it is holding a spin_lock which is need. > Gar... I think I was just totally wrong on this. I think your original code was fine. Sorry Eduardo and Greg. This is a threaded IRQ so the regular spin_lock is fine or even the mutex would have been. IRQ_ONESHOT is about triggering a second IRQ before the first one has been finished, btw. I am an idiot. regards, dan carpenter -- 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/8] staging: rename omap-thermal driver to ti-soc-thermal
On Mon, Mar 18, 2013 at 10:59:12AM -0400, Eduardo Valentin wrote: > Because this driver will support also OMAP derivatives, > this patch does a big rename inside this driver, so it > better fits its usage. > It would be better to do a minimal move patch which just renames the files and updated the Makefile. The following patches would rename the functions. That makes it easier to review. > Cc: Santosh Shilimkar > Cc: Benoit > Cc: Nishanth Menon > > Signed-off-by: Eduardo Valentin Put a --- line here after the Signed-off-by line so that "git am" doesn't include the diff stat in the changelog. regards, dan carpenter -- 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/8] staging: omap-thermal: use spin_lock_irqsave inside IRQ handler
On 18-03-2013 15:16, Dan Carpenter wrote: On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote: Even if the IRQ is not firing because it is ONE_SHOT and disable at INTC level, the IRQ handler must use spin_lock_irqsave. It is necessary to disable IRQs from the current CPU while it is holding a spin_lock which is need. Gar... I think I was just totally wrong on this. I think your original code was fine. Sorry Eduardo and Greg. This is a threaded IRQ so the regular spin_lock is fine or even the mutex would have been. In fact it is. But I rather prefer to use spinlocks there, just to keep the irq handler sane, even if it is moved to non-threaded IRQ. IRQ_ONESHOT is about triggering a second IRQ before the first one has been finished, btw. It is, and that gets done by masking the IRQ at INTC level. I am an idiot. Not really. Thanks for your time reviewing the driver. I will resend this series. Drop this one and split patch 4/8 into two I think (one for moving files, one for renaming functions) regards, dan carpenter -- 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] Kbuild support for ARM FIT images
Dear Russell, In message <20130318175746.gj30...@n2100.arm.linux.org.uk> you wrote: > > Unfortunately, there is a fundamental problem with uImage. It encodes > the load address, and that is utterly incompatible with the goal of > having a kernel image which boots on multiple platforms. I'm not sure if you are aware that U-Boot supports uImages that can be run from _any_ load address (using the IH_TYPE_KERNEL_NOLOAD image type). If anybody was willing to keep uImage support in the kernel this would probably be a convenient way to go. But in any case, the uImage format is deprecated. Support for FIT images was added more than five years ago, and new developments should rather focus on supporting these. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de -- 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: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Stephen, In message <51475997.2060...@wwwdotorg.org> you wrote: > > Raw zImage /is/ the useful format that should be adopted. This "one size fits all" approch does fit everywhere. There are a number of users (including _big_ commercial ones, with _large_ numebrs of systems in the field) that have simple requirements like: - how can I find out if the image I just loaded to RAM in OK (OK maning some checksum is correct, or some crypto-key could be verified, or ...) ? - how can I find out which version of image is installed on this device in the flash? Can I print something like an ID string, or a build timestamp, etc? etc. etc. zImage may work well in many cases, but there are also many cases where in image format that allows for additional meta-data is mandatory. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Minds are like parachutes - they only function when open. -- 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/8] staging: omap-thermal: use spin_lock_irqsave inside IRQ handler
On Mon, Mar 18, 2013 at 03:38:38PM -0400, Eduardo Valentin wrote: > On 18-03-2013 15:16, Dan Carpenter wrote: > >On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote: > >>Even if the IRQ is not firing because it is ONE_SHOT and disable > >>at INTC level, the IRQ handler must use spin_lock_irqsave. > >>It is necessary to disable IRQs from the current > >>CPU while it is holding a spin_lock which is need. > >> > > > >Gar... I think I was just totally wrong on this. I think your > >original code was fine. Sorry Eduardo and Greg. > > > >This is a threaded IRQ so the regular spin_lock is fine or even the > >mutex would have been. > > In fact it is. But I rather prefer to use spinlocks there, just to > keep the irq handler sane, even if it is moved to non-threaded IRQ. Yep. I'd agree there. > > > > >IRQ_ONESHOT is about triggering a second IRQ before the first one > >has been finished, btw. > > It is, and that gets done by masking the IRQ at INTC level. > > > > >I am an idiot. > > > Not really. Thanks for your time reviewing the driver. > > I will resend this series. Drop this one and split patch 4/8 into > two I think (one for moving files, one for renaming functions) Great. Much appreciated. regards, dan carpenter -- 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 6/8] SERIAL: OMAP: Remove the slave idle handling from the driver
On Thu, Mar 14, 2013 at 03:07:01PM +0530, Santosh Shilimkar wrote: > (Looping Greg KH.) > > Greg, > > On Wednesday 20 February 2013 09:14 PM, Santosh Shilimkar wrote: > > On Wednesday 20 February 2013 08:54 PM, Kevin Hilman wrote: > >> Santosh Shilimkar writes: > >> > >>> UART IP slave idle handling now taken care by runtime pm backend(hwmod > >>> layer) > >>> so remove the hackery from the driver. > >>> > >>> Tested-by: Vaibhav Bedia > >>> Tested-by: Sourav Poddar > >>> Signed-off-by: Rajendra nayak > >>> Signed-off-by: Santosh Shilimkar > >>> > >>> --- > >>> drivers/tty/serial/omap-serial.c | 23 --- > >>> 1 file changed, 23 deletions(-) > >> > >> This patch should also remove the hooks from > >> > >> > > Right. Will fix that in next version. Thanks. > > > Sorry for not CC'ing first place > The subject patch is part of the series which cleans up the slave > idle handling from OMAP serial driver. It will be best to queue > it along with rest of the patches with your ack on $subject patch. > > Here is the updated version which also removed the hooks > from 'linux/platform_data/serial-omap.h' as per Kevin suggestion. > > >From 92916b8e0d895962c88fefbf99284967a4b94426 Mon Sep 17 00:00:00 2001 > From: Santosh Shilimkar > Date: Fri, 15 Feb 2013 15:50:37 +0530 > Subject: [PATCH 6/8] SERIAL: OMAP: Remove the slave idle handling from the > driver > > UART IP slave idle handling now taken care by runtime pm backend(hwmod layer) > so remove the hackery from the driver. > > Cc: Greg Kroah-Hartman > > Tested-by: Vaibhav Bedia > Tested-by: Sourav Poddar > Signed-off-by: Rajendra nayak > Signed-off-by: Santosh Shilimkar Acked-by: Greg Kroah-Hartman -- 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: OMAP2+: clocks: Pass static parent pointers to common clock core
Quoting Tony Lindgren (2013-03-18 09:37:58) > * Rajendra Nayak [130318 01:25]: > > On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote: > > > * Rajendra Nayak [130315 05:31]: > > >> On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote: > > >>> * Rajendra Nayak [130314 05:44]: > > OMAP clock inits happen quite early, even before the slab is available. > > As part of the clock init, the common clock core tries to cache parent > > pointers (if not passed by the caller registering the clock) which > > fails in case of OMAP since the slab isn't initied. > > Without CONFIG_DEBUG_SLAB enabled, this just results in the common > > clock core > > retrying the caching attempt at some point later. > > However with CONFIG_DEBUG_SLAB enabled this results in a BUG() as > > reported > > in the link below by Tony.. > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html > > > > Fix this by passing static parent pointers to the common clock core > > while registering clocks. > > >>> > > >>> I wonder if we could easily fix this by initializing only some of the > > >>> clocks that early? > > >> > > >> We actually don't need any clocks that early (I mean even before slab > > >> init) > > >> We only need them before timer init. > > > > > > Yes and only the timer clocks at that point. The others could be > > > initialized > > > later on so we get console error messages without having to turn on > > > DEBUG_LL > > > and earlyprintk. > > > > but that wouldn't be possible with the hwmod dependency on clocks. We would > > need to move the hwmod inits further down too. > > > > > > > >> This isn't something specific to OMAP so I started looking at what others > > >> in drivers/clk seem to do. > > >> > > >> I found imx, spear, mvebu all do their clk inits within .init_time > > >> callbacks. > > >> tegra seems to even do it within .init_irq callback. > > >> > > >> Either one would work for us too :) > > > > > > Well I suggest init_irq as that's when we need the first clocks for timer. > > > > For which platforms? I instead see them being needed only by init_timer, so > > was thinking thats a better place instead. > > > > For the -rc fix to fix the crash with DEBUG_SLAB, is it fine if I move *all* > > clock inits down to init_timer (or init_irq). > > Sounds good to me for the -rc series. How about initialize omap_clk_init() > function pointer in the SoC specific omap*_init_early() then just call > omap_clk_init() in timer_init? > > > Splitting clocks alone would not work for now, without hwmod being moved > > down also. > > Good point. For the -rc series the sounds like your suggestion is the > least intrusive fix and also gets us started removing few more early > boot time dependencies. > +1 for removing the early init dependencies. hwmod initialization was the original impetus for all this static struct clk stuff. If the initialization for hwmod and the omap clocks can be moved to a later callback then it is the first step in removing the static data and getting rid of clk-private.h usage. Regards, Mike > 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: [PATCH 2/2] ARM: OMAP2+: clocks: Pass static parent pointers to common clock core
On Tuesday 19 March 2013 06:53 AM, Mike Turquette wrote: > Quoting Tony Lindgren (2013-03-18 09:37:58) >> * Rajendra Nayak [130318 01:25]: >>> On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote: * Rajendra Nayak [130315 05:31]: > On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote: >> * Rajendra Nayak [130314 05:44]: >>> OMAP clock inits happen quite early, even before the slab is available. >>> As part of the clock init, the common clock core tries to cache parent >>> pointers (if not passed by the caller registering the clock) which >>> fails in case of OMAP since the slab isn't initied. >>> Without CONFIG_DEBUG_SLAB enabled, this just results in the common >>> clock core >>> retrying the caching attempt at some point later. >>> However with CONFIG_DEBUG_SLAB enabled this results in a BUG() as >>> reported >>> in the link below by Tony.. >>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html >>> >>> Fix this by passing static parent pointers to the common clock core >>> while registering clocks. >> >> I wonder if we could easily fix this by initializing only some of the >> clocks that early? > > We actually don't need any clocks that early (I mean even before slab > init) > We only need them before timer init. Yes and only the timer clocks at that point. The others could be initialized later on so we get console error messages without having to turn on DEBUG_LL and earlyprintk. >>> >>> but that wouldn't be possible with the hwmod dependency on clocks. We would >>> need to move the hwmod inits further down too. >>> > This isn't something specific to OMAP so I started looking at what others > in drivers/clk seem to do. > > I found imx, spear, mvebu all do their clk inits within .init_time > callbacks. > tegra seems to even do it within .init_irq callback. > > Either one would work for us too :) Well I suggest init_irq as that's when we need the first clocks for timer. >>> >>> For which platforms? I instead see them being needed only by init_timer, so >>> was thinking thats a better place instead. >>> >>> For the -rc fix to fix the crash with DEBUG_SLAB, is it fine if I move *all* >>> clock inits down to init_timer (or init_irq). >> >> Sounds good to me for the -rc series. How about initialize omap_clk_init() >> function pointer in the SoC specific omap*_init_early() then just call >> omap_clk_init() in timer_init? >> >>> Splitting clocks alone would not work for now, without hwmod being moved >>> down also. >> >> Good point. For the -rc series the sounds like your suggestion is the >> least intrusive fix and also gets us started removing few more early >> boot time dependencies. >> > > +1 for removing the early init dependencies. hwmod initialization was > the original impetus for all this static struct clk stuff. If the > initialization for hwmod and the omap clocks can be moved to a later > callback then it is the first step in removing the static data and > getting rid of clk-private.h usage. I am working on that stuff to get rid of the dependency on clk-private.h Will post some RFC soon once I have omap4 working and if the approach seems fine, will move over all of omap so you can delete the clk-private.h completely :) > > Regards, > Mike > >> 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: OMAP baseline test results for v3.9-rc2
Hi, restating these to reflect some bugfixes in the test log parsing scripts. On Thu, 14 Mar 2013, Paul Walmsley wrote: > vmlinux object size > (delta in bytes from test_v3.9-rc1 > (6dbe51c251a327e012439c4772097a13df43c5b8)): >text data bsstotal kernel > +13528 +640 +13592 omap1_defconfig > +9440 +1200+9560 omap2plus_defconfig > +13472 +1280 +13600 omap2plus_defconfig_cpupm > +13472 +1280 +13600 omap2plus_defconfig_omap2_4_only > +9756 +1200+9876 omap2plus_defconfig_omap3_4_only >+704 -64 -188 +452 rmk_omap3430_ldp_allnoconfig >+556 -640 +492 rmk_omap4430_sdp_oldconfig The correct and complete delta should be: vmlinux object size (delta in bytes from test_v3.9-rc1 (6dbe51c251a327e012439c4772097a13df43c5b8)): text data bsstotal kernel +620 -72 +4 +552 n800_multi_omap2xxx +5860 +648 +12+6520 n800_only_a +9180 +880+9268 omap1_defconfig_1510innovator_only +9440 +1200+9560 omap2plus_defconfig +13472 +1280 +13600 omap2plus_defconfig_cpupm +13528 +640 +13592 omap2plus_defconfig_no_pm +13472 +1280 +13600 omap2plus_defconfig_omap2_4_only +9756 +1200+9876 omap2plus_defconfig_omap3_4_only +704 -64 -188 +452 rmk_omap3430_ldp_allnoconfig +656 -640 +592 rmk_omap3430_ldp_oldconfig +704 -64 -188 +452 rmk_omap4430_sdp_allnoconfig +556 -640 +492 rmk_omap4430_sdp_oldconfig - 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: OMAP baseline test results for v3.9-rc1
Hi, here's the restated delta from v3.8 -> v3.9-rc1, after some script bug fixes. On Tue, 12 Mar 2013, Paul Walmsley wrote: > vmlinux object size > (delta in bytes from test_v3.8 (19f949f52599ba7c3f67a5897ac6be14bfcb1200)): >text data bsstotal kernel > +195310 +37968+1364 +234642 omap2plus_defconfig > +185362 +37128+1364 +223854 omap2plus_defconfig_cpupm > +186719 +31416+1300 +219435 omap2plus_defconfig_omap2_4_only > +181125 +41432+1300 +223857 omap2plus_defconfig_omap3_4_only > +10460 +10272+1184 +21916 rmk_omap3430_ldp_allnoconfig > +40867 +14672 +972 +56511 rmk_omap4430_sdp_oldconfig > > Looks like v3.9 is well on target to exceed even the previous > per-release bloat records. > > There are some entries missing from the above table; this is probably due > to some bug in my scripts that needs to be dealt with. And here's the correct results. vmlinux object size (delta in bytes from test_v3.8 (19f949f52599ba7c3f67a5897ac6be14bfcb1200)): text data bsstotal kernel -557629 +23472-9252 -543409 n800_multi_omap2xxx -557204 +26680-9280 -539804 n800_only_a +49056+2992 +424 +52472 omap1_defconfig_1510innovator_only +195310 +37968+1364 +234642 omap2plus_defconfig +185362 +37128+1364 +223854 omap2plus_defconfig_cpupm +192610 +36304+1364 +230278 omap2plus_defconfig_no_pm +186719 +31416+1300 +219435 omap2plus_defconfig_omap2_4_only +181125 +41432+1300 +223857 omap2plus_defconfig_omap3_4_only +10460 +10272+1184 +21916 rmk_omap3430_ldp_allnoconfig +40004 +27640 +788 +68432 rmk_omap3430_ldp_oldconfig +10348 +10272+1296 +21916 rmk_omap4430_sdp_allnoconfig +40867 +14672 +972 +56511 rmk_omap4430_sdp_oldconfig The massive decrease in N800 kernel size is a result of an all-out attempt to keep the kernel booting on N800, which has a 2MB kernel size limitation in the bootloader. Same crazy bloat in the OMAP2+ kernels, and it's probably due to the CONFIG_ARCH_MULTIPLATFORM changes. Hey, at least we don't have to worry about supporting embedded use-cases any more on ARM ;-) - 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 1/2] driver: serial-omap: move max uart count into generic header file.
Hi Kevin,
On Tuesday 19 March 2013 12:15 AM, Kevin Hilman wrote:
Sourav Poddar writes:
OMAP_MAX_HSUART_PORTS is moved to omap_serial header file.
Why?
The patch is a prerequisitive for the next patch in the series, where I am
making use of the max number of uarts, omap device supports. Hence, I
am rearranging the macro from a driver file to a header file. So, it can
be used at
multiple places.
You started to explain it in the cover letter, but a full description
belongs here for the permanent git history.
Sure, I will add the complete description for this here itself in my next
version.
Kevin
Cc: Santosh Shilimkar
Cc: Felipe Balbi
Cc: Rajendra nayak
Signed-off-by: Sourav Poddar
---
drivers/tty/serial/omap-serial.c |2 --
include/linux/platform_data/serial-omap.h |1 +
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 5722eaf..4c2ba9f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,8 +43,6 @@
#include
#include
-#define OMAP_MAX_HSUART_PORTS 6
-
#define UART_BUILD_REVISION(x, y) (((x)<< 8) | (y))
#define OMAP_UART_REV_42 0x0402
diff --git a/include/linux/platform_data/serial-omap.h
b/include/linux/platform_data/serial-omap.h
index ff9b0aa..92c48c2 100644
--- a/include/linux/platform_data/serial-omap.h
+++ b/include/linux/platform_data/serial-omap.h
@@ -29,6 +29,7 @@
* is used as console uart.
*/
#define OMAP_SERIAL_NAME "ttyO"
+#define OMAP_MAX_HSUART_PORTS 6
struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
--
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 6/8] SERIAL: OMAP: Remove the slave idle handling from the driver
On Tuesday 19 March 2013 05:41 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 14, 2013 at 03:07:01PM +0530, Santosh Shilimkar wrote: >> (Looping Greg KH.) >> >> Greg, >> [..] >>> >> Sorry for not CC'ing first place >> The subject patch is part of the series which cleans up the slave >> idle handling from OMAP serial driver. It will be best to queue >> it along with rest of the patches with your ack on $subject patch. >> >> Here is the updated version which also removed the hooks >> from 'linux/platform_data/serial-omap.h' as per Kevin suggestion. >> >> >From 92916b8e0d895962c88fefbf99284967a4b94426 Mon Sep 17 00:00:00 2001 >> From: Santosh Shilimkar >> Date: Fri, 15 Feb 2013 15:50:37 +0530 >> Subject: [PATCH 6/8] SERIAL: OMAP: Remove the slave idle handling from the >> driver >> >> UART IP slave idle handling now taken care by runtime pm backend(hwmod layer) >> so remove the hackery from the driver. >> >> Cc: Greg Kroah-Hartman >> >> Tested-by: Vaibhav Bedia >> Tested-by: Sourav Poddar >> Signed-off-by: Rajendra nayak >> Signed-off-by: Santosh Shilimkar > > Acked-by: Greg Kroah-Hartman > Thanks Greg !! 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: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
On Monday 18 March 2013 10:36 PM, Will Deacon wrote:
> On Mon, Mar 18, 2013 at 03:46:28PM +, Santosh Shilimkar wrote:
>> On Monday 18 March 2013 08:37 PM, Will Deacon wrote:
>>> That really sucks :( Does this affect all OMAP-based boards?
>>>
>> All OMAP4 based boards..
>
> Brilliant. Is there any way that the secure code can be fixed in future
> products?
>
Nope. This can only be done with new silicon rev for GP devices which is
not going to happen. For secure devices, some secure patching is possible
but these are not development devices, so not much point.
+ /* Check if we have access to CPU debug features */
+ ARM_DBG_READ(c7, c14, 6, val);
+ if ((val & 0x1) == 0) {
+ pr_warn_once("CPU %d debug is unavailable\n", cpu);
+ cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu));
+ return;
+ }
>>>
>>> There are a few of problems here:
>>>
>>> 1. That is only checking for non-secure access, which precludes
>>>running Linux in secure mode.
>>>
>> We can check bit 4 as well to take care linux running in secure mode.
>
> It still doesn't help unless we know whether Linux is running secure or
> non-secure.
>
ok.
>>> 2. DBGAUTHSTATUS accesses are UNPREDICTABLE when the double-lock is
>>>set for v7.1 processors.
>>>
>>> 3. DBGAUTHSTATUS doesn't exist in ARMv6.
>>>
>> We cans skip the code for these versions like...
>> if (!ARM_DEBUG_ARCH_V7_ECP14 == get_debug_arch())
>> goto skip_dbgsts_read;
>
> Sure, I was just pointing out that the code needs fixing for this.
>
>>> 4. CPUs without the security extensions have DBGAUTHSTATUS.NSE == 0
>>>
>> Which bit is that ? I don't find this bit in Cortex-A9 docs. With all
>> these checks, may be a separate function like 'is_debug_available()'
>> would be better.
>
> NSE is bit 0 (the one you're checking).
>
ok. So the subject patch might break those devices.
>>
>>> 5. Accessing DBGAUTHSTATUS requires DBGEN to be driven high.
>>>Assuming that your pr_warn_once is emitted, this implies that
>>>DBGEN is driven high from cold boot, yet the NSE bit is low,
>>>implying that DBGEN is also low. That's contradictory, so I have
>>>no idea what's going on...
>>>
>> Me neither. The warning is emitted at least.
>
> Any chance you could follow up with your firmware/hardware guys about this
> please? I'd really like to understand how we end up in this state in case we
> can do something in the architecture to stop it from happening in future.
>
I will check on this part and update you when I hear from them.
>>> Apart from that, it's fine!
>>>
>> If you agree, I can update patch accordingly.
>> BTW, do you have any better trick to take care of
>> above scenraio ?
>
> Well, we could just add the warn_once prints but that doesn't stop debug
> from breaking after the first pm/suspend/hotplug operation.
>
Probably we should drop the $subject patch approach and use warn_once
at least for current rc. Ofcourse it doesn't help to get working
hw_breakpoint support. Patch end of the email with warn_once.
Regards,
Santosh
>From 6611d48eb5571e3e094c7a9c2479e652b37d35e3 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Tue, 19 Mar 2013 11:53:41 +0530
Subject: [PATCH] ARM: hw_breakpoints: Use warn_once to avoid debug message
flood from reset_ctrl_regs()
CPU debug features like hardware break, watchpoints can be used only when
the debug mode is enabled and available. Unfortunately on OMAP4 based device,
after a CPU power cycle, the debug feature gets disabled which leads to
a flood of messages coming from reset_ctrl_regs() which gets called on
every CPU_PM_EXIT with CPUidle enabled.
So make use of warn_once() so that system is usable.
Thanks to Will for pointers and Lokesh for the analysis of the issue.
Cc: Will Deacon
Tested-by: Lokesh Vutla
Signed-off-by: Santosh Shilimkar
---
arch/arm/kernel/hw_breakpoint.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 96093b7..5dc1aa6 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -966,7 +966,7 @@ static void reset_ctrl_regs(void *unused)
}
if (err) {
- pr_warning("CPU %d debug is powered down!\n", cpu);
+ pr_warn_once("CPU %d debug is powered down!\n", cpu);
cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu));
return;
}
@@ -987,7 +987,7 @@ clear_vcr:
isb();
if (cpumask_intersects(&debug_err_mask, cpumask_of(cpu))) {
- pr_warning("CPU %d failed to disable vector catch\n", cpu);
+ pr_warn_once("CPU %d failed to disable vector catch\n", cpu);
return;
}
@@ -1007,7 +1007,7 @@ clear_vcr:
}
if (cpumask_intersects(&debug_err_mask, cpumask_of(cpu))) {
-
Re: [PATCH v2 3/4] drm/omap: Make fixed resolution panels work
On Tuesday 12 March 2013 08:23 PM, Tomi Valkeinen wrote: On 2013-03-12 16:38, Archit Taneja wrote: memcmp on two structs is often not a good idea. There could be padding bytes there, with uninitialized data. I'm not sure if that's the case here, though, but it could well change any time (perhaps even depending on compiler version). I saw usage of memcmp on structs in the kernel, but then most of them were in drivers and not core, and could be mistakes :) adding '__attribute__((packed))' to omap_video_timings might be helpful I suppose. But I don't know if it's safe to do a memcmp even with a packed struct. I think it's safe to use memcmp if you know that both structs have been initialized to zero with memset. I'm still pondering whether it'd just be simpler to require all the dssdrv ops to be filled, probably using a helper macro in the panel drivers... Did you consider that approach? I'm not saying to go for it, I'm saying I can't make my mind which would be better =). I didn't consider it mainly because I thought we were going to get rid of our private omapdss panel drivers with CDF panels, and efforts in fixing it wouldn't be much useful. But if there isn't any other good alternative, then I can try to see what macros look like. Well, even if I was slightly optimistic earlier, I now have a feeling CDF may take a while. I think we should just go for omapdss dev model change first. One thing to note about the ops is that NULL is currently used to convey information, something like "this ops is not possible or valid". So adding all the ops may not quite work. For example, adding update op for auto-update panels could tell that the panel supports manual update. (Well, for that particular case we have a flag, but you get the idea). But if we can add only some of the ops to the drivers, and there is no information lost when we won't have NULLs, I guess that could be the simplest option. Then we don't need to add extra code in each place we use the ops. Of course, simpler options for this patch would be to do a manual compare of the fields instead of a memcmp, or adding default ops in omap_dss_register_driver. Adding default ops in omap_dss_register_driver() is not good. It prevents us from having the ops as const in the future, and is also not possible when we either move to CDF or change the omapdss dev model. So I think either we need to handle the NULLs as you do in this patch, or add the ops to the panels. But the ops could still be the default versions offered by the omapdss. I was trying to come up with a macro which could add default ops to the omap_dss_driver. It isn't straight forward as I thought, because you need to choose either the default op, or the panel driver's op if it exists. For example, I can't create a macro which adds an op for get_timings() to all panel drivers, the panel drivers which already this op defined will have 2 instances of get_timings() in the omap_dss_driver struct. I have been looking around in the kernel to see how undeclared ops in a struct are generally dealt with. Till now, I've noticed that the code which uses this ops takes the responsibility to check whether they are NULL or not. The easiest way would be to have these default funcs inlined in a header, and every panel driver's omap_dss_driver struct fills in the default op. This way we can make the driver ops const. Do you have any idea of a macro which could do the same as above, and leads to less addition of code? Archit One thing about common panel driver functions in general is that they won't use the panel driver's locking. So if a panel driver doesn't create a get_timings() op assuming that omapdss will make a default func for it, we would miss out on the panel lock. I don't know if that's really bad, and doing a memcmp or anything else in omapdrm also doesn't help with this case. That's true. The locking is a bit of a mess (read: broken =) anyway currently. Tomi -- 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 0/2] omap serial fix.
On Monday 18 March 2013 04:24 PM, Sourav Poddar wrote: > The first patch is a rearrangement of a macro "OMAP_MAX_HSUART_PORTS" > to a header file so that it can be used in other file. > The second patch fixes the wakeup from uart issue while using > "no_console_suspend" in the > bootargs. > > These patches are developed on 3.8 custom kernel containing omap5 > supend/resume support. > > Cc: Santosh Shilimkar Thanks Sourav for sorting out the issue. With update of changelog suggested by Kevin on patch 1, Feel free to add, Acked-Tested-by: Santosh Shilimkar > Sourav Poddar (2): > driver: serial-omap: move max uart count into generic header file. > arm: mach-omap2: prevent UART console idle on suspend while using > "no_console_suspend" > > arch/arm/mach-omap2/omap_device.c | 36 > - > drivers/tty/serial/omap-serial.c |2 - > include/linux/platform_data/serial-omap.h |1 + > 3 files changed, 36 insertions(+), 3 deletions(-) > -- 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
