* [PATCH 2.6.37-rc1] OMAP1: camera.h: readd missing include
From: Janusz Krzysztofik @ 2010-11-02 14:04 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap@vger.kernel.org, e3-hacking
#include <media/omap1_camera.h> directive, required for successfull
compilation of dependant boards (board-ams-delta for now), has been lost
somehow from arch/arm/mach-omap1/include/mach/camera.h on creation. Readd it.
Created and tested against linux-2.6.37-rc1.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
arch/arm/mach-omap1/include/mach/camera.h | 2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.37-rc1/arch/arm/mach-omap1/include/mach/camera.h.orig 2010-11-01 22:41:04.000000000 +0100
+++ linux-2.6.37-rc1/arch/arm/mach-omap1/include/mach/camera.h 2010-11-01 23:18:44.000000000 +0100
@@ -1,6 +1,8 @@
#ifndef __ASM_ARCH_CAMERA_H_
#define __ASM_ARCH_CAMERA_H_
+#include <media/omap1_camera.h>
+
void omap1_camera_init(void *);
static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
^ permalink raw reply
* [Qemu-devel] Re: [PATCH v7 0/6] pcie port switch emulators
From: Michael S. Tsirkin @ 2010-11-02 14:05 UTC (permalink / raw)
To: Isaku Yamahata; +Cc: skandasa, adnan, etmartin, qemu-devel, wexu2
In-Reply-To: <cover.1288689399.git.yamahata@valinux.co.jp>
On Tue, Nov 02, 2010 at 06:32:46PM +0900, Isaku Yamahata wrote:
> This patch series is v7 of the pcie switch emulators.
> Now the express part has been merged, so the aer part is left.
I think figuring out the FLR first is a good idea.
This would include sticky bit implementation and figuring
out how to initiate, and handle, different kinds of reset.
That in turn is helpful because a lot of AER is sticky.
> This patch series is for the master branch because the current pci branch
> seems a bit behind.
I made them identical now so it should not matter.
--
MST
^ permalink raw reply
* RE: [PATCH] USB: ehci/mxc: compile fix
From: Nguyen Dinh-R00091 @ 2010-11-02 14:05 UTC (permalink / raw)
To: Uwe Kleine-König, Greg KH
Cc: kernel, Sergei Shtylyov, matthieu.castet, linux-kernel, linux-usb,
Alan Stern
In-Reply-To: <1288690257-16801-1-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3487 bytes --]
Hi Uwe,
> -----Original Message-----
> From: Uwe Kleine-König [mailto:u.kleine-koenig@pengutronix.de]
> Sent: Tuesday, November 02, 2010 4:31 AM
> To: Greg KH
> Cc: kernel@pengutronix.de; Sergei Shtylyov; matthieu.castet@parrot.com;
> linux-kernel@vger.kernel.org; linux-usb@vger.kernel.org; Nguyen Dinh-
> R00091; Nguyen Dinh-R00091; Alan Stern
> Subject: [PATCH] USB: ehci/mxc: compile fix
>
> Commit
> 65fd427 (USB: ehci tdi : let's tdi_reset set host mode)
>
> broke the build using ARM's mx51_defconfig:
>
> CC drivers/usb/host/ehci-hcd.o
> In file included from drivers/usb/host/ehci-hcd.c:1166:
> drivers/usb/host/ehci-mxc.c: In function 'ehci_mxc_drv_probe':
> drivers/usb/host/ehci-mxc.c:192: error: 'ehci' undeclared (first
> use in this function)
> drivers/usb/host/ehci-mxc.c:192: error: (Each undeclared identifier
> is reported only once
> drivers/usb/host/ehci-mxc.c:192: error: for each function it
> appears in.)
> drivers/usb/host/ehci-mxc.c:117: warning: unused variable 'temp'
> make[3]: *** [drivers/usb/host/ehci-hcd.o] Error 1
> make[2]: *** [drivers/usb/host/ehci-hcd.o] Error 2
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2
>
> Fix it together with the warning about the unused variable and use
> msleep instead of mdelay as requested by Alan Stern.
>
> Cc: Dinh Nguyen <Dinh.Nguyen@freescale.com>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> I currently have no hardware to test it, so I only verified it to
> compile.
>
> Dinh: I changed your Tested-by to Cc for the new patch, do you care to
> retest?
Retested - check!
>
> Best regards
> Uwe
> ---
> drivers/usb/host/ehci-mxc.c | 14 +++++++++-----
> 1 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
> index ac9c4d7..bce8505 100644
> --- a/drivers/usb/host/ehci-mxc.c
> +++ b/drivers/usb/host/ehci-mxc.c
> @@ -36,6 +36,8 @@ struct ehci_mxc_priv {
> static int ehci_mxc_setup(struct usb_hcd *hcd)
> {
> struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> + struct device *dev = hcd->self.controller;
> + struct mxc_usbh_platform_data *pdata = dev_get_platdata(dev);
> int retval;
>
> /* EHCI registers start at offset 0x100 */
> @@ -63,6 +65,12 @@ static int ehci_mxc_setup(struct usb_hcd *hcd)
>
> ehci_reset(ehci);
>
> + /* set up the PORTSCx register */
> + ehci_writel(ehci, pdata->portsc, &ehci->regs->port_status[0]);
> +
> + /* is this really needed? */
> + msleep(10);
> +
> ehci_port_power(ehci, 0);
> return 0;
> }
> @@ -114,7 +122,7 @@ static int ehci_mxc_drv_probe(struct platform_device
> *pdev)
> struct mxc_usbh_platform_data *pdata = pdev->dev.platform_data;
> struct usb_hcd *hcd;
> struct resource *res;
> - int irq, ret, temp;
> + int irq, ret;
> struct ehci_mxc_priv *priv;
> struct device *dev = &pdev->dev;
>
> @@ -188,10 +196,6 @@ static int ehci_mxc_drv_probe(struct platform_device
> *pdev)
> clk_enable(priv->ahbclk);
> }
>
> - /* set up the PORTSCx register */
> - ehci_writel(ehci, pdata->portsc, &ehci->regs->port_status[0]);
> - mdelay(10);
> -
> /* setup specific usb hw */
> ret = mxc_initialize_usb_hw(pdev->id, pdata->flags);
> if (ret < 0)
> --
> 1.7.2.3
>
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply
* Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection
From: Guenter Roeck @ 2010-11-02 14:04 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20090310170340.4c63de39@hyperion.delvare>
On Tue, Nov 02, 2010 at 09:21:02AM -0400, Jean Delvare wrote:
> Hi Fred,
>
> Please don't top-post.
>
> On Tue, 12 Oct 2010 09:15:03 +0200, Fred . wrote:
> > I am sorry tha I do not have the nescesary equipment nor skill set in
> > order to be able to help test
> > or contribute with code.
> >
> > Now since the interface definition is upstreams, I hope that someone
> > may implement the feature
> > in at least one of the drivers.
>
> This is done now: the new w83795 hardware monitoring driver implements
> the standard intrusion detection interface.
>
> I have written user-space code to use that interface. I have two
> patches, one for libsensors, one for sensors, both apply on top of
> lm-sensors SVN, if anyone wants to give them a try. I've attached them.
> They work OK for me, I'll commit them soon unless someone finds and
> reports a problem with them.
>
> Then we will have to convert the remaining drivers. I found 3 drivers
> which need to be converted: adm9240, w83792d and w83793. If there are
> more, please let me know.
>
Reminds me. I have a set of patches for those almost ready for submission.
Hope you didn't do the same work ;).
Code below looks ok.
Guenter
> --
> Jean Delvare
> Add support for intrusion detection to libsensors.
>
> ---
> doc/libsensors-API.txt | 6 ++++++
> lib/Module.mk | 2 +-
> lib/sensors.h | 4 ++++
> lib/sysfs.c | 14 +++++++++++---
> 4 files changed, 22 insertions(+), 4 deletions(-)
>
> --- lm-sensors.orig/lib/sensors.h 2010-11-02 12:59:04.000000000 +0100
> +++ lm-sensors/lib/sensors.h 2010-11-02 13:00:26.000000000 +0100
> @@ -141,6 +141,7 @@ typedef enum sensors_feature_type {
> SENSORS_FEATURE_ENERGY = 0x04,
> SENSORS_FEATURE_CURR = 0x05,
> SENSORS_FEATURE_VID = 0x10,
> + SENSORS_FEATURE_INTRUSION = 0x11,
> SENSORS_FEATURE_BEEP_ENABLE = 0x18,
> SENSORS_FEATURE_UNKNOWN = INT_MAX,
> } sensors_feature_type;
> @@ -198,6 +199,9 @@ typedef enum sensors_subfeature_type {
>
> SENSORS_SUBFEATURE_VID = SENSORS_FEATURE_VID << 8,
>
> + SENSORS_SUBFEATURE_INTRUSION_ALARM = SENSORS_FEATURE_INTRUSION << 8,
> + SENSORS_SUBFEATURE_INTRUSION_BEEP,
> +
> SENSORS_SUBFEATURE_BEEP_ENABLE = SENSORS_FEATURE_BEEP_ENABLE << 8,
>
> SENSORS_SUBFEATURE_UNKNOWN = INT_MAX,
> --- lm-sensors.orig/lib/sysfs.c 2010-11-02 12:59:04.000000000 +0100
> +++ lm-sensors/lib/sysfs.c 2010-11-02 13:00:26.000000000 +0100
> @@ -137,14 +137,14 @@ static int sysfs_foreach_busdev(const ch
> char sensors_sysfs_mount[NAME_MAX];
>
> #define MAX_MAIN_SENSOR_TYPES 6
> -#define MAX_OTHER_SENSOR_TYPES 1
> +#define MAX_OTHER_SENSOR_TYPES 2
> #define MAX_SENSORS_PER_TYPE 24
> #define MAX_SUBFEATURES 8
> #define FEATURE_SIZE (MAX_SUBFEATURES * 2)
> #define FEATURE_TYPE_SIZE (MAX_SENSORS_PER_TYPE * FEATURE_SIZE)
>
> -/* Room for all 6 main types (in, fan, temp, power, energy, current) and 1
> - other type (VID) with all their subfeatures + misc features */
> +/* Room for all 6 main types (in, fan, temp, power, energy, current) and 2
> + other types (VID, intrusion) with all their subfeatures + misc features */
> #define SUB_OFFSET_OTHER (MAX_MAIN_SENSOR_TYPES * FEATURE_TYPE_SIZE)
> #define SUB_OFFSET_MISC (SUB_OFFSET_OTHER + \
> MAX_OTHER_SENSOR_TYPES * FEATURE_TYPE_SIZE)
> @@ -190,6 +190,7 @@ char *get_feature_name(sensors_feature_t
> case SENSORS_FEATURE_POWER:
> case SENSORS_FEATURE_ENERGY:
> case SENSORS_FEATURE_CURR:
> + case SENSORS_FEATURE_INTRUSION:
> underscore = strchr(sfname, '_');
> name = strndup(sfname, underscore - sfname);
> if (!name)
> @@ -289,6 +290,11 @@ static const struct subfeature_type_matc
> { NULL, 0 }
> };
>
> +static const struct subfeature_type_match intrusion_matches[] = {
> + { "alarm", SENSORS_SUBFEATURE_INTRUSION_ALARM },
> + { "beep", SENSORS_SUBFEATURE_INTRUSION_BEEP },
> + { NULL, 0 }
> +};
> static struct feature_type_match matches[] = {
> { "temp%d%c", temp_matches },
> { "in%d%c", in_matches },
> @@ -297,6 +303,7 @@ static struct feature_type_match matches
> { "power%d%c", power_matches },
> { "curr%d%c", curr_matches },
> { "energy%d%c", energy_matches },
> + { "intrusion%d%c", intrusion_matches },
> };
>
> /* Return the subfeature type and channel number based on the subfeature
> @@ -411,6 +418,7 @@ static int sensors_read_dynamic_chip(sen
> sorted table */
> switch (ftype) {
> case SENSORS_FEATURE_VID:
> + case SENSORS_FEATURE_INTRUSION:
> i = SUB_OFFSET_OTHER +
> (ftype - SENSORS_FEATURE_VID) * FEATURE_TYPE_SIZE +
> nr * FEATURE_SIZE + (sftype & 0xFF);
> --- lm-sensors.orig/doc/libsensors-API.txt 2010-10-10 20:20:31.000000000 +0200
> +++ lm-sensors/doc/libsensors-API.txt 2010-11-02 13:01:58.000000000 +0100
> @@ -6,6 +6,12 @@ over time. This document summarizes thes
> authors can quickly figure out how to test for the availability of a
> given new feature.
>
> +0x431 lm-sensors SVN
> +* Added support for intrusion detection
> + enum sensors_feature_type SENSORS_FEATURE_INTRUSION
> + enum sensors_subfeature_type SENSORS_SUBFEATURE_INTRUSION_ALARM
> + enum sensors_subfeature_type SENSORS_SUBFEATURE_INTRUSION_BEEP
> +
> 0x430 lm-sensors 3.2.0
> * License changed from GPL to LGPL
>
> --- lm-sensors.orig/lib/Module.mk 2010-10-10 20:03:08.000000000 +0200
> +++ lm-sensors/lib/Module.mk 2010-11-02 13:02:18.000000000 +0100
> @@ -33,7 +33,7 @@ LIBMAN5FILES := $(MODULE_DIR)/sensors.co
> # changed in a backward incompatible way. The interface is defined by
> # the public header files - in this case they are error.h and sensors.h.
> LIBMAINVER := 4
> -LIBMINORVER := 3.0
> +LIBMINORVER := 3.1
> LIBVER := $(LIBMAINVER).$(LIBMINORVER)
>
> # The static lib name, the shared lib name, and the internal ('so') name of
> Add support for intrusion detection to sensors.
>
> ---
> prog/sensors/chips.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> --- lm-sensors.orig/prog/sensors/chips.c 2010-11-02 13:37:40.000000000 +0100
> +++ lm-sensors/prog/sensors/chips.c 2010-11-02 13:38:10.000000000 +0100
> @@ -2,7 +2,7 @@
> chips.c - Part of sensors, a user-space program for hardware monitoring
> Copyright (C) 1998-2003 Frodo Looijaard <frodol@dds.nl> and
> Mark D. Studebaker <mdsxyz123@yahoo.com>
> - Copyright (C) 2007 Jean Delvare <khali@linux-fr.org>
> + Copyright (C) 2007-2010 Jean Delvare <khali@linux-fr.org>
>
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> @@ -661,6 +661,27 @@ static void print_chip_curr(const sensor
> printf("\n");
> }
>
> +static void print_chip_intrusion(const sensors_chip_name *name,
> + const sensors_feature *feature,
> + int label_size)
> +{
> + char *label;
> + const sensors_subfeature *subfeature;
> + double alarm;
> +
> + subfeature = sensors_get_subfeature(name, feature,
> + SENSORS_SUBFEATURE_INTRUSION_ALARM);
> + if (!subfeature)
> + return;
> +
> + if ((label = sensors_get_label(name, feature))
> + && !sensors_get_value(name, subfeature->number, &alarm)) {
> + print_label(label, label_size);
> + printf("%s\n", alarm ? "ALARM" : "OK");
> + }
> + free(label);
> +}
> +
> void print_chip(const sensors_chip_name *name)
> {
> const sensors_feature *feature;
> @@ -695,6 +716,9 @@ void print_chip(const sensors_chip_name
> case SENSORS_FEATURE_CURR:
> print_chip_curr(name, feature, label_size);
> break;
> + case SENSORS_FEATURE_INTRUSION:
> + print_chip_intrusion(name, feature, label_size);
> + break;
> default:
> continue;
> }
--
Guenter Roeck
Distinguished Engineer
PDU IP Systems
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support
From: Greg KH @ 2010-11-02 14:03 UTC (permalink / raw)
To: Naveen Kumar G; +Cc: linux-kernel, STEricsson_nomadik_linux
In-Reply-To: <1288699725-14405-1-git-send-email-naveen.gaddipati@stericsson.com>
On Tue, Nov 02, 2010 at 05:38:45PM +0530, Naveen Kumar G wrote:
> --- /dev/null
> +++ b/drivers/staging/ste_rmi4/TODO
> @@ -0,0 +1,7 @@
> +TODO
> +----
> +
> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
> +Merge any device support needed from this driver into it
> +Delete this driver
Huh?
Why not just add this driver to the kernel tree instead? When the
"promised" driver then eventually shows up (who is promising it?) then
delete the thing.
But until then, why is this needed to go into the staging tree? Is
there any other main reason it should be here and not in the "real" part
of the kernel?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] regulator: regulator disable supply fix
From: Mattias Wallin @ 2010-11-02 13:45 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, linux-kernel@vger.kernel.org
In-Reply-To: <20101102131952.GC21476@opensource.wolfsonmicro.com>
On 11/02/2010 02:19 PM, Mark Brown wrote:
> On Tue, Nov 02, 2010 at 01:22:29PM +0100, Mattias Wallin wrote:
>> This patch fixes a disable failure when regulator supply is used.
>> A while loop in regulator disable checks for supply pointer != NULL
>> but the pointer is not always updated, resulting in the while loop
>> running too many times causing a disable failure.
>
>> Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com>
>
> Hrm. This does fix the problem which is needed so:
>
> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
>
>> ---
>> drivers/regulator/core.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
>> index f1d10c9..dc7d36e 100644
>> --- a/drivers/regulator/core.c
>> +++ b/drivers/regulator/core.c
>> @@ -1424,6 +1424,7 @@ int regulator_disable(struct regulator *regulator)
>> /* decrease our supplies ref count and disable if required */
>> while (supply_rdev != NULL) {
>> rdev = supply_rdev;
>> + supply_rdev = NULL;
>>
>> mutex_lock(&rdev->mutex);
>> _regulator_disable(rdev, &supply_rdev);
>
> but this does smell a bit like it ought to be in the _regulator_disable()
> call rather than the caller.
Would you prefer below solution instead?
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index dc7d36e..51f66b2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1359,6 +1359,7 @@ static int _regulator_disable(struct regulator_dev *rdev,
struct regulator_dev **supply_rdev_ptr)
{
int ret = 0;
+ *supply_rdev_ptr = NULL;
if (WARN(rdev->use_count <= 0,
"unbalanced disables for %s\n",
^ permalink raw reply related
* Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
From: Felipe Contreras @ 2010-11-02 14:02 UTC (permalink / raw)
To: Mark Brown
Cc: linux-usb, linux-main, linux-omap, Felipe Balbi, Greg KH,
Samuel Ortiz, Liam Girdwood, David Brownell, Greg Kroah-Hartman,
Hao Wu, Alan Cox, Uwe Kleine-König, Mike Rapoport
In-Reply-To: <20101102131146.GA21476@opensource.wolfsonmicro.com>
On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
>
>> config REGULATOR_TWL4030
>> bool "TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC"
>> depends on TWL4030_CORE
>> + default y
>> help
>> This driver supports the voltage regulators provided by
>> this family of companion chips.
>
> This default is not suitable for non-OMAP platforms, it should be
> conditional on OMAP or something if we're going to do this (though
> generally we handle this with defconfigs rather than in Kconfig).
This would only be enabled when TWL4030_CORE is enabled, so non-OMAP
platforms would not get affected.
I guess you have seen the complaint from Linus regarding ARM relying
too much on defconfigs. This helps in order to simplify defconfigs,
and eventually getting rid of them completely.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff
From: Felipe Contreras @ 2010-11-02 14:02 UTC (permalink / raw)
To: Mark Brown
Cc: linux-usb, linux-main, linux-omap, Felipe Balbi, Greg KH,
Samuel Ortiz, Liam Girdwood, David Brownell, Greg Kroah-Hartman,
Hao Wu, Alan Cox, Uwe Kleine-König, Mike Rapoport
In-Reply-To: <20101102131146.GA21476-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
>
>> config REGULATOR_TWL4030
>> bool "TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC"
>> depends on TWL4030_CORE
>> + default y
>> help
>> This driver supports the voltage regulators provided by
>> this family of companion chips.
>
> This default is not suitable for non-OMAP platforms, it should be
> conditional on OMAP or something if we're going to do this (though
> generally we handle this with defconfigs rather than in Kconfig).
This would only be enabled when TWL4030_CORE is enabled, so non-OMAP
platforms would not get affected.
I guess you have seen the complaint from Linus regarding ARM relying
too much on defconfigs. This helps in order to simplify defconfigs,
and eventually getting rid of them completely.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] mtd: onenand: add cache program feature for 4kb page onenand
From: Kyungmin Park @ 2010-11-02 14:01 UTC (permalink / raw)
To: Roman Tereshonkov; +Cc: linux-mtd
In-Reply-To: <1288697130-12772-1-git-send-email-roman.tereshonkov@nokia.com>
Hi,
Thank you for your works.
I'll check your patch in my board, 2KiB & 4KiB pagesize.
Thank you,
Kyungmin Park
On Tue, Nov 2, 2010 at 8:25 PM, Roman Tereshonkov
<roman.tereshonkov@nokia.com> wrote:
> Implement cache program feature for 4KB page onenand.
> This feature improves the write data performance.
> The observed 128KB data program speed change is
> from 8827KB/s to 14156 KB/s when the feature is enabled.
>
> Roman Tereshonkov (3):
> mtd: onenand: add option and variable for cache program feature
> mtd: onenand: introduce not "real" commands for cache program
> feature.
> mtd: onenand: implement cache program feature for 4kb page onenand
>
> drivers/mtd/onenand/omap2.c | 12 ++++++++--
> drivers/mtd/onenand/onenand_base.c | 39 ++++++++++++++++++++++++++++++++++-
> include/linux/mtd/onenand.h | 12 +++++++++++
> include/linux/mtd/onenand_regs.h | 2 +
> 4 files changed, 60 insertions(+), 5 deletions(-)
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 3/3] msi: Store the capability size in PCIDevice
From: Alex Williamson @ 2010-11-02 14:00 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: yamahata, qemu-devel
In-Reply-To: <20101102092508.GA3390@redhat.com>
On Tue, 2010-11-02 at 11:25 +0200, Michael S. Tsirkin wrote:
> On Mon, Nov 01, 2010 at 11:37:53PM -0600, Alex Williamson wrote:
> > Avoid needing to get the MSI capability flags every time we need to
> > check the capability length. This also makes it accessible outside
> > of msi.c, making it easier for users to filter config space writes
> > using msi_cap and msi_cap_size.
>
> I think for this last use-case, we are better off with returning a
> boolean from msi_write_config which tells us whether the write is in
> range. This has the advantage in that it will also work well for other
> capabilities. Or second best, if that is insufficient for some reason,
> export an msi_cap_size function.
Returning whether the write was in range isn't enough. For device
assignment, I need to know whether the capability was enabled or
disabled. This currently means checking the enable state before and
after calling msi_write_config and doing the appropriate backend setup.
I think the only way I could blindly call the msi/x write config
routines is if we init the capability with enable/disable callbacks.
I'd be ok with an msi_cap_size function if we don't want to go that far
too. What do you prefer? Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 3/3] mtd: onenand: implement cache program feature for 4kb page onenand
From: Kyungmin Park @ 2010-11-02 14:00 UTC (permalink / raw)
To: Roman Tereshonkov; +Cc: kyungmin.park, linux-mtd
In-Reply-To: <1288697130-12772-4-git-send-email-roman.tereshonkov@nokia.com>
Hi,
On Tue, Nov 2, 2010 at 8:25 PM, Roman Tereshonkov
<roman.tereshonkov@nokia.com> wrote:
> Implement cache program feature for 4KB page onenand.
> This feature improves the write data performance.
> The observed 128KB data program speed change is
> from 8827KB/s to 14156 KB/s when the feature is enabled.
>
> Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
> ---
> drivers/mtd/onenand/omap2.c | 12 ++++++++--
> drivers/mtd/onenand/onenand_base.c | 39 ++++++++++++++++++++++++++++++++++-
> 2 files changed, 46 insertions(+), 5 deletions(-)
Please make separate the two patches, one for OMAP, another is for
onenand_base.c
>
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 9f322f1..da25a90 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -108,8 +108,9 @@ static void wait_warn(char *msg, int state, unsigned int ctrl,
> static int omap2_onenand_wait(struct mtd_info *mtd, int state)
> {
> struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> + struct onenand_chip *this = mtd->priv;
> unsigned int intr = 0;
> - unsigned int ctrl;
> + unsigned int ctrl, ctrl_mask;
> unsigned long timeout;
> u32 syscfg;
>
> @@ -180,7 +181,8 @@ retry:
> if (result == 0) {
> /* Timeout after 20ms */
> ctrl = read_reg(c, ONENAND_REG_CTRL_STATUS);
> - if (ctrl & ONENAND_CTRL_ONGO) {
> + if (ctrl & ONENAND_CTRL_ONGO &&
> + !this->ongoing) {
> /*
> * The operation seems to be still going
> * so give it some more time.
> @@ -269,7 +271,11 @@ retry:
> return -EIO;
> }
>
> - if (ctrl & 0xFE9F)
> + ctrl_mask = 0xFE9F;
> + if (this->ongoing)
> + ctrl_mask &= ~0x8000;
> +
> + if (ctrl & ctrl_mask)
> wait_warn("unexpected controller status", state, ctrl, intr);
>
> return 0;
> diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
> index 6b3a875..b2c3e97 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -440,6 +440,19 @@ static int onenand_command(struct mtd_info *mtd, int cmd, loff_t addr, size_t le
> default:
> if (ONENAND_IS_2PLANE(this) && cmd == ONENAND_CMD_PROG)
> cmd = ONENAND_CMD_2X_PROG;
> +
> + /* Exclude 1st OTP and OTP blocks */
Are there any reason? I think 1st OTP block is just block 0 so no need
to consider block 0 case.
> + if (ONENAND_IS_CACHE_PROGRAM(this) &&
> + likely(onenand_block(this, addr) != 0) &&
> + ONENAND_IS_4KB_PAGE(this)) {
and I think no need to check 4KB_PAGE.
> +
> + if (cmd == ONENAND_CMD_CACHE_PROG)
> + cmd = ONENAND_CMD_2X_CACHE_PROG;
> + else if (cmd == ONENAND_CMD_CACHE_PROG_LAST)
> + cmd = ONENAND_CMD_PROG;
> +
> + }
> +
> dataram = ONENAND_CURRENT_BUFFERRAM(this);
> break;
> }
> @@ -1845,7 +1858,7 @@ static int onenand_write_ops_nolock(struct mtd_info *mtd, loff_t to,
> const u_char *buf = ops->datbuf;
> const u_char *oob = ops->oobbuf;
> u_char *oobbuf;
> - int ret = 0;
> + int ret = 0, cmd;
>
> DEBUG(MTD_DEBUG_LEVEL3, "%s: to = 0x%08x, len = %i\n",
> __func__, (unsigned int) to, (int) len);
> @@ -1954,7 +1967,25 @@ static int onenand_write_ops_nolock(struct mtd_info *mtd, loff_t to,
> ONENAND_SET_NEXT_BUFFERRAM(this);
> }
>
> - this->command(mtd, ONENAND_CMD_PROG, to, mtd->writesize);
> + this->ongoing = 0;
> +
> + /* Exclude 1st OTP and OTP blocks */
> + if (ONENAND_IS_CACHE_PROGRAM(this) &&
> + likely(onenand_block(this, to) != 0) &&
> + ONENAND_IS_4KB_PAGE(this)) {
check the length here instead of 4KB_PAGE.
> +
> + if ((written + thislen) < len) {
> + cmd = ONENAND_CMD_CACHE_PROG;
> + this->ongoing = 1;
> + } else {
> + cmd = ONENAND_CMD_CACHE_PROG_LAST;
> + }
Need to check how to pass the cmd properly. How/When send the CACHE_PROG_LAST?
> +
> + } else {
> + cmd = ONENAND_CMD_PROG;
> + }
> +
> + this->command(mtd, cmd, to, mtd->writesize);
>
> /*
> * 2 PLANE, MLC, and Flex-OneNAND wait here
> @@ -3380,6 +3411,8 @@ static void onenand_check_features(struct mtd_info *mtd)
> else if (numbufs == 1)
> this->options |= ONENAND_HAS_4KB_PAGE;
>
> + this->options |= ONENAND_HAS_CACHE_PROGRAM;
It also needs to set CACHE_PROGRAM option.
> +
> case ONENAND_DEVICE_DENSITY_2Gb:
> /* 2Gb DDP does not have 2 plane */
> if (!ONENAND_IS_DDP(this))
> @@ -3415,6 +3448,8 @@ static void onenand_check_features(struct mtd_info *mtd)
> printk(KERN_DEBUG "Chip has 2 plane\n");
> if (this->options & ONENAND_HAS_4KB_PAGE)
> printk(KERN_DEBUG "Chip has 4KiB pagesize\n");
> + if (this->options & ONENAND_HAS_CACHE_PROGRAM)
> + printk(KERN_DEBUG "Chip has cache program feature\n");
> }
Thank you,
Kyungmin Park
^ permalink raw reply
* [PATCH] posix-cpu-timers: rcu_read_lock/unlock protect find_task_by_vpid call
From: Sergey Senozhatsky @ 2010-11-02 13:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: Thomas Gleixner, Peter Zijlstra, Ingo Molnar, linux-kernel
Commit 4221a9918e38b7494cee341dda7b7b4bb8c04bde "Add RCU check for
find_task_by_vpid()" introduced rcu_lockdep_assert to find_task_by_pid_ns.
Add rcu_read_lock/rcu_read_unlock to call find_task_by_vpid.
Tetsuo Handa wrote:
Quoting from one of posts in that thead
http://kerneltrap.org/mailarchive/linux-kernel/2010/2/8/4536388
| Usually tasklist gives enough protection, but if copy_process() fails
| it calls free_pid() lockless and does call_rcu(delayed_put_pid().
| This means, without rcu lock find_pid_ns() can't scan the hash table
| safely.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 6842eeb..855bc53 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -38,11 +38,13 @@ static int check_clock(const clockid_t which_clock)
return 0;
read_lock(&tasklist_lock);
+ rcu_read_lock();
p = find_task_by_vpid(pid);
if (!p || !(CPUCLOCK_PERTHREAD(which_clock) ?
same_thread_group(p, current) : thread_group_leader(p))) {
error = -EINVAL;
}
+ rcu_read_unlock();
read_unlock(&tasklist_lock);
return error;
@@ -395,17 +397,21 @@ int posix_cpu_timer_create(struct k_itimer *new_timer)
if (pid == 0) {
p = current;
} else {
+ rcu_read_lock();
p = find_task_by_vpid(pid);
if (p && !same_thread_group(p, current))
p = NULL;
+ rcu_read_unlock();
}
} else {
if (pid == 0) {
p = current->group_leader;
} else {
+ rcu_read_lock();
p = find_task_by_vpid(pid);
if (p && !thread_group_leader(p))
p = NULL;
+ rcu_read_unlock();
}
}
new_timer->it.cpu.task = p;
^ permalink raw reply related
* Re: [DRAFT PATCH 0/3] perf: Add Intel Nehalem uncore pmu support
From: Lin Ming @ 2010-11-02 13:58 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Frederic Weisbecker, Arjan van de Ven,
Stephane Eranian, robert.richter@amd.com, Cyrill Gorcunov,
paulus@samba.org, Thomas Gleixner, H. Peter Anvin, CoreyAshford,
lkml
In-Reply-To: <1288700970.2039.26.camel@laptop>
On Tue, 2010-11-02 at 20:29 +0800, Peter Zijlstra wrote:
> On Tue, 2010-11-02 at 15:27 +0800, Lin Ming wrote:
> > Any comment is very appreciated.
>
> Right, so I was hoping to use the sysfs bits to expose things, I'll try
> and get around to looking at your latest effort in that area soonish.
> I'll try and sit down with gregkh one of these days to talk it over.
>
> I'm not too sure about 1/3's change to x86_perf_event_update(), but its
> not too aweful, the change to x86_perf_event_set_period() however does
> look quite gruesome.
>
> It might make sense to simple duplicate that code in the uncore bits,.
> dunno.
How about below?
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index fafa0f9..b22aa95 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -80,10 +80,52 @@ static int uncore_pmu_event_init(struct perf_event *event)
return 0;
}
+static int
+uncore_perf_event_set_period(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ s64 left = local64_read(&hwc->period_left);
+ s64 period = hwc->sample_period;
+ u64 max_period = (1ULL << UNCORE_NUM_COUNTERS) - 1;
+ int ret = 0, idx = hwc->idx;
+
+ /*
+ * If we are way outside a reasonable range then just skip forward:
+ */
+ if (unlikely(left <= -period)) {
+ left = period;
+ local64_set(&hwc->period_left, left);
+ hwc->last_period = period;
+ ret = 1;
+ }
+
+ if (unlikely(left <= 0)) {
+ left += period;
+ local64_set(&hwc->period_left, left);
+ hwc->last_period = period;
+ ret = 1;
+ }
+
+ if (left > max_period)
+ left = max_period;
+
+ /*
+ * The hw event starts counting from this event offset,
+ * mark it to be able to extra future deltas:
+ */
+ local64_set(&hwc->prev_count, (u64)-left);
+
+ wrmsrl(hwc->event_base + idx, (u64)(-left) & max_period);
+
+ perf_event_update_userpage(event);
+
+ return ret;
+}
+
static void uncore_pmu_start(struct perf_event *event, int flags)
{
if (flags & PERF_EF_RELOAD)
- x86_perf_event_set_period(event);
+ uncore_perf_event_set_period(event);
uncore_pmu_enable_event(event);
@@ -200,7 +242,7 @@ static inline void uncore_pmu_ack_status(u64 ack)
static int uncore_pmu_save_and_restart(struct perf_event *event)
{
x86_perf_event_update(event, UNCORE_CNTVAL_BITS);
- return x86_perf_event_set_period(event);
+ return uncore_perf_event_set_period(event);
}
int uncore_pmu_handle_irq(struct pt_regs *regs)
>
> 2/3 looks ok, but I think it would be nice if it would be more self
> contained, that is, not be part of the include mess and possibly have
> its own NMI_DIE notifier entry.
How about below to make uncore code more self contained?
I'll look at the NMI DIE notifier thing later.
diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h
index 550e26b..8df4e13 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -127,6 +127,7 @@ union cpuid10_edx {
#ifdef CONFIG_PERF_EVENTS
extern void init_hw_perf_events(void);
extern void perf_events_lapic_init(void);
+extern void init_uncore_pmu(void);
#define PERF_EVENT_INDEX_OFFSET 0
@@ -138,6 +139,7 @@ extern void perf_events_lapic_init(void);
#define PERF_EFLAGS_EXACT (1UL << 3)
struct pt_regs;
+extern int uncore_pmu_handle_irq(struct pt_regs *regs);
extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
extern unsigned long perf_misc_flags(struct pt_regs *regs);
#define perf_misc_flags(regs) perf_misc_flags(regs)
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 3f0ebe4..db4bf99 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
obj-$(CONFIG_PERF_EVENTS) += perf_event.o
+obj-$(CONFIG_PERF_EVENTS) += perf_event_intel_uncore.o
obj-$(CONFIG_X86_MCE) += mcheck/
obj-$(CONFIG_MTRR) += mtrr/
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index cca07b4..330e4f4 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1215,8 +1215,6 @@ struct pmu_nmi_state {
static DEFINE_PER_CPU(struct pmu_nmi_state, pmu_nmi);
-static int uncore_pmu_handle_irq(struct pt_regs *regs);
-
static int __kprobes
perf_event_nmi_handler(struct notifier_block *self,
unsigned long cmd, void *__args)
@@ -1308,7 +1306,6 @@ x86_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event)
#include "perf_event_intel_lbr.c"
#include "perf_event_intel_ds.c"
#include "perf_event_intel.c"
-#include "perf_event_intel_uncore.c"
static int __cpuinit
x86_pmu_notifier(struct notifier_block *self, unsigned long action, void *hcpu)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index b22aa95..b9f15f2 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -3,6 +3,7 @@
static struct node_hw_events uncore_events[MAX_NUMNODES];
static DEFINE_PER_CPU(struct uncore_cpu_hw_events, uncore_cpu_hw_events);
static bool uncore_pmu_initialized;
+static atomic_t active_events;
static void uncore_pmu_enable_event(struct perf_event *event)
{
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.h b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
index 33b9b5e..0a5e6d4 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
@@ -78,3 +78,4 @@ struct uncore_cpu_hw_events {
unsigned long active_mask[BITS_TO_LONGS(UNCORE_NUM_COUNTERS)];
};
+extern u64 x86_perf_event_update(struct perf_event *event, int cntval_bits);
>
> All in all, Thanks for doing this, its a good start!
Thanks for the quick response.
Lin Ming
^ permalink raw reply related
* [PATCH v2] regulator: regulator disable supply fix
From: Mattias Wallin @ 2010-11-02 13:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: linux-kernel, Mattias Wallin
This patch fixes a disable failure when regulator supply is used.
A while loop in regulator disable checks for supply pointer != NULL
but the pointer is not always updated, resulting in the while loop
running too many times causing a disable failure.
Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/regulator/core.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f1d10c9..c625633 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1359,6 +1359,7 @@ static int _regulator_disable(struct regulator_dev *rdev,
struct regulator_dev **supply_rdev_ptr)
{
int ret = 0;
+ *supply_rdev_ptr = NULL;
if (WARN(rdev->use_count <= 0,
"unbalanced disables for %s\n",
--
1.6.3.3
^ permalink raw reply related
* [Qemu-devel] Re: [PATCH v7 2/6] pcie/aer: helper functions for pcie aer capability
From: Michael S. Tsirkin @ 2010-11-02 13:54 UTC (permalink / raw)
To: Isaku Yamahata; +Cc: skandasa, adnan, etmartin, qemu-devel, wexu2
In-Reply-To: <7e0bd57a938864f2bb60651f975f5bcaf042c4f2.1288689399.git.yamahata@valinux.co.jp>
On Tue, Nov 02, 2010 at 06:32:48PM +0900, Isaku Yamahata wrote:
> This patch implements helper functions for pcie aer capability
> which will be used later.
>
> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Applying this gets:
Applying: pcie/aer: helper functions for pcie aer capability
/scm/qemu/.git/rebase-apply/patch:95: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
^ permalink raw reply
* Re: Linux 2.6.36-rc8 won't boot
From: David Miller @ 2010-11-02 13:54 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <alpine.LNX.2.01.1010151559250.28469@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Tue, 2 Nov 2010 14:48:49 +0100 (CET)
> I tried bisecting today, booted a number of kernels already, and upon
> the latest reboot I only get this - very frustrating.
>
> SPARC Enterprise T1000, No Keyboard
> Copyright (c) 1998, 2010, Oracle and/or its affiliates. All rights
> reserved.
> OpenBoot 4.30.4.b, 8064 MB memory available, Serial #81908004.
> Ethernet address 0:14:4f:e1:d1:24, Host ID: 84e1d124.
> (T1000 firmware 6.7.10)
>
> {0} ok boot
> Boot device: disk File and args:
> SILO Version 1.4.14
> ERROR: Last Trap: Illegal Instruction
> {0} ok
Type "dis" and ".registers" so that you can see where it crashed
and what the register values were at the time of the crash.
^ permalink raw reply
* Re: clone packet with new destination address
From: Stephen Clark @ 2010-11-02 13:53 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Changli Gao, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1011021445320.7622@obet.zrqbmnf.qr>
On 11/02/2010 09:46 AM, Jan Engelhardt wrote:
> On Tuesday 2010-11-02 14:44, Stephen Clark wrote:
>
>>>
>>>
>>>> Also if I am mistaken and it does hit one of the remaining iptables
>>>> chains how do I tell it is not the original but the cloned packet I
>>>> want to change to the new destination address?
>>>>
>>>>
>>> Good question. Given the possibilities I think an extra route towards
>>> the logging server that specifies a realm value, that is then
>>> matchable in -A OUTPUT -m realm, is in order.
>>>
>>>
>> Hmm...,
>>
>> Sounds like maybe an easier way to do this is to use libipq and the
>> QUEUE target to select the packets of interest - then make a copy
>> of the packet in userspace and use a raw socket to send the copy
>> with the new destination address on its way.
>>
>> Does this sound reasonable?
>>
> The roundtrip over userspace sounds unnecessarily imperformant.
>
>
I would agree but it keeps me from being dependent on a particular
kernel version
and we are only concerned with less than 10 packets per second.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* [Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34
From: bugzilla-daemon @ 2010-11-02 13:53 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-28402-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #96 from madbiologist <s.j.turner@uq.net.au> 2010-11-02 06:53:28 PDT ---
This fix has been released in kernel 2.6.37-rc1, and queued for stable.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: command bootu to start kernel
From: Belisko Marek @ 2010-11-02 13:53 UTC (permalink / raw)
To: Juergen Beisert; +Cc: barebox
In-Reply-To: <201010291436.18901.jbe@pengutronix.de>
On Fri, Oct 29, 2010 at 2:36 PM, Juergen Beisert <jbe@pengutronix.de> wrote:
> Belisko Marek wrote:
>> On Fri, Oct 29, 2010 at 11:26 AM, Marc Kleine-Budde <mkl@pengutronix.de>
> wrote:
>> > On 10/29/2010 11:21 AM, Belisko Marek wrote:
>> >>>>> do you have a "MEM=32" on your command line?
>> >>>>
>> >>>> Well I add it but same result:
>> >>>
>> >>> BTW: It must be "mem=", in lowercase, but you did this.
>> >>>
>> >>> What I was meant to ask was, if you forget to add the "M" to "32".
>> >>> Because with mem=32 you tell Linux just to use 32 bytes of memory.
>> >>> Maybe your ATAGs are broken, Linux might not see the whole RAM or any
>> >>> if it.
>> >>
>> >> yes it was typo I forgot put M after 32. Kernel now properly boot :).
>> >
>> > How much RAM you you have? Adjust mem= accordingly.
>>
>> Have 64M I will adjust.
>>
>> >> U-boot somehow
>> >> add kernel this parameter? Because for u-boot I don't need to set this
>> >> parameter.
>> >
>> > Nope - u-boot and barebox set up this information in the ATAG list.
>> > Seems something is broken with your ATAG list.
>>
>> Could be a problem thats I load barebox directly to ram and run it and
>> then RAM size isn't probed
>> and correctly set in atags?
>
> No, you need something like that:
>
> [...]
> static struct memory_platform_data ram_pdata = {
> .name = "ram0",
> .flags = DEVFS_RDWR,
> };
>
> struct device_d mini_sdram_dev = {
> .id = -1,
> .name = "mem",
> .map_base = CS6_BASE,
> .size = 64 * 1024 * 1024,
> .platform_data = &ram_pdata,
> };
Suppose similar must be done for a9m24xx boards?
>
> [...]
>
> static int mini2440_devices_init(void)
> {
> [...]
> register_device(&mini2440_sdram_dev);
> [...]
> armlinux_add_dram(&mini2440_sdram_dev);
> [...]
> }
>
> jbe
>
> --
> Pengutronix e.K. | Juergen Beisert |
> Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
> Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
>
thanks,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
icq: 290551086
web: http://open-nandra.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH] curl: make CURL_FEATURES configurable again
From: Michael Smith @ 2010-11-02 13:49 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <20101030101545.GB21651@denix.org>
Denys Dmytriyenko wrote:
> It has been discussed before (check irc logs 7-10 days ago) and Khem made a
> change to introduce new override called "target", which can be used in this
> case. Anyway, I ended up fixing it by amend in my overlay:
>
> http://arago-project.org/git/?p=arago.git;a=commitdiff;h=37979c41a04f7712dbf9c325871fea7c01cc737a
Yes - the target override patch didn't go in, but I agree it would make
this easier.
Anon python seems to be going out of style so the v2 curl patch uses
variable settings with a native override to ensure gnutls isn't in the
feature list.
Mike
^ permalink raw reply
* [PATCH 2/4] staging: ft1000: Use common return point.
From: Marek Belisko @ 2010-11-02 13:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Marek Belisko; +Cc: devel, linux-kernel, Marek Belisko
In-Reply-To: <1288705907-30725-1-git-send-email-marek.belisko@gmail.com>
Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
drivers/staging/ft1000/ft1000-usb/ft1000_hw.c | 23 +++++++++--------------
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
index 9bb5377..0de4a2e 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
@@ -1121,14 +1121,13 @@ static int ft1000_start_xmit(struct sk_buff *skb, struct net_device *dev)
if ( skb == NULL )
{
DEBUG ("ft1000_hw: ft1000_start_xmit:skb == NULL!!!\n" );
- return STATUS_FAILURE;
+ return NETDEV_TX_OK;
}
if ( pFt1000Dev->status & FT1000_STATUS_CLOSING)
{
DEBUG("network driver is closed, return\n");
- dev_kfree_skb(skb);
- return STATUS_SUCCESS;
+ goto err;
}
//DEBUG("ft1000_start_xmit 1:length of packet = %d\n", skb->len);
@@ -1147,28 +1146,24 @@ static int ft1000_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
/* Drop packet is mediastate is down */
DEBUG("ft1000_hw:ft1000_start_xmit:mediastate is down\n");
- dev_kfree_skb(skb);
- return STATUS_SUCCESS;
+ goto err;
}
if ( (skb->len < ENET_HEADER_SIZE) || (skb->len > ENET_MAX_SIZE) )
{
/* Drop packet which has invalid size */
DEBUG("ft1000_hw:ft1000_start_xmit:invalid ethernet length\n");
- dev_kfree_skb(skb);
- return STATUS_SUCCESS;
+ goto err;
}
//mbelian
- if(ft1000_copy_down_pkt (dev, (pdata+ENET_HEADER_SIZE-2), skb->len - ENET_HEADER_SIZE + 2) == STATUS_FAILURE)
- {
- dev_kfree_skb(skb);
- return STATUS_SUCCESS;
- }
+ ft1000_copy_down_pkt(dev, (pdata+ENET_HEADER_SIZE-2),
+ skb->len - ENET_HEADER_SIZE + 2);
- dev_kfree_skb(skb);
+err:
+ dev_kfree_skb(skb);
//DEBUG(" ft1000_start_xmit() exit\n");
- return 0;
+ return NETDEV_TX_OK;
}
//---------------------------------------------------------------------------
--
1.7.1
^ permalink raw reply related
* Re: Fix format warning for drivers/xen/blktap/device.c for xen/stable-2.6.32.x pvops commit 6c72eadd151f6f1b904989532a83988af0ea661a
From: Teck Choon Giam @ 2010-11-02 13:50 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <AANLkTikpuqv9suwcjgxsAq4yVsz6cQDY_8Rnjd+FK75Z@mail.gmail.com>
From: Giam Teck Choon <giamteckchoon@gmail.com>
Fix compilation format warning in drivers/xen/blktap/device.c
drivers/xen/blktap/device.c: In function ‘blktap_device_create’:
drivers/xen/blktap/device.c:869: warning: format ‘%llu’ expects type
‘long long unsigned int’, but argument 5 has type ‘sector_t’
drivers/xen/blktap/device.c: In function ‘blktap_device_debug’:
drivers/xen/blktap/device.c:898: warning: format ‘%llu’ expects type
‘long long unsigned int’, but argument 4 has type ‘sector_t’
Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
---
drivers/xen/blktap/device.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/blktap/device.c b/drivers/xen/blktap/device.c
index e4fc23e..8f1d3a9 100644
--- a/drivers/xen/blktap/device.c
+++ b/drivers/xen/blktap/device.c
@@ -867,7 +867,8 @@ blktap_device_create(struct blktap *tap, struct
blktap_params *params)
set_bit(BLKTAP_DEVICE, &tap->dev_inuse);
dev_info(disk_to_dev(gd), "sector-size: %u capacity: %llu\n",
- queue_logical_block_size(rq), get_capacity(gd));
+ queue_logical_block_size(rq),
+ (unsigned long long)get_capacity(gd));
return 0;
@@ -895,7 +896,8 @@ blktap_device_debug(struct blktap *tap, char *buf,
size_t size)
s += snprintf(s, end - s,
"disk capacity:%llu sector size:%u\n",
- get_capacity(disk), queue_logical_block_size(q));
+ (unsigned long long)get_capacity(disk),
+ queue_logical_block_size(q));
s += snprintf(s, end - s,
"queue flags:%#lx plugged:%d stopped:%d empty:%d\n",
^ permalink raw reply related
* [PATCH 4/4] staging: ft1000: Check return value.
From: Marek Belisko @ 2010-11-02 13:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Marek Belisko; +Cc: devel, linux-kernel, Marek Belisko
In-Reply-To: <1288705907-30725-1-git-send-email-marek.belisko@gmail.com>
Function ft1000_submit_rx_urb() could fail so add checking
for return value.
Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
drivers/staging/ft1000/ft1000-usb/ft1000_hw.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
index 30a8475..1fa1f81 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
@@ -1347,6 +1347,7 @@ static int ft1000_open (struct net_device *dev)
{
struct ft1000_info *pInfo = (struct ft1000_info *)netdev_priv(dev);
struct timeval tv; //mbelian
+ int ret;
DEBUG("ft1000_open is called for card %d\n", pInfo->CardNumber);
//DEBUG("ft1000_open: dev->addr=%x, dev->addr_len=%d\n", dev->addr, dev->addr_len);
@@ -1364,8 +1365,9 @@ static int ft1000_open (struct net_device *dev)
netif_carrier_on(dev); //mbelian
- ft1000_submit_rx_urb(pInfo);
- return 0;
+ ret = ft1000_submit_rx_urb(pInfo);
+
+ return ret;
}
//---------------------------------------------------------------------------
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] staging: ft1000: Correct return error values.
From: Marek Belisko @ 2010-11-02 13:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Marek Belisko; +Cc: devel, linux-kernel, Marek Belisko
In-Reply-To: <1288705907-30725-1-git-send-email-marek.belisko@gmail.com>
Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
drivers/staging/ft1000/ft1000-usb/ft1000_hw.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
index 0de4a2e..30a8475 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
@@ -1306,7 +1306,7 @@ static int ft1000_submit_rx_urb(struct ft1000_info *info)
{
DEBUG("network driver is closed, return\n");
//usb_kill_urb(pFt1000Dev->rx_urb); //mbelian
- return STATUS_SUCCESS;
+ return -ENODEV;
}
usb_fill_bulk_urb(pFt1000Dev->rx_urb,
@@ -1321,12 +1321,12 @@ static int ft1000_submit_rx_urb(struct ft1000_info *info)
if((result = usb_submit_urb(pFt1000Dev->rx_urb, GFP_ATOMIC)))
{
printk("ft1000_submit_rx_urb: submitting rx_urb %d failed\n", result);
- return STATUS_FAILURE;
+ return result;
}
//DEBUG("ft1000_submit_rx_urb exit: result=%d\n", result);
- return STATUS_SUCCESS;
+ return 0;
}
//---------------------------------------------------------------------------
--
1.7.1
^ permalink raw reply related
* [PATCH 1/4] staging: ft1000: Use specific error codes instead self defined.
From: Marek Belisko @ 2010-11-02 13:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Marek Belisko; +Cc: devel, linux-kernel, Marek Belisko
Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
drivers/staging/ft1000/ft1000-usb/ft1000_hw.c | 27 +++++++++---------------
1 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
index 90394e1..9bb5377 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
@@ -1025,7 +1025,7 @@ static int ft1000_copy_down_pkt (struct net_device *netdev, u8 *packet, u16 len)
{
DEBUG("ft1000_copy_down_pkt::Card Not Ready\n");
- return STATUS_FAILURE;
+ return -ENODEV;
}
@@ -1037,7 +1037,7 @@ static int ft1000_copy_down_pkt (struct net_device *netdev, u8 *packet, u16 len)
{
DEBUG("Error:ft1000_copy_down_pkt:Message Size Overflow!\n");
DEBUG("size = %d\n", count);
- return STATUS_FAILURE;
+ return -EINVAL;
}
if ( count % 4)
@@ -1080,25 +1080,18 @@ static int ft1000_copy_down_pkt (struct net_device *netdev, u8 *packet, u16 len)
}*/
- ret = usb_submit_urb(pFt1000Dev->tx_urb, GFP_ATOMIC);
- if(ret)
- {
+ ret = usb_submit_urb(pFt1000Dev->tx_urb, GFP_ATOMIC);
+ if (ret) {
DEBUG("ft1000 failed tx_urb %d\n", ret);
-
- return STATUS_FAILURE;
-
- }
- else
- {
- //DEBUG("ft1000 sucess tx_urb %d\n", ret);
-
- pInfo->stats.tx_packets++;
- pInfo->stats.tx_bytes += (len+14);
- }
+ return ret;
+ } else {
+ pInfo->stats.tx_packets++;
+ pInfo->stats.tx_bytes += (len+14);
+ }
//DEBUG("ft1000_copy_down_pkt() exit\n");
- return STATUS_SUCCESS;
+ return 0;
}
//---------------------------------------------------------------------------
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.