* fat64 implementation
From: Keshava Munegowda @ 2011-02-24 6:42 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-kernel
In-Reply-To: <20110224063749.GV22723@ZenIV.linux.org.uk>
Hi All
Is fat64 implementation is existing today? Are there any RFC patches?
Any body working on the implementation of fat64 file system?
Regards
Keshava Munegowda
^ permalink raw reply
* [linux-lvm] if clvm based on rhcs?
From: yue @ 2011-02-24 6:40 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 91 bytes --]
i use san , clvm based on san.
if i have to install rhcs ,if i want to use clvm?
thanks.
[-- Attachment #2: Type: text/html, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH] python-2.6: python-xml depends on python-elementtree
From: Martin Jansa @ 2011-02-24 6:38 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1298512974-1229-1-git-send-email-obi@opendreambox.org>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
On Thu, Feb 24, 2011 at 02:02:54AM +0000, Andreas Oberritter wrote:
> * Fixes the following error:
>
> import xml.etree.cElementTree
> File "/usr/lib/python2.6/xml/etree/cElementTree.py", line 3, in <module>
> from _elementtree import *
> ImportError: No module named _elementtree
>
> Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
> ---
> contrib/python/generate-manifest-2.6.py | 4 ++--
> recipes/python/python-2.6-manifest.inc | 4 ++--
> recipes/python/python_2.6.6.bb | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
Acked-by: Martin Jansa <Martin.Jansa@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-24 6:39 UTC (permalink / raw)
To: hiroshi.doyu, Guzman Lugo, Fernando
Cc: Sakari Ailus, linux-omap, linux-arm-kernel, tony
In-Reply-To: <AANLkTim+kcVxH=5pW51F0LFX=3igfWTgmthHN2F7tBB4@mail.gmail.com>
On Wed, Feb 23, 2011 at 11:48 PM, Guzman Lugo, Fernando
<fernando.lugo@ti.com> wrote:
> On Wed, Feb 23, 2011 at 2:56 PM, Sakari Ailus
> <sakari.ailus@maxwell.research.nokia.com> wrote:
>> David Cohen wrote:
>>> On Wed, Feb 23, 2011 at 3:39 PM, Guzman Lugo, Fernando
>>> <fernando.lugo@ti.com> wrote:
>>>> On Wed, Feb 23, 2011 at 3:45 AM, David Cohen <dacohen@gmail.com> wrote:
>>>>> On Wed, Feb 23, 2011 at 3:17 AM, Guzman Lugo, Fernando
>>>>> <fernando.lugo@ti.com> wrote:
>>>>>> On Wed, Feb 16, 2011 at 1:35 PM, David Cohen <dacohen@gmail.com> wrote:
>>>>>>> Add support to register an isr for IOMMU fault situations and adapt it
>>>>>>> to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
>>>>>>> module might want to be informed when errors happen in order to debug it
>>>>>>> or react.
>>>>>>>
>>>>>>> Signed-off-by: David Cohen <dacohen@gmail.com>
>>>>>>> ---
>>>>>>> arch/arm/mach-omap2/iommu2.c | 17 +++++++++-
>>>>>>> arch/arm/plat-omap/include/plat/iommu.h | 14 ++++++++-
>>>>>>> arch/arm/plat-omap/iommu.c | 52 ++++++++++++++++++++++---------
>>>>>>> 3 files changed, 65 insertions(+), 18 deletions(-)
>>>>>>>
>>>>>> ....
>>>>>>
>>>>>>> @@ -917,6 +912,33 @@ void iommu_put(struct iommu *obj)
>>>>>>> }
>>>>>>> EXPORT_SYMBOL_GPL(iommu_put);
>>>>>>>
>>>>>>> +int iommu_set_isr(const char *name,
>>>>>>> + int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
>>>>>>> + void *priv),
>>>>>>> + void *isr_priv)
>>>>>>> +{
>>>>>>> + struct device *dev;
>>>>>>> + struct iommu *obj;
>>>>>>> +
>>>>>>
>>>>>> if the driver support multiple user for the same iommu why can only
>>>>>> one callback be registered? should it support register multiple
>>>>>> callback function (one per user)?
>>>>>
>>>>> Can you define a scenario for that?
>>>>> On OMAP3 ISP the multiple users are the multiple ISP submodule, but I
>>>>> don't think it's necessary all submodule to have a specific callback.
>>>>> ISP core layer should handle.
>>>>
>>>> Hi,
>>>>
>>>> In OMAP4 the cortex M3 is a double core processor and as each core is
>>>> running they own version of the RTOS we threat them independently. So
>>>> our driver which controls the remote processor sees two processor but
>>>> both use the same iommu hw. When a iommu fault happens, at this
>>>> moment, it is consider as a faltal error and it is no managed to
>>>> recover and continue, instead a restart of the processor is needed, if
>>>> the fault happens in core0 we need to reset core1 too and vice versa.
>>>> if the iommu would support several user callbacks, we can register the
>>>> callback which resets core0 and also the callback which resets core1
>>>> and treat them as totally independent processors. Also we have an
>>>> error event notifier driver, which is only in charge of notifying
>>>> error events to userspace, so we would have multiple callbacks we
>>>> could do this
>>>
>>> I understood your point. In this case, I may not disagree about having
>>> more than one callback per obj, although it doesn't seem a nice
>>> scenario.
>>> We can have a list of callbacks and call the entire list when a fault
>>> happens. But it's necessary to pay attention it will happen in atomic
>>> context and users should not abuse and register many callbacks. The
>>> callback should *NOT* print useless messages and must verify the error
>>> code to not execute useless steps.
>>> In this context, callback and ISR cannot share a same pointer anymore.
>>
>> I think this is outside of the scope of the patch but...
>
> yes, the same behaviour was before the patches, but as the patches are
> changing the isr, I think it is a good time to modify, not in patch 2,
> but in a new patch to be added to the serie between patch 1 and 2, so
> that we dont need to change ISR part again after this set of patches.
Let's wait for Hiroshi's opinion and decide if I change or not the patches.
Br,
David
>
>>
>> To efficiently debug iommu faults (with a driver using iommu page
>> walking), besides the actual fault address the list of existing mappings
>> and the information which driver created them and for which purpose is
>> useful.
>>
>> The list of mappings is already available in the iommu structure. It'd
>> be nice if there was a function a driver could call to print them.
>
>>
>> I can only think of ugly ways to implement the other.
>>
>> Just my 5 cents (as we have no 2 cent coins here).
>>
>> Regards,
>>
>> --
>> Sakari Ailus
>> sakari.ailus@maxwell.research.nokia.com
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-24 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim+kcVxH=5pW51F0LFX=3igfWTgmthHN2F7tBB4@mail.gmail.com>
On Wed, Feb 23, 2011 at 11:48 PM, Guzman Lugo, Fernando
<fernando.lugo@ti.com> wrote:
> On Wed, Feb 23, 2011 at 2:56 PM, Sakari Ailus
> <sakari.ailus@maxwell.research.nokia.com> wrote:
>> David Cohen wrote:
>>> On Wed, Feb 23, 2011 at 3:39 PM, Guzman Lugo, Fernando
>>> <fernando.lugo@ti.com> wrote:
>>>> On Wed, Feb 23, 2011 at 3:45 AM, David Cohen <dacohen@gmail.com> wrote:
>>>>> On Wed, Feb 23, 2011 at 3:17 AM, Guzman Lugo, Fernando
>>>>> <fernando.lugo@ti.com> wrote:
>>>>>> On Wed, Feb 16, 2011 at 1:35 PM, David Cohen <dacohen@gmail.com> wrote:
>>>>>>> Add support to register an isr for IOMMU fault situations and adapt it
>>>>>>> to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
>>>>>>> module might want to be informed when errors happen in order to debug it
>>>>>>> or react.
>>>>>>>
>>>>>>> Signed-off-by: David Cohen <dacohen@gmail.com>
>>>>>>> ---
>>>>>>> ?arch/arm/mach-omap2/iommu2.c ? ? ? ? ? ?| ? 17 +++++++++-
>>>>>>> ?arch/arm/plat-omap/include/plat/iommu.h | ? 14 ++++++++-
>>>>>>> ?arch/arm/plat-omap/iommu.c ? ? ? ? ? ? ?| ? 52 ++++++++++++++++++++++---------
>>>>>>> ?3 files changed, 65 insertions(+), 18 deletions(-)
>>>>>>>
>>>>>> ....
>>>>>>
>>>>>>> @@ -917,6 +912,33 @@ void iommu_put(struct iommu *obj)
>>>>>>> ?}
>>>>>>> ?EXPORT_SYMBOL_GPL(iommu_put);
>>>>>>>
>>>>>>> +int iommu_set_isr(const char *name,
>>>>>>> + ? ? ? ? ? ? ? ? int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
>>>>>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?void *priv),
>>>>>>> + ? ? ? ? ? ? ? ? void *isr_priv)
>>>>>>> +{
>>>>>>> + ? ? ? struct device *dev;
>>>>>>> + ? ? ? struct iommu *obj;
>>>>>>> +
>>>>>>
>>>>>> if the driver support multiple user for the same iommu why can only
>>>>>> one callback be registered? should it support register multiple
>>>>>> callback function (one per user)?
>>>>>
>>>>> Can you define a scenario for that?
>>>>> On OMAP3 ISP the multiple users are the multiple ISP submodule, but I
>>>>> don't think it's necessary all submodule to have a specific callback.
>>>>> ISP core layer should handle.
>>>>
>>>> Hi,
>>>>
>>>> In OMAP4 the cortex M3 is a double core processor and as each core is
>>>> running they own version of the RTOS we threat them independently. So
>>>> our driver which controls the remote processor sees two processor but
>>>> both use the same iommu hw. When a iommu fault happens, at this
>>>> moment, it is consider as a faltal error and it is no managed to
>>>> recover and continue, instead a restart of the processor is needed, if
>>>> the fault happens in core0 we need to reset core1 too and vice versa.
>>>> if the iommu would support several user callbacks, we can register the
>>>> callback which resets core0 and also the callback which resets core1
>>>> and treat them as totally independent processors. Also we have an
>>>> error event notifier driver, which is only in charge of notifying
>>>> error events to userspace, so we would have multiple callbacks we
>>>> could do this
>>>
>>> I understood your point. In this case, I may not disagree about having
>>> more than one callback per obj, although it doesn't seem a nice
>>> scenario.
>>> We can have a list of callbacks and call the entire list when a fault
>>> happens. But it's necessary to pay attention it will happen in atomic
>>> context and users should not abuse and register many callbacks. The
>>> callback should *NOT* print useless messages and must verify the error
>>> code to not execute useless steps.
>>> In this context, callback and ISR cannot share a same pointer anymore.
>>
>> I think this is outside of the scope of the patch but...
>
> yes, the same behaviour was before the patches, but as the patches are
> changing the isr, I think it is a good time to modify, not in patch 2,
> but in a new patch to be added to the serie between patch 1 and 2, so
> that we dont need to change ISR part again after this set of patches.
Let's wait for Hiroshi's opinion and decide if I change or not the patches.
Br,
David
>
>>
>> To efficiently debug iommu faults (with a driver using iommu page
>> walking), besides the actual fault address the list of existing mappings
>> and the information which driver created them and for which purpose is
>> useful.
>>
>> The list of mappings is already available in the iommu structure. It'd
>> be nice if there was a function a driver could call to print them.
>
>>
>> I can only think of ugly ways to implement the other.
>>
>> Just my 5 cents (as we have no 2 cent coins here).
>>
>> Regards,
>>
>> --
>> Sakari Ailus
>> sakari.ailus at maxwell.research.nokia.com
>>
>
^ permalink raw reply
* [Cluster-devel] if gfs2 or clvm based on rhcs?
From: yue @ 2011-02-24 6:38 UTC (permalink / raw)
To: cluster-devel.redhat.com
i want to deploy iscsi+clvm+gfs2
i do not know if i have to install rhcs?
but i use fc12 ,not rhel.
what /etc/cluster/cluster.conf do ? how to configure the conf file?
thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20110224/ea8d48e6/attachment.htm>
^ permalink raw reply
* [PATCH v6] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Samreen @ 2011-02-24 6:38 UTC (permalink / raw)
To: linux-arm-kernel
Enabling all the display interface options to be built as module
And enabling all the display panels to be built as modules.
Signed-off-by: Samreen <samreen@ti.com>
---
Version6:
Enabling all the display interface options and all the display
panels.
Version5:
Incorporating the comments from Tony Lindgren, Kevin Hilman,
Paul Mundt & Tomi Valkeinen to build DSS & panels as modules.
See: https://patchwork.kernel.org/patch/281492/
Version4:
Remove the enabling of the display panels by default.
Version3:
Eliminate the separate default number of FBs for
different architecture. Keeping default FBs as 3 as before.
Version2:
Enables by default NEC panel used in zoom2/3/3630sdp, instead of
Sharp LQ043T1DG01 panel enabled in previous version of this patch.
Testing:
---------
The base used for OMAP3 testing is:
branch: master
commit: bb95b65a
URL: git://gitorious.org/linux-omap-dss2/linux.git
And OMAP4 testing is on the following branch + few patches to enable DSI taal panel:
branch: lo-dss2-Feb18
commit: 67bcb5600
URL: git://dev.omapzoom.org/pub/scm/axelcx/kernel-display.git
The patch is tested on 3630zoom, 3430sdp & 4430sdp, it was not tested
on OMAP2 platform due crash seen while boot.
(See: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43921.html)
arch/arm/configs/omap2plus_defconfig | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index ae890ca..407ccf8 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -192,6 +192,17 @@ CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_OMAP_LCD_VGA=y
+CONFIG_OMAP2_DSS=m
+CONFIG_OMAP2_DSS_RFBI=y
+CONFIG_OMAP2_DSS_SDI=y
+CONFIG_OMAP2_DSS_DSI=y
+CONFIG_FB_OMAP2=m
+CONFIG_PANEL_GENERIC_DPI=m
+CONFIG_PANEL_SHARP_LS037V7DW01=m
+CONFIG_PANEL_NEC_NL8048HL11_01B=m
+CONFIG_PANEL_TAAL=m
+CONFIG_PANEL_TPO_TD043MTEA1=m
+CONFIG_PANEL_ACX565AKM=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
--
1.5.6.3
^ permalink raw reply related
* [PATCH] of/pdt: allow DT device matching by fixing 'name' brokenness (v4)
From: Andres Salomon @ 2011-02-24 6:38 UTC (permalink / raw)
To: Grant Likely
Cc: Daniel Drake, linux-kernel, devicetree-discuss, David S. Miller,
sparclinux
In-Reply-To: <20110224053814.GA6046@angua.secretlab.ca>
Commit e2f2a93b changed dp->name from using the 'name' property to
using package-to-path. This fixed /proc/device-tree creation by
eliminating conflicts between names (the 'name' property provides
names like 'battery', whereas package-to-path provides names like
'/foo/bar/battery@0', which we stripped to 'battery@0'). However,
it also breaks of_device_id table matching.
The fix that we _really_ wanted was to keep dp->name based upon
the name property ('battery'), but based dp->full_name upon
package-to-path ('battery@0'). This patch does just that.
This also changes OLPC behavior to use the full result from
package-to-path for full_name, rather than stripping the directory
out. In practice, the strings end up being exactly the same; this
change saves time, code, and memory.
v2: combine two patches and revert of_pdt_node_name to original version
v3: use dp->phandle instead of passing around node
v4: warn/bail out for non-sparc archs if pkg2path is not set
Signed-off-by: Andres Salomon <dilinger@queued.net>
---
drivers/of/pdt.c | 50 ++++++++++++++++++++++----------------------------
1 files changed, 22 insertions(+), 28 deletions(-)
diff --git a/drivers/of/pdt.c b/drivers/of/pdt.c
index 28295d0..61f6308 100644
--- a/drivers/of/pdt.c
+++ b/drivers/of/pdt.c
@@ -48,7 +48,9 @@ static inline void irq_trans_init(struct device_node *dp) { }
static inline const char *of_pdt_node_name(struct device_node *dp)
{
- return dp->name;
+ /* non-sparc archs should be setting a pkg2path hook */
+ WARN_ON(1);
+ return NULL;
}
#endif /* !CONFIG_SPARC */
@@ -134,7 +136,7 @@ static char * __init of_pdt_get_one_property(phandle node, const char *name)
static char * __init of_pdt_try_pkg2path(phandle node)
{
- char *res, *buf = NULL;
+ char *buf = NULL;
int len;
if (!of_pdt_prom_ops->pkg2path)
@@ -147,29 +149,6 @@ static char * __init of_pdt_try_pkg2path(phandle node)
pr_err("%s: package-to-path failed\n", __func__);
return NULL;
}
-
- res = strrchr(buf, '/');
- if (!res) {
- pr_err("%s: couldn't find / in %s\n", __func__, buf);
- return NULL;
- }
- return res+1;
-}
-
-/*
- * When fetching the node's name, first try using package-to-path; if
- * that fails (either because the arch hasn't supplied a PROM callback,
- * or some other random failure), fall back to just looking at the node's
- * 'name' property.
- */
-static char * __init of_pdt_build_name(phandle node)
-{
- char *buf;
-
- buf = of_pdt_try_pkg2path(node);
- if (!buf)
- buf = of_pdt_get_one_property(node, "name");
-
return buf;
}
@@ -187,7 +166,7 @@ static struct device_node * __init of_pdt_create_node(phandle node,
kref_init(&dp->kref);
- dp->name = of_pdt_build_name(node);
+ dp->name = of_pdt_get_one_property(node, "name");
dp->type = of_pdt_get_one_property(node, "device_type");
dp->phandle = node;
@@ -201,10 +180,25 @@ static struct device_node * __init of_pdt_create_node(phandle node,
static char * __init of_pdt_build_full_name(struct device_node *dp)
{
int len, ourlen, plen;
+ const char *name;
char *n;
+ /*
+ * When fetching the full name we want the name we see with
+ * package-to-path (ie, '/foo/bar/battery@0') rather than what
+ * we see with the name property (ie, 'battery').
+ */
+ n = of_pdt_try_pkg2path(dp->phandle);
+ if (n)
+ return n;
+
+ name = of_pdt_node_name(dp);
+ if (!name)
+ return NULL;
+
+ /* Older method for determining full name */
plen = strlen(dp->parent->full_name);
- ourlen = strlen(of_pdt_node_name(dp));
+ ourlen = strlen(name);
len = ourlen + plen + 2;
n = prom_early_alloc(len);
@@ -213,7 +207,7 @@ static char * __init of_pdt_build_full_name(struct device_node *dp)
strcpy(n + plen, "/");
plen++;
}
- strcpy(n + plen, of_pdt_node_name(dp));
+ strcpy(n + plen, name);
return n;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH] of/pdt: allow DT device matching by fixing 'name'
From: Andres Salomon @ 2011-02-24 6:38 UTC (permalink / raw)
To: Grant Likely
Cc: Daniel Drake, linux-kernel, devicetree-discuss, David S. Miller,
sparclinux
In-Reply-To: <20110224053814.GA6046@angua.secretlab.ca>
Commit e2f2a93b changed dp->name from using the 'name' property to
using package-to-path. This fixed /proc/device-tree creation by
eliminating conflicts between names (the 'name' property provides
names like 'battery', whereas package-to-path provides names like
'/foo/bar/battery@0', which we stripped to 'battery@0'). However,
it also breaks of_device_id table matching.
The fix that we _really_ wanted was to keep dp->name based upon
the name property ('battery'), but based dp->full_name upon
package-to-path ('battery@0'). This patch does just that.
This also changes OLPC behavior to use the full result from
package-to-path for full_name, rather than stripping the directory
out. In practice, the strings end up being exactly the same; this
change saves time, code, and memory.
v2: combine two patches and revert of_pdt_node_name to original version
v3: use dp->phandle instead of passing around node
v4: warn/bail out for non-sparc archs if pkg2path is not set
Signed-off-by: Andres Salomon <dilinger@queued.net>
---
drivers/of/pdt.c | 50 ++++++++++++++++++++++----------------------------
1 files changed, 22 insertions(+), 28 deletions(-)
diff --git a/drivers/of/pdt.c b/drivers/of/pdt.c
index 28295d0..61f6308 100644
--- a/drivers/of/pdt.c
+++ b/drivers/of/pdt.c
@@ -48,7 +48,9 @@ static inline void irq_trans_init(struct device_node *dp) { }
static inline const char *of_pdt_node_name(struct device_node *dp)
{
- return dp->name;
+ /* non-sparc archs should be setting a pkg2path hook */
+ WARN_ON(1);
+ return NULL;
}
#endif /* !CONFIG_SPARC */
@@ -134,7 +136,7 @@ static char * __init of_pdt_get_one_property(phandle node, const char *name)
static char * __init of_pdt_try_pkg2path(phandle node)
{
- char *res, *buf = NULL;
+ char *buf = NULL;
int len;
if (!of_pdt_prom_ops->pkg2path)
@@ -147,29 +149,6 @@ static char * __init of_pdt_try_pkg2path(phandle node)
pr_err("%s: package-to-path failed\n", __func__);
return NULL;
}
-
- res = strrchr(buf, '/');
- if (!res) {
- pr_err("%s: couldn't find / in %s\n", __func__, buf);
- return NULL;
- }
- return res+1;
-}
-
-/*
- * When fetching the node's name, first try using package-to-path; if
- * that fails (either because the arch hasn't supplied a PROM callback,
- * or some other random failure), fall back to just looking at the node's
- * 'name' property.
- */
-static char * __init of_pdt_build_name(phandle node)
-{
- char *buf;
-
- buf = of_pdt_try_pkg2path(node);
- if (!buf)
- buf = of_pdt_get_one_property(node, "name");
-
return buf;
}
@@ -187,7 +166,7 @@ static struct device_node * __init of_pdt_create_node(phandle node,
kref_init(&dp->kref);
- dp->name = of_pdt_build_name(node);
+ dp->name = of_pdt_get_one_property(node, "name");
dp->type = of_pdt_get_one_property(node, "device_type");
dp->phandle = node;
@@ -201,10 +180,25 @@ static struct device_node * __init of_pdt_create_node(phandle node,
static char * __init of_pdt_build_full_name(struct device_node *dp)
{
int len, ourlen, plen;
+ const char *name;
char *n;
+ /*
+ * When fetching the full name we want the name we see with
+ * package-to-path (ie, '/foo/bar/battery@0') rather than what
+ * we see with the name property (ie, 'battery').
+ */
+ n = of_pdt_try_pkg2path(dp->phandle);
+ if (n)
+ return n;
+
+ name = of_pdt_node_name(dp);
+ if (!name)
+ return NULL;
+
+ /* Older method for determining full name */
plen = strlen(dp->parent->full_name);
- ourlen = strlen(of_pdt_node_name(dp));
+ ourlen = strlen(name);
len = ourlen + plen + 2;
n = prom_early_alloc(len);
@@ -213,7 +207,7 @@ static char * __init of_pdt_build_full_name(struct device_node *dp)
strcpy(n + plen, "/");
plen++;
}
- strcpy(n + plen, of_pdt_node_name(dp));
+ strcpy(n + plen, name);
return n;
}
--
1.7.2.3
^ permalink raw reply related
* Re: proposed C API for librados
From: Hannu Valtonen @ 2011-02-24 6:38 UTC (permalink / raw)
To: Colin McCabe; +Cc: ceph-devel
In-Reply-To: <AANLkTi=qvZjPOHkZbPem0TPjovGiqNo7Arq=q2YqEWDS@mail.gmail.com>
On 2/24/11 8:09 AM, Colin McCabe wrote:
Hi,
If you're having a stab at this, could you please add a librados C api
for listing of pools at the same time. (it's available on the C++ side
but would be great to have on the C side for Python bindings)
> Hi all,
>
> We're trying to finalize the API for librados for the 0.25 release.
> This is the C API we're looking at.
>
> cheers,
> Colin
>
>
> =================================================================
> #ifndef CEPH_LIBRADOS_H
> #define CEPH_LIBRADOS_H
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> #include<netinet/in.h>
> #include<linux/types.h>
> #include<string.h>
>
> #ifndef CEPH_OSD_TMAP_SET
> #define CEPH_OSD_TMAP_HDR 'h'
> #define CEPH_OSD_TMAP_SET 's'
> #define CEPH_OSD_TMAP_RM 'r'
> #endif
>
> #define LIBRADOS_VER_MAJOR 0
> #define LIBRADOS_VER_MINOR 25
> #define LIBRADOS_VER_EXTRA 0
>
> #define LIBRADOS_VERSION(maj, min, extra) ((maj<< 16) + (min<< 8) + extra)
>
> #define LIBRADOS_VERSION_CODE LIBRADOS_VERSION(LIBRADOS_VER_MAJOR,
> LIBRADOS_VER_MINOR, LIBRADOS_VER_EXTRA)
>
> #define LIBRADOS_SUPPORTS_WATCH 1
>
> typedef void *rados_t;
> typedef void *rados_pool_t;
> typedef void *rados_list_ctx_t;
> typedef uint64_t rados_snap_t;
>
> struct rados_pool_stat_t {
> uint64_t num_bytes; // in bytes
> uint64_t num_kb; // in KB
> uint64_t num_objects;
> uint64_t num_object_clones;
> uint64_t num_object_copies; // num_objects * num_replicas
> uint64_t num_objects_missing_on_primary;
> uint64_t num_objects_unfound;
> uint64_t num_objects_degraded;
> uint64_t num_rd, num_rd_kb,num_wr, num_wr_kb;
> };
>
> struct rados_statfs_t {
> uint64_t kb, kb_used, kb_avail;
> uint64_t num_objects;
> };
>
>
> void rados_version(int *major, int *minor, int *extra);
>
> /* initialization */
> int rados_create(rados_t *cluster, const char * const id);
>
> /* Connect to the cluster */
> int rados_connect(rados_t cluster);
>
> /* destroy the cluster instance */
> void rados_destroy(rados_t cluster);
>
> /* Config
> *
> * Functions for manipulating the Ceph configuration at runtime.
> * After changing the Ceph configuration, you should call rados_conf_apply to
> * ensure that the changes have been applied.
> */
> int rados_conf_read_file(rados_t cluster, const char *path);
>
> /* Sets a configuration value from a string.
> * Returns 0 on success, error code otherwise. */
> int rados_conf_set(rados_t cluster, const char *option, const char *value);
>
> /* Reopens the log file.
> * You must do this after changing the logging configuration.
> * It is also good practice to call this from your SIGHUP signal
> handler, so that users can send you
> * a SIGHUP to reopen the log.
> */
> void rados_reopen_log(rados_t cluster);
>
> /* Returns a configuration value as a string.
> * If len is positive, that is the maximum number of bytes we'll write into the
> * buffer. If len == -1, we'll call malloc() and set *buf.
> * Returns 0 on success, error code otherwise. Returns ENAMETOOLONG if the
> * buffer is too short. */
> int rados_conf_get(rados_t cluster, const char *option, char *buf, int len);
> int rados_conf_get_alloc(rados_t cluster, const char *option, char **buf);
>
> /* pools */
> int rados_pool_open(rados_t cluster, const char *name, rados_pool_t *pool);
> int rados_pool_close(rados_pool_t pool);
> int rados_pool_lookup(rados_t cluster, const char *name);
>
> int rados_pool_stat(rados_pool_t pool, struct rados_pool_stat_t *stats);
>
> void rados_snap_set_read(rados_pool_t pool, rados_snap_t snap);
> int rados_snap_set_write_context(rados_pool_t pool, rados_snap_t seq,
> rados_snap_t *snaps, int num_snaps);
>
> int rados_pool_create(rados_t cluster, const char *name);
> int rados_pool_create_with_auid(rados_t cluster, const char *name,
> uint64_t auid);
> int rados_pool_create_with_crush_rule(rados_t cluster, const char
> *name, __u8 crush_rule);
> int rados_pool_create_with_all(rados_t cluster, const char *name, uint64_t auid,
> __u8 crush_rule);
> int rados_pool_delete(rados_pool_t pool);
> int rados_pool_set_auid(rados_pool_t pool, uint64_t auid);
>
> /* objects */
> int rados_objects_list_open(rados_pool_t pool, rados_list_ctx_t *ctx);
> int rados_objects_list_next(rados_list_ctx_t ctx, const char **entry);
> void rados_objects_list_close(rados_list_ctx_t ctx);
>
>
> /* snapshots */
> int rados_pool_snap_create(rados_pool_t pool, const char *snapname);
> int rados_pool_snap_remove(rados_pool_t pool, const char *snapname);
> int rados_pool_snap_rollback_object(rados_pool_t pool, const char *oid,
> const char *snapname);
> int rados_pool_selfmanaged_snap_create(rados_pool_t pool, uint64_t *snapid);
> int rados_pool_selfmanaged_snap_remove(rados_pool_t pool, uint64_t snapid);
> int rados_pool_snap_list(rados_pool_t pool, rados_snap_t *snaps, int maxlen);
> int rados_pool_snap_lookup(rados_pool_t pool, const char *name,
> rados_snap_t *id);
> int rados_pool_snap_get_name(rados_pool_t pool, rados_snap_t id, char
> *name, int maxlen);
>
> /* sync io */
> uint64_t rados_get_last_version(rados_pool_t pool);
>
> int rados_write(rados_pool_t pool, const char *oid, off_t off, const
> char *buf, size_t len);
> int rados_write_full(rados_pool_t pool, const char *oid, off_t off,
> const char *buf, size_t len);
> int rados_read(rados_pool_t pool, const char *oid, off_t off, char
> *buf, size_t len);
> int rados_remove(rados_pool_t pool, const char *oid);
> int rados_trunc(rados_pool_t pool, const char *oid, size_t size);
>
> /* attrs */
> int rados_getxattr(rados_pool_t pool, const char *o, const char *name,
> char *buf, size_t len);
> int rados_setxattr(rados_pool_t pool, const char *o, const char *name,
> const char *buf, size_t len);
> int rados_rmxattr(rados_pool_t pool, const char *o, const char *name);
>
> /* misc */
> int rados_stat(rados_pool_t pool, const char *o, uint64_t *psize,
> time_t *pmtime);
> int rados_tmap_update(rados_pool_t pool, const char *o, const char
> *cmdbuf, size_t cmdbuflen);
> int rados_exec(rados_pool_t pool, const char *oid, const char *cls,
> const char *method,
> const char *in_buf, size_t in_len, char *buf, size_t out_len);
>
> /* async io */
> typedef void *rados_completion_t;
> typedef void (*rados_callback_t)(rados_completion_t cb, void *arg);
>
> int rados_aio_create_completion(void *cb_arg, rados_callback_t
> cb_complete, rados_callback_t cb_safe,
> rados_completion_t *pc);
> int rados_aio_wait_for_complete(rados_completion_t c);
> int rados_aio_wait_for_safe(rados_completion_t c);
> int rados_aio_is_complete(rados_completion_t c);
> int rados_aio_is_safe(rados_completion_t c);
> int rados_aio_get_return_value(rados_completion_t c);
> uint64_t rados_aio_get_obj_ver(rados_completion_t c);
> void rados_aio_release(rados_completion_t c);
> int rados_aio_write(rados_pool_t pool, const char *oid,
> off_t off, const char *buf, size_t len,
> rados_completion_t completion);
> int rados_aio_write_full(rados_pool_t pool, const char *oid,
> off_t off, const char *buf, size_t len,
> rados_completion_t completion);
> int rados_aio_read(rados_pool_t pool, const char *oid,
> off_t off, char *buf, size_t len,
> rados_completion_t completion);
>
> /* watch/notify */
> typedef void (*rados_watchcb_t)(uint8_t opcode, uint64_t ver, void *arg);
> int rados_watch(rados_pool_t pool, const char *o, uint64_t ver,
> uint64_t *handle,
> rados_watchcb_t watchcb, void *arg);
> int rados_unwatch(rados_pool_t pool, const char *o, uint64_t handle);
> int rados_notify(rados_pool_t pool, const char *o, uint64_t ver);
>
> #ifdef __cplusplus
> }
> #endif
>
> #endif
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [RFC][PATCH] ext2: Resolve i_nlink race in ext2_rename
From: Al Viro @ 2011-02-24 6:37 UTC (permalink / raw)
To: Josh Hunt; +Cc: Jan Kara, linux-ext4, sandeen, linux-kernel, linux-fsdevel
In-Reply-To: <1298528501-32176-1-git-send-email-johunt@akamai.com>
On Wed, Feb 23, 2011 at 10:21:41PM -0800, Josh Hunt wrote:
> [resending: left Jan off the original mail by accident]
>
> We have a multi-threaded workload which is currently "losing" files in the form
> of unattached inodes. The workload is link, rename, unlink intensive. This is
> happening on an ext2 filesystem and have reproduced the issue in kernel
> 2.6.37. Here's a sample strace:
>
> open("/a/tmp/tmpfile.1296184058", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 9
> link("/a/tmp/tmpfile.1296184058", "/a/tmp/tmpfile.28117.1296184059") = 0
> rename("/a/tmp/tmpfile.28117.1296184059", "/a/tmp/tmpfile") = 0
> stat64("/a/tmp/tmpfile", {st_mode=S_IFREG|0644, st_size=24248267, ...}) = 0
> link("/a/tmp/tmpfile", "/a/tmp/submit/tmpfile") = 0
> open("/a/tmp/tmpfile.1296184058", O_RDONLY) = 13
> open("/a/tmp/submit/tmpfile.send.q9SNoL", O_RDWR|O_CREAT|O_EXCL, 0600) = 824
> rename("/a/tmp/submit/tmpfile", "/a/tmp/submit/tmpfile.send.q9SNoL") = 0
> unlink("/a/tmp/tmpfile.1296184058") = 0
> open("/a/tmp/submit/tmpfile.send.q9SNoL", O_RDONLY) = 827
> open("/a/tmp/submit/tmpfile.send.q9SNoL", O_RDONLY) = 828
> open("/a/tmp/submit/tmpfile.send.q9SNoL", O_RDONLY) = 829
> unlink("/a/tmp/submit/tmpfile.send.q9SNoL") = 0
>
> The application behavior shown above repeats indefinitely with most filenames
> changing during each iteration except for 'tmpfile'. Looking into this issue I
> see that vfs_rename_other() only takes i_mutex for the new inode and the new
> inode's directory as well as the old directory's mutex. This works for
> modifying the dir entry and appears to be fine for most filesystems, but
> ext2 and a few others (exofs, minix, nilfs2, omfs, sysv, ufs) modify i_nlink
> inside of their respective rename functions without grabbing the i_mutex. The
> modifications are done through calls to inode_inc_link_count(old_inode) and
> inode_dec_link_count(old_inode), etc.
>
> Taking the mutex for the old inode appears to resolve the issue of the
> lost files/unattached inodes that I am seeing with this workload. I've attached
> a patch below doing what I've described above. If this is an accepted solution
> I believe other filesystems may also be affected by this and I could provide
> a patch for those as well.
I don't know... The thing is, we mostly do that to make life easier for
fsck in case of crash. Other than that, there's no reason to play with
link count of that sucker at all. The question is, do we really want
such rename() interrupted by dirty shutdown to result in what looks like two
legitimate links to that inode without any indications of what had happened?
Note that fsck (at least on ext2) will correct link counts anyway and if
nothing else, we probably want some noise pointing to the inode in question...
IOW, maybe it's better to rip these inc/dec for old_inode out and replace
them with mark_inode_dirty() in place where we currently do dec. Comments?
^ permalink raw reply
* Re: Multicast snooping fixes and suggestions
From: Stephen Hemminger @ 2011-02-24 6:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Herbert Xu, Linus Lüssing, David S. Miller, bridge, netdev,
linux-kernel
In-Reply-To: <89132767-587d-4186-8eac-9692bed59a44@email.android.com>
On Wed, 23 Feb 2011 21:57:32 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:
> Ok, so stupid question... how do hardware switches deal with this? It would seem to me that if everyone behind say a Cisco switch had these kind of issues they would have limited appeal...
Real bridges run current newwer Spanning Tree Protocol that converges faster.
The current Linux STP code is on older standard (around 2001). The current STP
standard use RSTP which converges much faster.
http://en.wikipedia.org/wiki/Spanning_Tree_Protocol
There is a userspace RSTP daemon that almost nobody uses.
There are a number of other STP enhancements that are needed like
STP protection and MSTP, as welll as the Cisco non-standard STP VLAN stuff.
Fixing STP and testing it is a fairly project, too big for a spare time
effort and currently not something high enough on the project chart for me to
be able to dedicate much company time on. Contributions welcome.
^ permalink raw reply
* Re: [Bridge] Multicast snooping fixes and suggestions
From: Stephen Hemminger @ 2011-02-24 6:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: netdev, bridge, linux-kernel, Herbert Xu, Linus Lüssing,
David S. Miller
In-Reply-To: <89132767-587d-4186-8eac-9692bed59a44@email.android.com>
On Wed, 23 Feb 2011 21:57:32 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:
> Ok, so stupid question... how do hardware switches deal with this? It would seem to me that if everyone behind say a Cisco switch had these kind of issues they would have limited appeal...
Real bridges run current newwer Spanning Tree Protocol that converges faster.
The current Linux STP code is on older standard (around 2001). The current STP
standard use RSTP which converges much faster.
http://en.wikipedia.org/wiki/Spanning_Tree_Protocol
There is a userspace RSTP daemon that almost nobody uses.
There are a number of other STP enhancements that are needed like
STP protection and MSTP, as welll as the Cisco non-standard STP VLAN stuff.
Fixing STP and testing it is a fairly project, too big for a spare time
effort and currently not something high enough on the project chart for me to
be able to dedicate much company time on. Contributions welcome.
^ permalink raw reply
* Problems when try to alloc user bo using TTM
From: april @ 2011-02-24 6:34 UTC (permalink / raw)
To: dri-devel, dri-devel
Hi all:
TTM provide "ttm_bo_type_user" which create bo from user space memory.
I try to use this functions, but find some problems:
1. Can not get "pages" when driver try to bind user pages to GPU apterure.
ttm->state set to "tt_unbound" when add ttm structs, while
ttm_tt_populate prevent driver populate function called if ttm->state
is not "tt_unpopulated"
int ttm_tt_populate(struct ttm_tt *ttm)
{
struct page *page;
unsigned long i;
struct ttm_backend *be;
int ret;
if (ttm->state != tt_unpopulated)
return 0;
2. Page number may not be the size it rounded up.
eg.
supports allocate a user space BO size=5K, which round up to 2
pages,but it should be 3, if the user space memory like this
page1 page2 page3
_______________________
|_____|_____|_____|_____|
|<-------->|
5k
Thanks
april
^ permalink raw reply
* Re: [PATCH 0/3] Fixes for vfs-scale and vfs-automount
From: Ian Kent @ 2011-02-24 6:34 UTC (permalink / raw)
To: Al Viro
Cc: Trond Myklebust, David Howells, Kernel Mailing List,
linux-fsdevel, Linus Torvalds, Andrew Morton,
Linux NFS Mailing List, npiggin
In-Reply-To: <20110224035836.GS22723@ZenIV.linux.org.uk>
On Thu, 2011-02-24 at 03:58 +0000, Al Viro wrote:
>
> Anyway, I wonder why you care about __d_lookup_rcu() and ->d_inode stability;
> d_mountpoint() _is_ stable at that point (we hold vfsmount_lock) and you
> don't seem to look at ->d_inode at all in RCU case. Note that ->d_automount()
> is never called in RCU case at all; nor is ->lookup() and friends, so you
> really only have ->d_manage() to cope with, what with autofs4 having no
> ->d_revalidate() anymore.
It does now but it doesn't do a whole lot, just checks for a negative
dentry, returning false, and drops out of RCU mode when the dentry isn't
selected or being checked for expiry yet.
Indeed, I shouldn't need to care about it and checking for it doesn't
seem to do a whole lot.
I've seen walks fail with a dentry that has gone away (ie. I'm walking
in a tree that is being expired, they seem to be trees with no actual
mount at their base), which should be because I'm not catching the block
request at a higher level dentry. Unfortunately, including a check for
the base dentry in __follow_mount_rcu(), regardless of it being a
mountpoint, doesn't always catch the need to block either. That the tree
is being selected for expire is probably because the expire can't detect
a walk within the mount tree when the walker is between the
__d_lookup_rcu() and __follow_mount_rcu() calls. Jumping out of rcu-walk
mode in an added revalidate reduces the possibility of this happening
(assuming walks are sneaking in between dropping and acquiring the
vfsmount_lock) but doesn't eliminate it.
At this point I loop back to the trying to work out why a reference gets
picked up and the cycle repeats with various small changes to the
overall approach.
Actually, it's not just the root of a mount that is getting an extra
reference either. When I notice a root dentry has picked up a reference
(from a printk) and SIGKILL everything and start umounting manually I
get to a point in the tree where I need to umount autofs mounts twice,
which usually means nothing more than a get/put mismatch somewhere, but
in that case I normally don't see a root dentry pick up a reference.
That's confusing me too.
>
> BTW, Nick has moved to kernel.dk; whether he's still reachable there is
> a question, though - he seems to have disappeared since mid-January.
Yeah, I've forwarded a couple of messages where I forgot to change the
email. A few emails back Nick said he was following the thread anyway.
Ian
^ permalink raw reply
* Re: [PATCH 0/3] Fixes for vfs-scale and vfs-automount
From: Ian Kent @ 2011-02-24 6:34 UTC (permalink / raw)
To: Al Viro
Cc: Trond Myklebust, David Howells, Kernel Mailing List,
linux-fsdevel, Linus Torvalds, Andrew Morton,
Linux NFS Mailing List, npiggin-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20110224035836.GS22723-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
On Thu, 2011-02-24 at 03:58 +0000, Al Viro wrote:
>
> Anyway, I wonder why you care about __d_lookup_rcu() and ->d_inode stability;
> d_mountpoint() _is_ stable at that point (we hold vfsmount_lock) and you
> don't seem to look at ->d_inode at all in RCU case. Note that ->d_automount()
> is never called in RCU case at all; nor is ->lookup() and friends, so you
> really only have ->d_manage() to cope with, what with autofs4 having no
> ->d_revalidate() anymore.
It does now but it doesn't do a whole lot, just checks for a negative
dentry, returning false, and drops out of RCU mode when the dentry isn't
selected or being checked for expiry yet.
Indeed, I shouldn't need to care about it and checking for it doesn't
seem to do a whole lot.
I've seen walks fail with a dentry that has gone away (ie. I'm walking
in a tree that is being expired, they seem to be trees with no actual
mount at their base), which should be because I'm not catching the block
request at a higher level dentry. Unfortunately, including a check for
the base dentry in __follow_mount_rcu(), regardless of it being a
mountpoint, doesn't always catch the need to block either. That the tree
is being selected for expire is probably because the expire can't detect
a walk within the mount tree when the walker is between the
__d_lookup_rcu() and __follow_mount_rcu() calls. Jumping out of rcu-walk
mode in an added revalidate reduces the possibility of this happening
(assuming walks are sneaking in between dropping and acquiring the
vfsmount_lock) but doesn't eliminate it.
At this point I loop back to the trying to work out why a reference gets
picked up and the cycle repeats with various small changes to the
overall approach.
Actually, it's not just the root of a mount that is getting an extra
reference either. When I notice a root dentry has picked up a reference
(from a printk) and SIGKILL everything and start umounting manually I
get to a point in the tree where I need to umount autofs mounts twice,
which usually means nothing more than a get/put mismatch somewhere, but
in that case I normally don't see a root dentry pick up a reference.
That's confusing me too.
>
> BTW, Nick has moved to kernel.dk; whether he's still reachable there is
> a question, though - he seems to have disappeared since mid-January.
Yeah, I've forwarded a couple of messages where I forgot to change the
email. A few emails back Nick said he was following the thread anyway.
Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* [PATCH v6] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Samreen @ 2011-02-24 6:26 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, linux-fbdev
Cc: Tomi Valkeinen, Tony Lindgren, Kevin Hilman, Paul Mundt, Samreen
Enabling all the display interface options to be built as module
And enabling all the display panels to be built as modules.
Signed-off-by: Samreen <samreen@ti.com>
---
Version6:
Enabling all the display interface options and all the display
panels.
Version5:
Incorporating the comments from Tony Lindgren, Kevin Hilman,
Paul Mundt & Tomi Valkeinen to build DSS & panels as modules.
See: https://patchwork.kernel.org/patch/281492/
Version4:
Remove the enabling of the display panels by default.
Version3:
Eliminate the separate default number of FBs for
different architecture. Keeping default FBs as 3 as before.
Version2:
Enables by default NEC panel used in zoom2/3/3630sdp, instead of
Sharp LQ043T1DG01 panel enabled in previous version of this patch.
Testing:
---------
The base used for OMAP3 testing is:
branch: master
commit: bb95b65a
URL: git://gitorious.org/linux-omap-dss2/linux.git
And OMAP4 testing is on the following branch + few patches to enable DSI taal panel:
branch: lo-dss2-Feb18
commit: 67bcb5600
URL: git://dev.omapzoom.org/pub/scm/axelcx/kernel-display.git
The patch is tested on 3630zoom, 3430sdp & 4430sdp, it was not tested
on OMAP2 platform due crash seen while boot.
(See: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43921.html)
arch/arm/configs/omap2plus_defconfig | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index ae890ca..407ccf8 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -192,6 +192,17 @@ CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_OMAP_LCD_VGA=y
+CONFIG_OMAP2_DSS=m
+CONFIG_OMAP2_DSS_RFBI=y
+CONFIG_OMAP2_DSS_SDI=y
+CONFIG_OMAP2_DSS_DSI=y
+CONFIG_FB_OMAP2=m
+CONFIG_PANEL_GENERIC_DPI=m
+CONFIG_PANEL_SHARP_LS037V7DW01=m
+CONFIG_PANEL_NEC_NL8048HL11_01B=m
+CONFIG_PANEL_TAAL=m
+CONFIG_PANEL_TPO_TD043MTEA1=m
+CONFIG_PANEL_ACX565AKM=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
--
1.5.6.3
^ permalink raw reply related
* Re: [PULL REQUEST] md and related patches for 2.6.38
From: NeilBrown @ 2011-02-24 6:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Patterson, Jens Axboe, Jeff Moyer
In-Reply-To: <AANLkTinm95OYw2Sj0DuABTiG6eWzePcfAZyxOE0c4GsT@mail.gmail.com>
On Wed, 23 Feb 2011 22:01:49 -0800 Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Feb 23, 2011 at 9:53 PM, NeilBrown <neilb@suse.de> wrote:
> >
> > The most noteworthy is :
> > Fix over-zealous flush_disk when changing device size.
> >
> > which I include below in full.
>
> Gah.
>
> Why did you do that butt-ugly "__invalidate_device2()"?
>
> There are something like three users of that existing
> __invalidate_device() function, it would have made for a smaller and
> cleaner patch to just fix them all, rather than change the calling
> convention, create that ugly "2" function, and add the wrapper
> function.
>
> It's _doubly_ crazy, because that's exactly what you did to
> "invalidate_inodes()", so it has this crazy mix of "change one
> function" and "try to maintain another function unchanged".
>
> Why?
Seemed like a good idea at the time?
invalidate_inodes had precisely one caller so that seemed safe.
__invalidate_device had more - but I agree that two is not very many.
Revised patch - as below - can now be pull from the same place:
git://neil.brown.name/md for-linus
Thanks,
NeilBrown
>From 93b270f76e7ef3b81001576860c2701931cdc78b Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.de>
Date: Thu, 24 Feb 2011 17:25:47 +1100
Subject: [PATCH] Fix over-zealous flush_disk when changing device size.
There are two cases when we call flush_disk.
In one, the device has disappeared (check_disk_change) so any
data will hold becomes irrelevant.
In the oter, the device has changed size (check_disk_size_change)
so data we hold may be irrelevant.
In both cases it makes sense to discard any 'clean' buffers,
so they will be read back from the device if needed.
In the former case it makes sense to discard 'dirty' buffers
as there will never be anywhere safe to write the data. In the
second case it *does*not* make sense to discard dirty buffers
as that will lead to file system corruption when you simply enlarge
the containing devices.
flush_disk calls __invalidate_devices.
__invalidate_device calls both invalidate_inodes and invalidate_bdev.
invalidate_inodes *does* discard I_DIRTY inodes and this does lead
to fs corruption.
invalidate_bev *does*not* discard dirty pages, but I don't really care
about that at present.
So this patch adds a flag to __invalidate_device (calling it
__invalidate_device2) to indicate whether dirty buffers should be
killed, and this is passed to invalidate_inodes which can choose to
skip dirty inodes.
flusk_disk then passes true from check_disk_change and false from
check_disk_size_change.
dm avoids tripping over this problem by calling i_size_write directly
rathher than using check_disk_size_change.
md does use check_disk_size_change and so is affected.
This regression was introduced by commit 608aeef17a which causes
check_disk_size_change to call flush_disk, so it is suitable for any
kernel since 2.6.27.
Cc: stable@kernel.org
Acked-by: Jeff Moyer <jmoyer@redhat.com>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: NeilBrown <neilb@suse.de>
---
block/genhd.c | 2 +-
drivers/block/floppy.c | 2 +-
fs/block_dev.c | 12 ++++++------
fs/inode.c | 9 ++++++++-
fs/internal.h | 2 +-
include/linux/fs.h | 2 +-
6 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 6a5b772..cbf1112 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1355,7 +1355,7 @@ int invalidate_partition(struct gendisk *disk, int partno)
struct block_device *bdev = bdget_disk(disk, partno);
if (bdev) {
fsync_bdev(bdev);
- res = __invalidate_device(bdev);
+ res = __invalidate_device(bdev, true);
bdput(bdev);
}
return res;
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index b9ba04f..77fc76f 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -3281,7 +3281,7 @@ static int set_geometry(unsigned int cmd, struct floppy_struct *g,
struct block_device *bdev = opened_bdev[cnt];
if (!bdev || ITYPE(drive_state[cnt].fd_device) != type)
continue;
- __invalidate_device(bdev);
+ __invalidate_device(bdev, true);
}
mutex_unlock(&open_lock);
} else {
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 333a7bb..5e23152 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -927,9 +927,9 @@ EXPORT_SYMBOL_GPL(bd_unlink_disk_holder);
* when a disk has been changed -- either by a media change or online
* resize.
*/
-static void flush_disk(struct block_device *bdev)
+static void flush_disk(struct block_device *bdev, bool kill_dirty)
{
- if (__invalidate_device(bdev)) {
+ if (__invalidate_device(bdev, kill_dirty)) {
char name[BDEVNAME_SIZE] = "";
if (bdev->bd_disk)
@@ -966,7 +966,7 @@ void check_disk_size_change(struct gendisk *disk, struct block_device *bdev)
"%s: detected capacity change from %lld to %lld\n",
name, bdev_size, disk_size);
i_size_write(bdev->bd_inode, disk_size);
- flush_disk(bdev);
+ flush_disk(bdev, false);
}
}
EXPORT_SYMBOL(check_disk_size_change);
@@ -1019,7 +1019,7 @@ int check_disk_change(struct block_device *bdev)
if (!(events & DISK_EVENT_MEDIA_CHANGE))
return 0;
- flush_disk(bdev);
+ flush_disk(bdev, true);
if (bdops->revalidate_disk)
bdops->revalidate_disk(bdev->bd_disk);
return 1;
@@ -1601,7 +1601,7 @@ fail:
}
EXPORT_SYMBOL(lookup_bdev);
-int __invalidate_device(struct block_device *bdev)
+int __invalidate_device(struct block_device *bdev, bool kill_dirty)
{
struct super_block *sb = get_super(bdev);
int res = 0;
@@ -1614,7 +1614,7 @@ int __invalidate_device(struct block_device *bdev)
* hold).
*/
shrink_dcache_sb(sb);
- res = invalidate_inodes(sb);
+ res = invalidate_inodes(sb, kill_dirty);
drop_super(sb);
}
invalidate_bdev(bdev);
diff --git a/fs/inode.c b/fs/inode.c
index da85e56..c50d7fe 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -540,11 +540,14 @@ void evict_inodes(struct super_block *sb)
/**
* invalidate_inodes - attempt to free all inodes on a superblock
* @sb: superblock to operate on
+ * @kill_dirty: flag to guide handling of dirty inodes
*
* Attempts to free all inodes for a given superblock. If there were any
* busy inodes return a non-zero value, else zero.
+ * If @kill_dirty is set, discard dirty inodes too, otherwise treat
+ * them as busy.
*/
-int invalidate_inodes(struct super_block *sb)
+int invalidate_inodes(struct super_block *sb, bool kill_dirty)
{
int busy = 0;
struct inode *inode, *next;
@@ -556,6 +559,10 @@ int invalidate_inodes(struct super_block *sb)
list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) {
if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE))
continue;
+ if (inode->i_state & I_DIRTY && !kill_dirty) {
+ busy = 1;
+ continue;
+ }
if (atomic_read(&inode->i_count)) {
busy = 1;
continue;
diff --git a/fs/internal.h b/fs/internal.h
index 0663568..9b976b5 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -112,4 +112,4 @@ extern void release_open_intent(struct nameidata *);
*/
extern int get_nr_dirty_inodes(void);
extern void evict_inodes(struct super_block *);
-extern int invalidate_inodes(struct super_block *);
+extern int invalidate_inodes(struct super_block *, bool);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 32b38cd..683f4c5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2139,7 +2139,7 @@ extern void check_disk_size_change(struct gendisk *disk,
struct block_device *bdev);
extern int revalidate_disk(struct gendisk *);
extern int check_disk_change(struct block_device *);
-extern int __invalidate_device(struct block_device *);
+extern int __invalidate_device(struct block_device *, bool);
extern int invalidate_partition(struct gendisk *, int);
#endif
unsigned long invalidate_mapping_pages(struct address_space *mapping,
--
1.7.1
^ permalink raw reply related
* Re: [PULL REQUEST] md and related patches for 2.6.38
From: NeilBrown @ 2011-02-24 6:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Patterson, Jens Axboe, Jeff Moyer
In-Reply-To: <AANLkTinm95OYw2Sj0DuABTiG6eWzePcfAZyxOE0c4GsT@mail.gmail.com>
On Wed, 23 Feb 2011 22:01:49 -0800 Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Feb 23, 2011 at 9:53 PM, NeilBrown <neilb@suse.de> wrote:
> >
> > The most noteworthy is :
> > Fix over-zealous flush_disk when changing device size.
> >
> > which I include below in full.
>
> Gah.
>
> Why did you do that butt-ugly "__invalidate_device2()"?
>
> There are something like three users of that existing
> __invalidate_device() function, it would have made for a smaller and
> cleaner patch to just fix them all, rather than change the calling
> convention, create that ugly "2" function, and add the wrapper
> function.
>
> It's _doubly_ crazy, because that's exactly what you did to
> "invalidate_inodes()", so it has this crazy mix of "change one
> function" and "try to maintain another function unchanged".
>
> Why?
Seemed like a good idea at the time?
invalidate_inodes had precisely one caller so that seemed safe.
__invalidate_device had more - but I agree that two is not very many.
Revised patch - as below - can now be pull from the same place:
git://neil.brown.name/md for-linus
Thanks,
NeilBrown
From 93b270f76e7ef3b81001576860c2701931cdc78b Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.de>
Date: Thu, 24 Feb 2011 17:25:47 +1100
Subject: [PATCH] Fix over-zealous flush_disk when changing device size.
There are two cases when we call flush_disk.
In one, the device has disappeared (check_disk_change) so any
data will hold becomes irrelevant.
In the oter, the device has changed size (check_disk_size_change)
so data we hold may be irrelevant.
In both cases it makes sense to discard any 'clean' buffers,
so they will be read back from the device if needed.
In the former case it makes sense to discard 'dirty' buffers
as there will never be anywhere safe to write the data. In the
second case it *does*not* make sense to discard dirty buffers
as that will lead to file system corruption when you simply enlarge
the containing devices.
flush_disk calls __invalidate_devices.
__invalidate_device calls both invalidate_inodes and invalidate_bdev.
invalidate_inodes *does* discard I_DIRTY inodes and this does lead
to fs corruption.
invalidate_bev *does*not* discard dirty pages, but I don't really care
about that at present.
So this patch adds a flag to __invalidate_device (calling it
__invalidate_device2) to indicate whether dirty buffers should be
killed, and this is passed to invalidate_inodes which can choose to
skip dirty inodes.
flusk_disk then passes true from check_disk_change and false from
check_disk_size_change.
dm avoids tripping over this problem by calling i_size_write directly
rathher than using check_disk_size_change.
md does use check_disk_size_change and so is affected.
This regression was introduced by commit 608aeef17a which causes
check_disk_size_change to call flush_disk, so it is suitable for any
kernel since 2.6.27.
Cc: stable@kernel.org
Acked-by: Jeff Moyer <jmoyer@redhat.com>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: NeilBrown <neilb@suse.de>
---
block/genhd.c | 2 +-
drivers/block/floppy.c | 2 +-
fs/block_dev.c | 12 ++++++------
fs/inode.c | 9 ++++++++-
fs/internal.h | 2 +-
include/linux/fs.h | 2 +-
6 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 6a5b772..cbf1112 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1355,7 +1355,7 @@ int invalidate_partition(struct gendisk *disk, int partno)
struct block_device *bdev = bdget_disk(disk, partno);
if (bdev) {
fsync_bdev(bdev);
- res = __invalidate_device(bdev);
+ res = __invalidate_device(bdev, true);
bdput(bdev);
}
return res;
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index b9ba04f..77fc76f 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -3281,7 +3281,7 @@ static int set_geometry(unsigned int cmd, struct floppy_struct *g,
struct block_device *bdev = opened_bdev[cnt];
if (!bdev || ITYPE(drive_state[cnt].fd_device) != type)
continue;
- __invalidate_device(bdev);
+ __invalidate_device(bdev, true);
}
mutex_unlock(&open_lock);
} else {
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 333a7bb..5e23152 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -927,9 +927,9 @@ EXPORT_SYMBOL_GPL(bd_unlink_disk_holder);
* when a disk has been changed -- either by a media change or online
* resize.
*/
-static void flush_disk(struct block_device *bdev)
+static void flush_disk(struct block_device *bdev, bool kill_dirty)
{
- if (__invalidate_device(bdev)) {
+ if (__invalidate_device(bdev, kill_dirty)) {
char name[BDEVNAME_SIZE] = "";
if (bdev->bd_disk)
@@ -966,7 +966,7 @@ void check_disk_size_change(struct gendisk *disk, struct block_device *bdev)
"%s: detected capacity change from %lld to %lld\n",
name, bdev_size, disk_size);
i_size_write(bdev->bd_inode, disk_size);
- flush_disk(bdev);
+ flush_disk(bdev, false);
}
}
EXPORT_SYMBOL(check_disk_size_change);
@@ -1019,7 +1019,7 @@ int check_disk_change(struct block_device *bdev)
if (!(events & DISK_EVENT_MEDIA_CHANGE))
return 0;
- flush_disk(bdev);
+ flush_disk(bdev, true);
if (bdops->revalidate_disk)
bdops->revalidate_disk(bdev->bd_disk);
return 1;
@@ -1601,7 +1601,7 @@ fail:
}
EXPORT_SYMBOL(lookup_bdev);
-int __invalidate_device(struct block_device *bdev)
+int __invalidate_device(struct block_device *bdev, bool kill_dirty)
{
struct super_block *sb = get_super(bdev);
int res = 0;
@@ -1614,7 +1614,7 @@ int __invalidate_device(struct block_device *bdev)
* hold).
*/
shrink_dcache_sb(sb);
- res = invalidate_inodes(sb);
+ res = invalidate_inodes(sb, kill_dirty);
drop_super(sb);
}
invalidate_bdev(bdev);
diff --git a/fs/inode.c b/fs/inode.c
index da85e56..c50d7fe 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -540,11 +540,14 @@ void evict_inodes(struct super_block *sb)
/**
* invalidate_inodes - attempt to free all inodes on a superblock
* @sb: superblock to operate on
+ * @kill_dirty: flag to guide handling of dirty inodes
*
* Attempts to free all inodes for a given superblock. If there were any
* busy inodes return a non-zero value, else zero.
+ * If @kill_dirty is set, discard dirty inodes too, otherwise treat
+ * them as busy.
*/
-int invalidate_inodes(struct super_block *sb)
+int invalidate_inodes(struct super_block *sb, bool kill_dirty)
{
int busy = 0;
struct inode *inode, *next;
@@ -556,6 +559,10 @@ int invalidate_inodes(struct super_block *sb)
list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) {
if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE))
continue;
+ if (inode->i_state & I_DIRTY && !kill_dirty) {
+ busy = 1;
+ continue;
+ }
if (atomic_read(&inode->i_count)) {
busy = 1;
continue;
diff --git a/fs/internal.h b/fs/internal.h
index 0663568..9b976b5 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -112,4 +112,4 @@ extern void release_open_intent(struct nameidata *);
*/
extern int get_nr_dirty_inodes(void);
extern void evict_inodes(struct super_block *);
-extern int invalidate_inodes(struct super_block *);
+extern int invalidate_inodes(struct super_block *, bool);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 32b38cd..683f4c5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2139,7 +2139,7 @@ extern void check_disk_size_change(struct gendisk *disk,
struct block_device *bdev);
extern int revalidate_disk(struct gendisk *);
extern int check_disk_change(struct block_device *);
-extern int __invalidate_device(struct block_device *);
+extern int __invalidate_device(struct block_device *, bool);
extern int invalidate_partition(struct gendisk *, int);
#endif
unsigned long invalidate_mapping_pages(struct address_space *mapping,
--
1.7.1
^ permalink raw reply related
* [RFC][PATCH] ext2: Resolve i_nlink race in ext2_rename
From: Josh Hunt @ 2011-02-24 6:21 UTC (permalink / raw)
To: Jan Kara, linux-ext4; +Cc: sandeen, linux-kernel, linux-fsdevel, viro
[resending: left Jan off the original mail by accident]
We have a multi-threaded workload which is currently "losing" files in the form
of unattached inodes. The workload is link, rename, unlink intensive. This is
happening on an ext2 filesystem and have reproduced the issue in kernel
2.6.37. Here's a sample strace:
open("/a/tmp/tmpfile.1296184058", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 9
link("/a/tmp/tmpfile.1296184058", "/a/tmp/tmpfile.28117.1296184059") = 0
rename("/a/tmp/tmpfile.28117.1296184059", "/a/tmp/tmpfile") = 0
stat64("/a/tmp/tmpfile", {st_mode=S_IFREG|0644, st_size=24248267, ...}) = 0
link("/a/tmp/tmpfile", "/a/tmp/submit/tmpfile") = 0
open("/a/tmp/tmpfile.1296184058", O_RDONLY) = 13
open("/a/tmp/submit/tmpfile.send.q9SNoL", O_RDWR|O_CREAT|O_EXCL, 0600) = 824
rename("/a/tmp/submit/tmpfile", "/a/tmp/submit/tmpfile.send.q9SNoL") = 0
unlink("/a/tmp/tmpfile.1296184058") = 0
open("/a/tmp/submit/tmpfile.send.q9SNoL", O_RDONLY) = 827
open("/a/tmp/submit/tmpfile.send.q9SNoL", O_RDONLY) = 828
open("/a/tmp/submit/tmpfile.send.q9SNoL", O_RDONLY) = 829
unlink("/a/tmp/submit/tmpfile.send.q9SNoL") = 0
The application behavior shown above repeats indefinitely with most filenames
changing during each iteration except for 'tmpfile'. Looking into this issue I
see that vfs_rename_other() only takes i_mutex for the new inode and the new
inode's directory as well as the old directory's mutex. This works for
modifying the dir entry and appears to be fine for most filesystems, but
ext2 and a few others (exofs, minix, nilfs2, omfs, sysv, ufs) modify i_nlink
inside of their respective rename functions without grabbing the i_mutex. The
modifications are done through calls to inode_inc_link_count(old_inode) and
inode_dec_link_count(old_inode), etc.
Taking the mutex for the old inode appears to resolve the issue of the
lost files/unattached inodes that I am seeing with this workload. I've attached
a patch below doing what I've described above. If this is an accepted solution
I believe other filesystems may also be affected by this and I could provide
a patch for those as well.
Thanks
Josh
ext2_rename modifies old_inode's nlink values through
inode_inc_link_count(old_inode) and inode_dec_link_count(old_inode) without
holding old_inode's mutex. vfs_rename_other() only takes the mutex of the new
inode and directory and old inode's directory. This causes old inode's nlink
values to become incorrect and results in an unattached inode.
CC: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Josh Hunt <johunt@akamai.com>
---
fs/ext2/namei.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/ext2/namei.c b/fs/ext2/namei.c
index 2e1d834..827839a 100644
--- a/fs/ext2/namei.c
+++ b/fs/ext2/namei.c
@@ -321,6 +321,8 @@ static int ext2_rename (struct inode * old_dir, struct dentry * old_dentry,
dquot_initialize(old_dir);
dquot_initialize(new_dir);
+ mutex_lock(&old_inode->i_mutex);
+
old_de = ext2_find_entry (old_dir, &old_dentry->d_name, &old_page);
if (!old_de)
goto out;
@@ -375,6 +377,7 @@ static int ext2_rename (struct inode * old_dir, struct dentry * old_dentry,
ext2_delete_entry (old_de, old_page);
inode_dec_link_count(old_inode);
+ mutex_unlock(&old_inode->i_mutex);
if (dir_de) {
if (old_dir != new_dir)
@@ -397,6 +400,7 @@ out_old:
kunmap(old_page);
page_cache_release(old_page);
out:
+ mutex_unlock(&old_inode->i_mutex);
return err;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v3 5/5] OMAP: adapt hsmmc to hwmod framework
From: Varadarajan, Charulatha @ 2011-02-24 6:28 UTC (permalink / raw)
To: Kishore Kadiyala
Cc: linux-mmc, linux-omap, tony, cjb, madhu.cr, khilman, paul,
Benoit Cousson
In-Reply-To: <1298483231-29622-6-git-send-email-kishore.kadiyala@ti.com>
Kishore,
On Wed, Feb 23, 2011 at 23:17, Kishore Kadiyala <kishore.kadiyala@ti.com> wrote:
> Changes involves:
> 1) Remove controller reset in devices.c which is taken care of
> by hwmod framework.
> 2) Removing all base address macro defines except keeping one for OMAP2420.
why?
> 3) Using omap-device layer to register device and utilizing data from
> hwmod data file for base address, dma channel number, Irq_number,
> device attribute.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> CC: Kevin Hilman <khilman@deeprootsystems.com>
> ---
> arch/arm/mach-omap2/devices.c | 251 ---------------------------------
> arch/arm/mach-omap2/hsmmc.c | 153 ++++++++++++++++++--
> arch/arm/plat-omap/include/plat/mmc.h | 14 --
> 3 files changed, 141 insertions(+), 277 deletions(-)
>
<<snip>>
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index 34272e4..b6e1eae 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -16,7 +16,11 @@
> #include <mach/hardware.h>
> #include <plat/mmc.h>
> #include <plat/omap-pm.h>
> +#include <plat/mux.h>
> +#include <plat/omap_hwmod.h>
> +#include <plat/omap_device.h>
>
> +#include "mux.h"
> #include "hsmmc.h"
> #include "control.h"
>
> @@ -30,7 +34,7 @@ static u16 control_mmc1;
>
> static struct hsmmc_controller {
> char name[HSMMC_NAME_LEN + 1];
> -} hsmmc[OMAP34XX_NR_MMC];
> +} hsmmc[OMAP44XX_NR_MMC];
Why do you have a dependency on OMAP44XX_NR_MMC? You should get
this kind of information using number of iterations in *_hwmod_each_by_class.
>
> #if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM)
>
> @@ -204,7 +208,141 @@ static int nop_mmc_set_power(struct device *dev, int slot, int power_on,
> return 0;
> }
>
> -static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_MMC] __initdata;
> +static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
> + int controller_nr)
> +{
> + if ((mmc_controller->slots[0].switch_pin > 0) && \
> + (mmc_controller->slots[0].switch_pin < OMAP_MAX_GPIO_LINES))
> + omap_mux_init_gpio(mmc_controller->slots[0].switch_pin,
> + OMAP_PIN_INPUT_PULLUP);
> + if ((mmc_controller->slots[0].gpio_wp > 0) && \
> + (mmc_controller->slots[0].gpio_wp < OMAP_MAX_GPIO_LINES))
> + omap_mux_init_gpio(mmc_controller->slots[0].gpio_wp,
> + OMAP_PIN_INPUT_PULLUP);
> + if (cpu_is_omap34xx()) {
> + if (controller_nr == 0) {
> + omap_mux_init_signal("sdmmc1_clk",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc1_cmd",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc1_dat0",
> + OMAP_PIN_INPUT_PULLUP);
> + if (mmc_controller->slots[0].caps &
> + (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
> + omap_mux_init_signal("sdmmc1_dat1",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc1_dat2",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc1_dat3",
> + OMAP_PIN_INPUT_PULLUP);
> + }
> + if (mmc_controller->slots[0].caps &
> + MMC_CAP_8_BIT_DATA) {
> + omap_mux_init_signal("sdmmc1_dat4",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc1_dat5",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc1_dat6",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc1_dat7",
> + OMAP_PIN_INPUT_PULLUP);
> + }
> + }
> + if (controller_nr == 1) {
> + /* MMC2 */
> + omap_mux_init_signal("sdmmc2_clk",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc2_cmd",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc2_dat0",
> + OMAP_PIN_INPUT_PULLUP);
> +
> + /*
> + * For 8 wire configurations, Lines DAT4, 5, 6 and 7
> + * need to be muxed in the board-*.c files
> + */
> + if (mmc_controller->slots[0].caps &
> + (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
> + omap_mux_init_signal("sdmmc2_dat1",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc2_dat2",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc2_dat3",
> + OMAP_PIN_INPUT_PULLUP);
> + }
> + if (mmc_controller->slots[0].caps &
> + MMC_CAP_8_BIT_DATA) {
> + omap_mux_init_signal("sdmmc2_dat4.sdmmc2_dat4",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc2_dat5.sdmmc2_dat5",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc2_dat6.sdmmc2_dat6",
> + OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_signal("sdmmc2_dat7.sdmmc2_dat7",
> + OMAP_PIN_INPUT_PULLUP);
> + }
> + }
> +
> + /*
> + * For MMC3 the pins need to be muxed in the board-*.c files
> + */
> + }
> +}
> +
> +static struct omap_mmc_platform_data *hsmmc_data[OMAP44XX_NR_MMC] __initdata;
Ditto
> +
> +static struct omap_device_pm_latency omap_hsmmc_latency[] = {
> + [0] = {
> + .deactivate_func = omap_device_idle_hwmods,
> + .activate_func = omap_device_enable_hwmods,
> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> + },
> + /*
> + * XXX There should also be an entry here to power off/on the
> + * MMC regulators/PBIAS cells, etc.
> + */
> +};
> +
> +static int omap2_mmc_init(struct omap_hwmod *oh, void *hsmmcinfo)
> +{
> + struct omap_device *od;
> + struct omap_device_pm_latency *ohl;
> + char *name;
> + int ohl_cnt = 0;
> + struct mmc_dev_attr *mmc_dattr = oh->dev_attr;
> + struct omap2_hsmmc_info *c = (struct omap2_hsmmc_info *) hsmmcinfo;
> + int idx;
> + static int mmc_num;
> +
> + /* Initialization of controllers which are not updated
> + * in board file will be skipped here.
> + */
Check multi-line comment style
> + c += mmc_num;
> + if (!c->mmc) {
> + pr_err("omap_hsmmc_info is not updated in board file\n");
> + return 0;
> + }
> + idx = c->mmc - 1 ;
> + name = "mmci-omap-hs";
> + ohl = omap_hsmmc_latency;
> + ohl_cnt = ARRAY_SIZE(omap_hsmmc_latency);
> + omap2_mmc_mux(hsmmc_data[idx], idx);
> + hsmmc_data[idx]->controller_dev_attr = mmc_dattr->flags;
It would be good rename controller_dev_attr to controller_flag
> + od = omap_device_build(name, idx, oh, hsmmc_data[idx],
> + sizeof(struct omap_mmc_platform_data), ohl, ohl_cnt, false);
> + if (IS_ERR(od)) {
> + WARN(1, "Cant build omap_device for %s:%s.\n",
> + name, oh->name);
> + return PTR_ERR(od);
> + }
> + /*
> + * return device handle to board setup code
> + * required to populate for regulator framework structure
> + */
> + c->dev = &od->pdev.dev;
> + mmc_num++;
> + return 0;
> +}
>
> void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
> {
> @@ -358,16 +496,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
> hsmmc_data[c->mmc - 1] = mmc;
> }
>
> - omap2_init_mmc(hsmmc_data, OMAP34XX_NR_MMC);
> -
> - /* pass the device nodes back to board setup code */
> - for (c = controllers; c->mmc; c++) {
> - struct omap_mmc_platform_data *mmc = hsmmc_data[c->mmc - 1];
> -
> - if (!c->mmc || c->mmc > nr_hsmmc)
> - continue;
> - c->dev = mmc->dev;
> - }
> + omap_hwmod_for_each_by_class("mmc", omap2_mmc_init, controllers);
>
> done:
> for (i = 0; i < nr_hsmmc; i++)
> diff --git a/arch/arm/plat-omap/include/plat/mmc.h b/arch/arm/plat-omap/include/plat/mmc.h
> index 7853130..6205984 100644
> --- a/arch/arm/plat-omap/include/plat/mmc.h
> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> @@ -24,20 +24,12 @@
> #define OMAP1_MMC2_BASE 0xfffb7c00 /* omap16xx only */
>
> #define OMAP24XX_NR_MMC 2
> -#define OMAP34XX_NR_MMC 3
> #define OMAP44XX_NR_MMC 5
As mentioned above, OMAP44XX_NR_MMC & OMAP24XX_NR_MMC shall be
removed and instead get these info from hwmod.
I had provided the same comment in the previous patch version too. You may
reject the comment but mention the reasons for the same.
> #define OMAP2420_MMC_SIZE OMAP1_MMC_SIZE
> -#define OMAP3_HSMMC_SIZE 0x200
> #define OMAP4_HSMMC_SIZE 0x1000
Can't this be removed?
> #define OMAP2_MMC1_BASE 0x4809c000
> #define OMAP2_MMC2_BASE 0x480b4000
> -#define OMAP3_MMC3_BASE 0x480ad000
> -#define OMAP4_MMC4_BASE 0x480d1000
> -#define OMAP4_MMC5_BASE 0x480d5000
> #define OMAP4_MMC_REG_OFFSET 0x100
Remove OMAP4_MMC_REG_OFFSET too.
> -#define HSMMC5 (1 << 4)
> -#define HSMMC4 (1 << 3)
> -#define HSMMC3 (1 << 2)
> #define HSMMC2 (1 << 1)
> #define HSMMC1 (1 << 0)
<<snip>>
^ permalink raw reply
* setup_timer
From: Mohammed Shafi @ 2011-02-24 6:28 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <AANLkTinqchTWU+XyojkOoqus7_kQVo0oBHaD5hmNYCkN@mail.gmail.com>
On Wed, Feb 23, 2011 at 9:25 PM, Dave Hylands <dhylands@gmail.com> wrote:
> Hi shafi,
>
> On Wed, Feb 23, 2011 at 8:09 AM, Mohammed Shafi <shafi.kernel@gmail.com>
> wrote:
> > Hi all,
> > can some please explain what does setup_timer does.
> > thanks in advance,
>
> It initializes the timer structure and stores the callback function
> which will be called when the timer expires.
>
Dave thanks a lot for your reply and your simple answer cleared my doubts
completely!
I was looking at a protocol stack code where this function is used in few
places and now I am able to understand it.
thanks once again!
>
> Dave Hylands
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110224/8ca883af/attachment.html
^ permalink raw reply
* linux-next IPv4 connect() call to dest routed over ppp broken
From: Valdis.Kletnieks @ 2011-02-24 6:27 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3777 bytes --]
l2.6.38-rc5-next-20110222 is giving me trouble with network - specifically IPv4
routed over a PPP link. IPv6 seems to be OK, as does IPv4 not over PPP.
Problem entered sometime after -rc2-mmotm0125 (I didn't try -rc3 or -rc4 due to
time constraints that kept me from chasing down a different problem I had).
I'm at home, so I bring up a PPP link to our VPN endpoint, and route 2 /16s
via the PPP connection. So ifconfig and routing look like this:
ppp0 Link encap:Point-to-Point Protocol
inet addr:128.173.34.98 P-t-P:128.173.32.21 Mask:255.255.255.255
inet6 addr: 2001:468:c80:3b05:9559:2833:c9c6:4910/64 Scope:Global
inet6 addr: fe80::9559:2833:c9c6:4910/10 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1460 Metric:1
RX packets:19709 errors:0 dropped:0 overruns:0 frame:0
TX packets:14189 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:20541163 (19.5 MiB) TX bytes:1294777 (1.2 MiB)
wlan0 Link encap:Ethernet HWaddr 00:24:D6:53:C5:BA
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::224:d6ff:fe53:c5ba/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:209585 errors:0 dropped:3 overruns:0 frame:0
TX packets:205993 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:169153434 (161.3 MiB) TX bytes:105289986 (100.4 MiB)
% ip route show
default via 192.168.2.1 dev wlan0 metric 2
128.173.0.0/16 dev ppp0 scope link
128.173.32.21 via 192.168.2.1 dev wlan0 src 192.168.2.2
128.173.32.21 dev ppp0 proto kernel scope link src 128.173.34.98
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.2
198.82.0.0/16 dev ppp0 scope link
strace ntpdate -q 198.82.1.201 (an NTP server of ours, UDP over ppp0):
....
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("198.82.1.201")}, 16) = -1 EINVAL (Invalid argument)
.. and we're dead.
strace ping 198.82.1.201 (ICMP this time, over ppp0):
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("198.82.1.201")}, 16) = -1 EINVAL (Invalid argument)
and things fall over from there...
strace telnet telnet 198.82.161.192 25 (does TCP work? SMTP to a mail host of ours)
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("198.82.161.192")}, 16) = -1 EINVAL (Invalid argument)
Not looking good for the home team, but going to hosts not routed via the PPP interface
works just fine:
strace ping www.google.com (goes out via wlan0 directly)
....
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("72.14.204.99")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(60231), sin_addr=inet_addr("192.168.2.2")}, [16]) = 0
If I take down the ppp link, my routing table looks like:
% ip route show
default via 192.168.2.1 dev wlan0 metric 2
128.173.32.21 via 192.168.2.1 dev wlan0 src 192.168.2.2
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.2
and IPv4 to the problem addresses starts working:
strace ping 198.82.1.201 (via wlan0 directly):
...
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("198.82.1.201")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(60404), sin_addr=inet_addr("192.168.2.2")}, [16]) = 0
Any ideas? I'll probably not have a chance to bisect this for several days...
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* [PATCH v6] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Samreen @ 2011-02-24 6:26 UTC (permalink / raw)
To: linux-arm-kernel
Enabling all the display interface options to be built as module
And enabling all the display panels to be built as modules.
Signed-off-by: Samreen <samreen@ti.com>
---
Version6:
Enabling all the display interface options and all the display
panels.
Version5:
Incorporating the comments from Tony Lindgren, Kevin Hilman,
Paul Mundt & Tomi Valkeinen to build DSS & panels as modules.
See: https://patchwork.kernel.org/patch/281492/
Version4:
Remove the enabling of the display panels by default.
Version3:
Eliminate the separate default number of FBs for
different architecture. Keeping default FBs as 3 as before.
Version2:
Enables by default NEC panel used in zoom2/3/3630sdp, instead of
Sharp LQ043T1DG01 panel enabled in previous version of this patch.
Testing:
---------
The base used for OMAP3 testing is:
branch: master
commit: bb95b65a
URL: git://gitorious.org/linux-omap-dss2/linux.git
And OMAP4 testing is on the following branch + few patches to enable DSI taal panel:
branch: lo-dss2-Feb18
commit: 67bcb5600
URL: git://dev.omapzoom.org/pub/scm/axelcx/kernel-display.git
The patch is tested on 3630zoom, 3430sdp & 4430sdp, it was not tested
on OMAP2 platform due crash seen while boot.
(See: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg43921.html)
arch/arm/configs/omap2plus_defconfig | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index ae890ca..407ccf8 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -192,6 +192,17 @@ CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_OMAP_LCD_VGA=y
+CONFIG_OMAP2_DSS=m
+CONFIG_OMAP2_DSS_RFBI=y
+CONFIG_OMAP2_DSS_SDI=y
+CONFIG_OMAP2_DSS_DSI=y
+CONFIG_FB_OMAP2=m
+CONFIG_PANEL_GENERIC_DPI=m
+CONFIG_PANEL_SHARP_LS037V7DW01=m
+CONFIG_PANEL_NEC_NL8048HL11_01B=m
+CONFIG_PANEL_TAAL=m
+CONFIG_PANEL_TPO_TD043MTEA1=m
+CONFIG_PANEL_ACX565AKM=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
--
1.5.6.3
^ permalink raw reply related
* Re: [LTP] About LTP open_posix_testsuite/functional/threads/robust_test cases
From: Gui Jianfeng @ 2011-02-24 6:25 UTC (permalink / raw)
To: Garrett Cooper; +Cc: ltp-list@lists.sourceforge.net
In-Reply-To: <ABDE7E44-F301-4846-A7C3-D0F35CCC2E4F@gmail.com>
Garrett Cooper wrote:
> On Dec 22, 2010, at 6:31 PM, Gui Jianfeng <guijianfeng@cn.fujitsu.com
> <mailto:guijianfeng@cn.fujitsu.com>> wrote:
>
>> Hannu Heikkinen wrote:
>>> On 20/10/10 10:58 +0200, ext Gui Jianfeng wrote:
>>>> Hi Garrett
>>>>
>>>> In open_posix_testsuite/functional/threads/robust_test category,
>>>> all test cases don't follow the POSIX standard. They call many
>>>> functions that glibc doesn't even support. I wonder why not just
>>>> get rid of these test cases.
>>>>
>>>> --
>>>> Regards
>>>> Gui Jianfeng
>>>
>>> Hi,
>>>
>>> any progress/news about this?
>>
>> Garrett,
>>
>> Would you get rid of these cases?
>
> They should go in testcases/realtime . I can't commit changes for
> approximately another week and a half because I don't have Internet
> connectivity except on my phone (which doesn't do git :/..).
Garrett,
Would you also take a look these cases?
Thanks,
Gui
> Garrett
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply
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.