* Re: linux-next: usb/pxa trees build failure
From: Aric D. Blumer @ 2009-08-19 18:24 UTC (permalink / raw)
To: Greg KH
Cc: Eric Miao, Stephen Rothwell, linux-next, linux-kernel,
Mike Rapoport, Russell King
In-Reply-To: <20090819172223.GA4398@kroah.com>
Greg KH wrote:
> On Wed, Aug 19, 2009 at 10:35:10AM +0800, Eric Miao wrote:
>
>> Greg KH wrote:
>>
>>> On Tue, Aug 18, 2009 at 10:05:25PM +0800, Eric Miao wrote:
>>>
>>>> Greg KH wrote:
>>>>
>>>>> On Tue, Aug 18, 2009 at 01:58:52PM +1000, Stephen Rothwell wrote:
>>>>>
>>>>>> Hi Eric, Greg,
>>>>>>
>>>>>> The next-20090817 (and a few before) build (arm trizeps4_defconfig)
>>>>>> failed like this:
>>>>>>
>>>>>> drivers/usb/host/ohci-pxa27x.c:507: error: 'pdev' undeclared (first use in this function)
>>>>>>
>>>>>> Caused by the interaction of commit
>>>>>> 6458baec17e19d38b9d4eb1f96c213f91609c0e3 ("USB: ohci-pxa27x: Reconfigure
>>>>>> power settings on resume") from the usb tree with commit
>>>>>> b8fb7d4317bcea1b48c9560d23dff81121870ece ("[ARM] pxa: update
>>>>>> ohci-pxa27x.c to use 'struct dev_pm_ops'"). from the pxa tree.
>>>>>>
>>>>>> Greg/Aric, maybe that usb tree patch needs to go through the pxa tree?
>>>>>> (and maybe "USB: ohci-pxa27x: Allow NOCP and OCPM to be cleared" as well?)
>>>>>>
>>>>>> [this also broke the following configs: magician_defconfig,
>>>>>> em_x270_defconfig and cm_x2xx_defconfig.]
>>>>>>
>>>>> Ick, not good. Aric, should I drop this patch from my tree?
>>>>>
>>>>>
>>>> I think so, might be better to go through the pxa tree so that I can give
>>>> another review. (the fiber across the pacific seems to be broken again, so
>>>> I have to look into this tomorrow, still fetching -next, sigh).
>>>>
>>> Ok, let me know if you want me to drop these patches from my tree.
>>>
>>>
>> OK, so the problem is 'pdev' is no longer part of the dev_pm_ops, ('dev' is used
>> instead), and the 'inf' pointer can just be referenced from 'dev->platform_data',
>> so the fix is actually trivial, but it does have dependency issue.
>>
>> Greg,
>>
>> It looks to me would be better if this goes the pxa tree, and I'll send out the
>> updated patch of 6458baec later.
>>
>
> Ok, should I drop just this one patch from my tree, or any others as
> well
It is an isolated patch, so dropping it alone should be fine.
^ permalink raw reply
* Re: [PATCH v2] net: fix ks8851 build errors
From: David Miller @ 2009-08-19 19:13 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, netdev, akpm, linux-next, linux-kernel
In-Reply-To: <20090819085202.810630a2.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Wed, 19 Aug 2009 08:52:02 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix build errors due to missing Kconfig select of CRC32:
>
> ks8851.c:(.text+0x7d2ee): undefined reference to `crc32_le'
> ks8851.c:(.text+0x7d2f5): undefined reference to `bitrev32'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks Randy.
^ permalink raw reply
* Re: linux-next: suspend tree build warnings
From: Rafael J. Wysocki @ 2009-08-19 21:38 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, pm list, Alan Stern,
Mauro Carvalho Chehab, linux-media
In-Reply-To: <20090819172419.2cf53008.sfr@canb.auug.org.au>
On Wednesday 19 August 2009, Stephen Rothwell wrote:
> Hi Rafael,
Hi,
> Today's linux-next build (x86_64 allmodconfig) produced these warnings:
>
> drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_i2c_enumeration’:
> drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of 2256 bytes is larger than 2048 bytes
> drivers/media/dvb/frontends/dib3000mc.c: In function ‘dib3000mc_i2c_enumeration’:
> drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2160 bytes is larger than 2048 bytes
>
> Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 ("PM:
> Introduce core framework for run-time PM of I/O devices (rev. 17)").
Well.
This commit increases the size of struct device quite a bit and both of the
drivers above create a "state" object on the stack that contains struct device
among other things.
I think they should allocate these objects using kmalloc() and I don't know
what I can do about this, really. Maybe except for modifying the drivers to
use kmalloc().
Thanks,
Rafael
^ permalink raw reply
* Re: linux-next: suspend tree build warnings
From: Greg KH @ 2009-08-19 23:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Rothwell, linux-next, linux-kernel, pm list, Alan Stern,
Mauro Carvalho Chehab, linux-media
In-Reply-To: <200908192338.03910.rjw@sisk.pl>
On Wed, Aug 19, 2009 at 11:38:03PM +0200, Rafael J. Wysocki wrote:
> On Wednesday 19 August 2009, Stephen Rothwell wrote:
> > Hi Rafael,
>
> Hi,
>
> > Today's linux-next build (x86_64 allmodconfig) produced these warnings:
> >
> > drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_i2c_enumeration’:
> > drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of 2256 bytes is larger than 2048 bytes
> > drivers/media/dvb/frontends/dib3000mc.c: In function ‘dib3000mc_i2c_enumeration’:
> > drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2160 bytes is larger than 2048 bytes
> >
> > Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 ("PM:
> > Introduce core framework for run-time PM of I/O devices (rev. 17)").
>
> Well.
>
> This commit increases the size of struct device quite a bit and both of the
> drivers above create a "state" object on the stack that contains struct device
> among other things.
Ick. struct device should _never_ be on the stack, why would this code
want to do such a thing?
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: usb/pxa trees build failure
From: Greg KH @ 2009-08-19 23:37 UTC (permalink / raw)
To: Aric D. Blumer
Cc: Eric Miao, Stephen Rothwell, linux-next, linux-kernel,
Mike Rapoport, Russell King
In-Reply-To: <4A8C4348.7030601@sdgsystems.com>
On Wed, Aug 19, 2009 at 02:24:08PM -0400, Aric D. Blumer wrote:
> Greg KH wrote:
> > On Wed, Aug 19, 2009 at 10:35:10AM +0800, Eric Miao wrote:
> >
> >> Greg KH wrote:
> >>
> >>> On Tue, Aug 18, 2009 at 10:05:25PM +0800, Eric Miao wrote:
> >>>
> >>>> Greg KH wrote:
> >>>>
> >>>>> On Tue, Aug 18, 2009 at 01:58:52PM +1000, Stephen Rothwell wrote:
> >>>>>
> >>>>>> Hi Eric, Greg,
> >>>>>>
> >>>>>> The next-20090817 (and a few before) build (arm trizeps4_defconfig)
> >>>>>> failed like this:
> >>>>>>
> >>>>>> drivers/usb/host/ohci-pxa27x.c:507: error: 'pdev' undeclared (first use in this function)
> >>>>>>
> >>>>>> Caused by the interaction of commit
> >>>>>> 6458baec17e19d38b9d4eb1f96c213f91609c0e3 ("USB: ohci-pxa27x: Reconfigure
> >>>>>> power settings on resume") from the usb tree with commit
> >>>>>> b8fb7d4317bcea1b48c9560d23dff81121870ece ("[ARM] pxa: update
> >>>>>> ohci-pxa27x.c to use 'struct dev_pm_ops'"). from the pxa tree.
> >>>>>>
> >>>>>> Greg/Aric, maybe that usb tree patch needs to go through the pxa tree?
> >>>>>> (and maybe "USB: ohci-pxa27x: Allow NOCP and OCPM to be cleared" as well?)
> >>>>>>
> >>>>>> [this also broke the following configs: magician_defconfig,
> >>>>>> em_x270_defconfig and cm_x2xx_defconfig.]
> >>>>>>
> >>>>> Ick, not good. Aric, should I drop this patch from my tree?
> >>>>>
> >>>>>
> >>>> I think so, might be better to go through the pxa tree so that I can give
> >>>> another review. (the fiber across the pacific seems to be broken again, so
> >>>> I have to look into this tomorrow, still fetching -next, sigh).
> >>>>
> >>> Ok, let me know if you want me to drop these patches from my tree.
> >>>
> >>>
> >> OK, so the problem is 'pdev' is no longer part of the dev_pm_ops, ('dev' is used
> >> instead), and the 'inf' pointer can just be referenced from 'dev->platform_data',
> >> so the fix is actually trivial, but it does have dependency issue.
> >>
> >> Greg,
> >>
> >> It looks to me would be better if this goes the pxa tree, and I'll send out the
> >> updated patch of 6458baec later.
> >>
> >
> > Ok, should I drop just this one patch from my tree, or any others as
> > well
>
> It is an isolated patch, so dropping it alone should be fine.
Ok, it's now dropped from my tree, linux-next should now be happy :)
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the tip tree
From: Greg KH @ 2009-08-19 23:38 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Robin Getz, Jason Wessel,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20090819175901.59f1af9e.sfr@canb.auug.org.au>
On Wed, Aug 19, 2009 at 05:59:01PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb tree got a conflict in
> kernel/printk.c between commit 4d09161196c9a836eacea4b36e2f217bc34894cf
> ("printk: Enable the use of more than one CON_BOOT (early console)") from
> the tip tree and commit e289e7dc72eb6bfce70e2722d97a00f5e02893e8 ("USB:
> printk: early_printk,console: Allow more than one early console") from
> the usb tree.
>
> I assume that these are trying to do (more or less) the same thing. I
> have dropped the one from the usb tree for today. Please sort this out -
> at least remove the usb tree one until you have done so, thanks.
Jason, any thoughts? I'm going to drop your printk stuff from my tree
now, care to sort it out and resend your whole series?
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Greg KH @ 2009-08-19 23:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Jason Wessel
In-Reply-To: <20090819135239.GB30892@kroah.com>
On Wed, Aug 19, 2009 at 06:52:39AM -0700, Greg KH wrote:
> On Wed, Aug 19, 2009 at 06:34:02PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > arch/x86/built-in.o: In function `setup_early_printk':
> > early_printk.c:(.init.text+0x159de): undefined reference to `early_dbgp_init'
> > early_printk.c:(.init.text+0x159f9): undefined reference to `early_dbgp_console'
> >
> > Caused by commit 77f162cc16ff4bff1adefe47dbe48ab6b2d9247b ("USB: ehci
> > early_printk: split ehci debug driver from early_printk.c").
> >
> > I have reverted that commit for today (along with commits
> > 37e541af790703d66ba88cf3a71b5ae97654b753 ("USB: early_printk: insert cr
> > prior to nl as needed"), 71c0553ae63d2738a126d4f5b37730dfaa7a2fd7 ("USB:
> > ehci-dbgp: Execute early BIOS hand off"),
> > 3f038d06f259fd02142aaaaa47addfb4934d4faa ("USB: early_printk: EHCI debug
> > controller initialization delays") and
> > f6ee359e79de27b46213f8b5293251a26bc22b1e ("USB: ehci-dbgp: stability
> > improvements and external re-init") that depended on it).
>
> Ick. Jason, what happened here? It builds on i386 :)
Ok, I've dropped all of these now. Jason, care to respin them and
resend them?
Stephen, the usb tree should be now fixed up for linux-next, thanks for
the notices.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Stephen Rothwell @ 2009-08-19 23:58 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Jason Wessel
In-Reply-To: <20090819234518.GA12863@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 428 bytes --]
Hi Greg,
On Wed, 19 Aug 2009 16:45:18 -0700 Greg KH <greg@kroah.com> wrote:
>
> Ok, I've dropped all of these now. Jason, care to respin them and
> resend them?
>
> Stephen, the usb tree should be now fixed up for linux-next, thanks for
> the notices.
Thanks. I'll refetch it and start again for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: suspend tree build warnings
From: Andy Walls @ 2009-08-20 0:44 UTC (permalink / raw)
To: Greg KH
Cc: Rafael J. Wysocki, Stephen Rothwell, linux-next, linux-kernel,
pm list, Alan Stern, Mauro Carvalho Chehab, linux-media
In-Reply-To: <20090819233601.GA2875@kroah.com>
On Wed, 2009-08-19 at 16:36 -0700, Greg KH wrote:
> On Wed, Aug 19, 2009 at 11:38:03PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday 19 August 2009, Stephen Rothwell wrote:
> > > Hi Rafael,
> >
> > Hi,
> >
> > > Today's linux-next build (x86_64 allmodconfig) produced these warnings:
> > >
> > > drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_i2c_enumeration’:
> > > drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of 2256 bytes is larger than 2048 bytes
> > > drivers/media/dvb/frontends/dib3000mc.c: In function ‘dib3000mc_i2c_enumeration’:
> > > drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2160 bytes is larger than 2048 bytes
> > >
> > > Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 ("PM:
> > > Introduce core framework for run-time PM of I/O devices (rev. 17)").
> >
> > Well.
> >
> > This commit increases the size of struct device quite a bit and both of the
> > drivers above create a "state" object on the stack that contains struct device
> > among other things.
>
> Ick. struct device should _never_ be on the stack, why would this code
> want to do such a thing?
It appears that the state object is a dummy being used to detect and
twiddle some identical chips on the i2c bus. The functions called only
use the "i2c_adapter" and "cfg" member of the dummy state object, but
those functions want that state object as an input argument.
<obvious>
The simplest fix is dynamic allocation of the dummy state object with
kmalloc() and then to free it before exiting the function.
</obvious>
Regards,
Andy
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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: linux-next: manual merge of the usb tree with the tip tree
From: Jason Wessel @ 2009-08-20 2:37 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, linux-next, linux-kernel, Robin Getz,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20090819233818.GD2875@kroah.com>
Greg KH wrote:
> On Wed, Aug 19, 2009 at 05:59:01PM +1000, Stephen Rothwell wrote:
>
>> Hi Greg,
>>
>> Today's linux-next merge of the usb tree got a conflict in
>> kernel/printk.c between commit 4d09161196c9a836eacea4b36e2f217bc34894cf
>> ("printk: Enable the use of more than one CON_BOOT (early console)") from
>> the tip tree and commit e289e7dc72eb6bfce70e2722d97a00f5e02893e8 ("USB:
>> printk: early_printk,console: Allow more than one early console") from
>> the usb tree.
>>
>> I assume that these are trying to do (more or less) the same thing. I
>> have dropped the one from the usb tree for today. Please sort this out -
>> at least remove the usb tree one until you have done so, thanks.
>>
>
> Jason, any thoughts? I'm going to drop your printk stuff from my tree
> now, care to sort it out and resend your whole series?
>
>
I will investigate, re-test and send a new series to Greg KH later in
the week. The preliminary result shows the problem is a result of a
clash with two different patches in the tip tree. My patch set and the
two patches it collides with context wise fix different things.
In order to resolve this it appears that the series will need to get
split into something for the tip tree and something for the USB tree, or
we wait for the next pull of the tip branch into the Linus's tree.
Thanks,
Jason.
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the tip tree
From: Greg KH @ 2009-08-20 2:48 UTC (permalink / raw)
To: Jason Wessel
Cc: Stephen Rothwell, linux-next, linux-kernel, Robin Getz,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
In-Reply-To: <4A8CB6CF.3010109@windriver.com>
On Wed, Aug 19, 2009 at 09:37:03PM -0500, Jason Wessel wrote:
> Greg KH wrote:
> > On Wed, Aug 19, 2009 at 05:59:01PM +1000, Stephen Rothwell wrote:
> >
> >> Hi Greg,
> >>
> >> Today's linux-next merge of the usb tree got a conflict in
> >> kernel/printk.c between commit 4d09161196c9a836eacea4b36e2f217bc34894cf
> >> ("printk: Enable the use of more than one CON_BOOT (early console)") from
> >> the tip tree and commit e289e7dc72eb6bfce70e2722d97a00f5e02893e8 ("USB:
> >> printk: early_printk,console: Allow more than one early console") from
> >> the usb tree.
> >>
> >> I assume that these are trying to do (more or less) the same thing. I
> >> have dropped the one from the usb tree for today. Please sort this out -
> >> at least remove the usb tree one until you have done so, thanks.
> >>
> >
> > Jason, any thoughts? I'm going to drop your printk stuff from my tree
> > now, care to sort it out and resend your whole series?
> >
> >
>
> I will investigate, re-test and send a new series to Greg KH later in
> the week. The preliminary result shows the problem is a result of a
> clash with two different patches in the tip tree. My patch set and the
> two patches it collides with context wise fix different things.
>
> In order to resolve this it appears that the series will need to get
> split into something for the tip tree and something for the USB tree, or
> we wait for the next pull of the tip branch into the Linus's tree.
Hm, I'd prefer to get this in before that :)
Let me know what you find. If there are conflicts, we can work it out.
thanks,
greg k-h
^ permalink raw reply
* linux-next: manual merge of the drm tree with Linus' tree
From: Stephen Rothwell @ 2009-08-20 5:07 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-next, linux-kernel, Zhao Yakui
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/drm_edid.c between commit
ebb177d2afb8532a8a316489aed545ed0c170802 ("drm/edid: fixup detailed
timings like the X server.") from Linus' tree and commit
5c61259e6c7290082108e93815f7f72f27da14f4 ("drm/mode: get the modeline for
standard timing in EDID by using CVT/GTF") from the drm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/gpu/drm/drm_edid.c
index 7f2728b,bbcb2e2..0000000
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@@ -502,40 -547,12 +547,41 @@@ static int add_detailed_info(struct drm
struct detailed_non_pixel *data = &timing->data.other_data;
struct drm_display_mode *newmode;
- /* EDID up to and including 1.2 may put monitor info here */
- if (edid->version == 1 && edid->revision < 3)
- continue;
-
- /* Detailed mode timing */
- if (timing->pixel_clock) {
+ /* X server check is version 1.1 or higher */
+ if (edid->version == 1 && edid->revision >= 1 &&
+ !timing->pixel_clock) {
+ /* Other timing or info */
+ switch (data->type) {
+ case EDID_DETAIL_MONITOR_SERIAL:
+ break;
+ case EDID_DETAIL_MONITOR_STRING:
+ break;
+ case EDID_DETAIL_MONITOR_RANGE:
+ /* Get monitor range data */
+ break;
+ case EDID_DETAIL_MONITOR_NAME:
+ break;
+ case EDID_DETAIL_MONITOR_CPDATA:
+ break;
+ case EDID_DETAIL_STD_MODES:
+ /* Five modes per detailed section */
+ for (j = 0; j < 5; i++) {
+ struct std_timing *std;
+ struct drm_display_mode *newmode;
+
+ std = &data->data.timings[j];
- newmode = drm_mode_std(dev, std);
++ newmode = drm_mode_std(dev, std,
++ timing_level);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ break;
+ default:
+ break;
+ }
+ } else {
newmode = drm_mode_detailed(dev, edid, timing, quirks);
if (!newmode)
continue;
^ permalink raw reply
* linux-next: manual merge of the drm tree with the tree
From: Stephen Rothwell @ 2009-08-20 5:27 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-next, linux-kernel, Thomas Hellstrom, Roel Kluin
Hi Dave,
Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/ttm/ttm_bo.c between commits
ad49f501867cba87e1e45e5ebae0b12435d68bf1 ("drm/ttm/radeon: add dma32
support") and c96e7c7a3a79931446ecf9494a8415e4d164ebd8 ("drm/ttm: Read
buffer overflow") from Linus' tree and commit
a987fcaa805fcb24ba885c2e29fd4fdb6816f08f ("ttm: Make parts of a struct
ttm_bo_device global") from the drm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/gpu/drm/ttm/ttm_bo.c
index c2b0d71,0d0b1b7..0000000
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@@ -43,7 -43,41 +43,40 @@@
#define TTM_BO_HASH_ORDER 13
static int ttm_bo_setup_vm(struct ttm_buffer_object *bo);
-static void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo);
static int ttm_bo_swapout(struct ttm_mem_shrink *shrink);
+ static void ttm_bo_global_kobj_release(struct kobject *kobj);
+
+ static struct attribute ttm_bo_count = {
+ .name = "bo_count",
+ .mode = S_IRUGO
+ };
+
+ static ssize_t ttm_bo_global_show(struct kobject *kobj,
+ struct attribute *attr,
+ char *buffer)
+ {
+ struct ttm_bo_global *glob =
+ container_of(kobj, struct ttm_bo_global, kobj);
+
+ return snprintf(buffer, PAGE_SIZE, "%lu\n",
+ (unsigned long) atomic_read(&glob->bo_count));
+ }
+
+ static struct attribute *ttm_bo_global_attrs[] = {
+ &ttm_bo_count,
+ NULL
+ };
+
+ static struct sysfs_ops ttm_bo_global_ops = {
+ .show = &ttm_bo_global_show
+ };
+
+ static struct kobj_type ttm_bo_glob_kobj_type = {
+ .release = &ttm_bo_global_kobj_release,
+ .sysfs_ops = &ttm_bo_global_ops,
+ .default_attrs = ttm_bo_global_attrs
+ };
+
static inline uint32_t ttm_bo_type_flags(unsigned type)
{
@@@ -1182,7 -1193,8 +1225,8 @@@ static int ttm_bo_force_list_clean(stru
int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned mem_type)
{
+ struct ttm_bo_global *glob = bdev->glob;
- struct ttm_mem_type_manager *man = &bdev->man[mem_type];
+ struct ttm_mem_type_manager *man;
int ret = -EINVAL;
if (mem_type >= TTM_NUM_MEM_TYPES) {
@@@ -1329,17 -1414,10 +1447,11 @@@ int ttm_bo_device_release(struct ttm_bo
}
EXPORT_SYMBOL(ttm_bo_device_release);
- /*
- * This function is intended to be called on drm driver load.
- * If you decide to call it from firstopen, you must protect the call
- * from a potentially racing ttm_bo_driver_finish in lastclose.
- * (This may happen on X server restart).
- */
-
int ttm_bo_device_init(struct ttm_bo_device *bdev,
- struct ttm_mem_global *mem_glob,
- struct ttm_bo_driver *driver, uint64_t file_page_offset,
+ struct ttm_bo_global *glob,
+ struct ttm_bo_driver *driver,
- uint64_t file_page_offset)
++ uint64_t file_page_offset,
+ bool need_dma32)
{
int ret = -EINVAL;
@@@ -1374,30 -1444,17 +1478,18 @@@
INIT_DELAYED_WORK(&bdev->wq, ttm_bo_delayed_workqueue);
bdev->nice_mode = true;
INIT_LIST_HEAD(&bdev->ddestroy);
- INIT_LIST_HEAD(&bdev->swap_lru);
bdev->dev_mapping = NULL;
+ bdev->need_dma32 = need_dma32;
- ttm_mem_init_shrink(&bdev->shrink, ttm_bo_swapout);
- ret = ttm_mem_register_shrink(mem_glob, &bdev->shrink);
- if (unlikely(ret != 0)) {
- printk(KERN_ERR TTM_PFX
- "Could not register buffer object swapout.\n");
- goto out_err2;
- }
+ bdev->glob = glob;
- bdev->ttm_bo_extra_size =
- ttm_round_pot(sizeof(struct ttm_tt)) +
- ttm_round_pot(sizeof(struct ttm_backend));
-
- bdev->ttm_bo_size = bdev->ttm_bo_extra_size +
- ttm_round_pot(sizeof(struct ttm_buffer_object));
+ mutex_lock(&glob->device_list_mutex);
+ list_add_tail(&bdev->device_list, &glob->device_list);
+ mutex_unlock(&glob->device_list_mutex);
return 0;
- out_err2:
+ out_no_addr_mm:
ttm_bo_clean_mm(bdev, 0);
- out_err1:
- __free_page(bdev->dummy_read_page);
- out_err0:
+ out_no_sys:
return ret;
}
EXPORT_SYMBOL(ttm_bo_device_init);
^ permalink raw reply
* linux-next: manual merge of the drm tree with Linus' tree
From: Stephen Rothwell @ 2009-08-20 5:27 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-next, linux-kernel, Thomas Hellstrom
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/radeon/radeon_ttm.c between commit
ad49f501867cba87e1e45e5ebae0b12435d68bf1 ("drm/ttm/radeon: add dma32
support") from Linus' tree and commit
a987fcaa805fcb24ba885c2e29fd4fdb6816f08f ("ttm: Make parts of a struct
ttm_bo_device global") from the drm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/gpu/drm/radeon/radeon_ttm.c
index 15c3531,343b6d6..0000000
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@@ -446,9 -462,8 +467,9 @@@ int radeon_ttm_init(struct radeon_devic
}
/* No others user of address space so set it to 0 */
r = ttm_bo_device_init(&rdev->mman.bdev,
- rdev->mman.mem_global_ref.object,
+ rdev->mman.bo_global_ref.ref.object,
- &radeon_bo_driver, DRM_FILE_PAGE_OFFSET);
+ &radeon_bo_driver, DRM_FILE_PAGE_OFFSET,
+ rdev->need_dma32);
if (r) {
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
^ permalink raw reply
* Re: linux-next: manual merge of the drm tree with Linus' tree
From: Dave Airlie @ 2009-08-20 5:30 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Thomas Hellstrom
In-Reply-To: <20090820152743.a5f1088b.sfr@canb.auug.org.au>
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/radeon/radeon_ttm.c between commit
> ad49f501867cba87e1e45e5ebae0b12435d68bf1 ("drm/ttm/radeon: add dma32
> support") from Linus' tree and commit
> a987fcaa805fcb24ba885c2e29fd4fdb6816f08f ("ttm: Make parts of a struct
> ttm_bo_device global") from the drm tree.
I merged Linus tree soon after and pushed it out so it should be okay now.
Dave.
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the tip tree
From: Peter Zijlstra @ 2009-08-20 5:57 UTC (permalink / raw)
To: Greg KH
Cc: Jason Wessel, Stephen Rothwell, linux-next, linux-kernel,
Robin Getz, Thomas Gleixner, Ingo Molnar, H. Peter Anvin
In-Reply-To: <20090820024839.GA4121@kroah.com>
On Wed, 2009-08-19 at 19:48 -0700, Greg KH wrote:
> On Wed, Aug 19, 2009 at 09:37:03PM -0500, Jason Wessel wrote:
> > Greg KH wrote:
> > > On Wed, Aug 19, 2009 at 05:59:01PM +1000, Stephen Rothwell wrote:
> > >
> > >> Hi Greg,
> > >>
> > >> Today's linux-next merge of the usb tree got a conflict in
> > >> kernel/printk.c between commit 4d09161196c9a836eacea4b36e2f217bc34894cf
> > >> ("printk: Enable the use of more than one CON_BOOT (early console)") from
> > >> the tip tree and commit e289e7dc72eb6bfce70e2722d97a00f5e02893e8 ("USB:
> > >> printk: early_printk,console: Allow more than one early console") from
> > >> the usb tree.
> > >>
> > >> I assume that these are trying to do (more or less) the same thing. I
> > >> have dropped the one from the usb tree for today. Please sort this out -
> > >> at least remove the usb tree one until you have done so, thanks.
> > >>
> > >
> > > Jason, any thoughts? I'm going to drop your printk stuff from my tree
> > > now, care to sort it out and resend your whole series?
> > >
> > >
> >
> > I will investigate, re-test and send a new series to Greg KH later in
> > the week. The preliminary result shows the problem is a result of a
> > clash with two different patches in the tip tree. My patch set and the
> > two patches it collides with context wise fix different things.
> >
> > In order to resolve this it appears that the series will need to get
> > split into something for the tip tree and something for the USB tree, or
> > we wait for the next pull of the tip branch into the Linus's tree.
>
> Hm, I'd prefer to get this in before that :)
>
> Let me know what you find. If there are conflicts, we can work it out.
Maybe Robin can help out, since he authored one of the conflicting
patches?
^ permalink raw reply
* Re: linux-next: manual merge of the drm tree with Linus' tree
From: Stephen Rothwell @ 2009-08-20 6:43 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-next, linux-kernel, Thomas Hellstrom
In-Reply-To: <alpine.DEB.2.00.0908200629470.16909@skynet.skynet.ie>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
Hi Dave,
On Thu, 20 Aug 2009 06:30:15 +0100 (IST) Dave Airlie <airlied@linux.ie> wrote:
>
> I merged Linus tree soon after and pushed it out so it should be okay now.
Thanks. I look forward to tomorrow :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: suspend tree build warnings
From: Patrick Boettcher @ 2009-08-20 7:01 UTC (permalink / raw)
To: Andy Walls
Cc: Greg KH, Rafael J. Wysocki, Stephen Rothwell, linux-next,
linux-kernel, pm list, Alan Stern, Mauro Carvalho Chehab,
linux-media
In-Reply-To: <1250729056.2716.37.camel@morgan.walls.org>
Hi,
On Wed, 19 Aug 2009, Andy Walls wrote:
>> Ick. struct device should _never_ be on the stack, why would this code
>> want to do such a thing?
When you are doing a thing it does not necessarily you know that you're
doing it.
> It appears that the state object is a dummy being used to detect and
> twiddle some identical chips on the i2c bus. The functions called only
> use the "i2c_adapter" and "cfg" member of the dummy state object, but
> those functions want that state object as an input argument.
>
> <obvious>
> The simplest fix is dynamic allocation of the dummy state object with
> kmalloc() and then to free it before exiting the function.
> </obvious>
Even more obvious: Fix the function with simpler code to do the same
thing.
I will try to fetch some time from somewhere to work on it.
--
Patrick
http://www.kernellabs.com/
^ permalink raw reply
* Re: [PATCH V3 linux-next] treewide: remove unnecessary semicolons
From: Stephen Rothwell @ 2009-08-20 8:25 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Joe Perches, LKML, linux-next
In-Reply-To: <alpine.LNX.2.00.0908191105570.25797@wotan.suse.de>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
Hi Jiri, Joe,
On Wed, 19 Aug 2009 11:06:26 +0200 (CEST) Jiri Kosina <jkosina@suse.cz> wrote:
>
> On Tue, 18 Aug 2009, Joe Perches wrote:
>
> > > > > > Previous discussion at: http://lkml.org/lkml/2009/6/28/288
> > > > > > Signed-off-by: Joe Perches <joe@perches.com>
> > > > I could do that or you could "git apply --exclude=drivers/staging/"
> > > > Which do you prefer?
> > > It doesn't apply any more, could you please refresh, resend, and I will
> > > apply it right away?
> > I used git apply --reject --exclude=drivers/staging
>
> OK, applied, let's see how many conflicts we get.
Suprisingly: none :-) (well at least for today)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: Tree for August 20
From: Stephen Rothwell @ 2009-08-20 9:01 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8288 bytes --]
Hi all,
Changes since 20090819:
This tree fails to build for powerpc allyesconfig (due to a TOC overflow
problem in the final link).
The drm tree gained 3 conflicts against Linus' tree.
The fsnotify tree lost its conflicts.
The drbd tree lost its build failure.
The tip tree lost a conflict.
The usb tree lost its conflict and its build failure.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 140 trees (counting Linus' and 21 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging thumb-2/thumb-2
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_sync.h
Merging reiserfs-bkl/reiserfs/kill-bkl
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/board-dm646x-evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm355.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm644x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm646x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm355.h
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm644x.h
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging mmc/next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/input/misc/Kconfig
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_crtc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_edid.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_sdvo.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/radeon_ttm.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_bo.c
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-4430sdp.c
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Merging kmemleak/kmemleak
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/socket.h
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in kernel/fork.c
CONFLICT (content): Merge conflict in kernel/trace/trace.h
Merging oprofile/for-next
CONFLICT (content): Merge conflict in kernel/trace/ring_buffer.c
Merging edac-amd/for-next
CONFLICT (content): Merge conflict in arch/x86/kernel/smpboot.c
CONFLICT (content): Merge conflict in include/linux/topology.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
Merging sfi/sfi-test
CONFLICT (content): Merge conflict in arch/x86/include/asm/io_apic.h
CONFLICT (content): Merge conflict in arch/x86/kernel/acpi/boot.c
CONFLICT (content): Merge conflict in arch/x86/kernel/apic/io_apic.c
CONFLICT (content): Merge conflict in drivers/acpi/internal.h
CONFLICT (content): Merge conflict in drivers/acpi/tables.c
CONFLICT (content): Merge conflict in include/linux/acpi.h
Merging asm-generic/next
Merging hwpoison/hwpoison
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/base/class.c
CONFLICT (content): Merge conflict in init/main.c
Merging quilt/tty
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging quilt/usb
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/epl/VirtualEthernetLinux.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/epl/VirtualEthernetLinux.c left in tree.
$ git rm -f drivers/staging/epl/VirtualEthernetLinux.c
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the tip tree
From: Ingo Molnar @ 2009-08-20 10:35 UTC (permalink / raw)
To: Jason Wessel
Cc: Greg KH, Stephen Rothwell, linux-next, linux-kernel, Robin Getz,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra
In-Reply-To: <4A8CB6CF.3010109@windriver.com>
* Jason Wessel <jason.wessel@windriver.com> wrote:
> Greg KH wrote:
> > On Wed, Aug 19, 2009 at 05:59:01PM +1000, Stephen Rothwell wrote:
> >
> >> Hi Greg,
> >>
> >> Today's linux-next merge of the usb tree got a conflict in
> >> kernel/printk.c between commit 4d09161196c9a836eacea4b36e2f217bc34894cf
> >> ("printk: Enable the use of more than one CON_BOOT (early console)") from
> >> the tip tree and commit e289e7dc72eb6bfce70e2722d97a00f5e02893e8 ("USB:
> >> printk: early_printk,console: Allow more than one early console") from
> >> the usb tree.
> >>
> >> I assume that these are trying to do (more or less) the same thing. I
> >> have dropped the one from the usb tree for today. Please sort this out -
> >> at least remove the usb tree one until you have done so, thanks.
> >>
> >
> > Jason, any thoughts? I'm going to drop your printk stuff from my tree
> > now, care to sort it out and resend your whole series?
> >
> >
>
> I will investigate, re-test and send a new series to
> Greg KH later in the week. The preliminary result
> shows the problem is a result of a clash with two
> different patches in the tip tree. My patch set and
> the two patches it collides with context wise fix
> different things.
>
> In order to resolve this it appears that the series
> will need to get split into something for the tip tree
> and something for the USB tree, or we wait for the next
> pull of the tip branch into the Linus's tree.
The printk bits are neatly separated out in the -tip
tree, in a standalone tree, tip:core/printk:
earth4:~/tip> gll linus..core/printk
42c2c8c: printk: Fix "printk: Enable the use of more than one CON_BOOT (early console)"
1aaad49: printk: Restore previous console_loglevel when re-enabling logging
8259cf4: printk: Ensure that "console enabled" messages are printed on the console
4d09161: printk: Enable the use of more than one CON_BOOT (early console)
So we can base on that and extend it with your bits, and
Greg could pull this into the USB tree as well he he
wants to (this tree is focused to this single topic and
is non-rebasing).
The git coordinates are:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core/printk
Please Cc: new printk/console bits to Linus and Andrew as
well.
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the omap tree with the arm tree
From: Tony Lindgren @ 2009-08-20 10:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-omap, linux-next, linux-kernel, Syed Rafiuddin,
Russell King, Kalle Valo
In-Reply-To: <20090819150433.4c12c612.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> [090819 08:04]:
> Hi all,
>
> Today's linux-next merge of the omap tree got a conflict in
> arch/arm/mach-omap2/board-4430sdp.c between commit
> 085b54d99b8ee999e7905b8f16e201e0da8ba369 ("ARM: OMAP4: Add UART4
> support") from the arm tree and commit
> 4c29fa3e47342666e12e46f35f40dd90b12cd1a4 ("OMAP: remove OMAP_TAG_UART")
> from the omap tree.
>
> Just context changes (I think). I fixed it up (see below) and can carry
> the fix as necessary.
Thanks yeh the fix looks right. I'll take a look if I can squeeze something
like that into my queue so the merge conflict disappears.
Regards,
Tony
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc arch/arm/mach-omap2/board-4430sdp.c
> index 1b22307,646079f..0000000
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@@ -38,8 -38,8 +38,8 @@@ static struct platform_device *sdp4430_
> &sdp4430_lcd_device,
> };
>
> - static struct omap_uart_config sdp4430_uart_config __initdata = {
> + static struct omap_uart_platform_data sdp4430_uart_config __initdata = {
> - .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2),
> + .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3),
> };
>
> static struct omap_lcd_config sdp4430_lcd_config __initdata = {
^ permalink raw reply
* RE: linux-next: manual merge of the omap tree with the arm tree
From: Shilimkar, Santosh @ 2009-08-20 13:03 UTC (permalink / raw)
To: Tony Lindgren, Stephen Rothwell
Cc: linux-omap@vger.kernel.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Syed, Rafiuddin, Russell King,
Kalle Valo
In-Reply-To: <20090820102004.GD12309@atomide.com>
> > Today's linux-next merge of the omap tree got a conflict in
> > arch/arm/mach-omap2/board-4430sdp.c between commit
> > 085b54d99b8ee999e7905b8f16e201e0da8ba369 ("ARM: OMAP4: Add UART4
> > support") from the arm tree and commit
> > 4c29fa3e47342666e12e46f35f40dd90b12cd1a4 ("OMAP: remove OMAP_TAG_UART")
> > from the omap tree.
> >
> > Just context changes (I think). I fixed it up (see below) and can carry
> > the fix as necessary.
>
> Thanks yeh the fix looks right. I'll take a look if I can squeeze
> something
> like that into my queue so the merge conflict disappears.
There is another issue with the same merge I noticed which not seems to be correct.
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=a11128de5baf523cf73176170659902fe1335527
< Code snippet >
102 static struct plat_serial8250_port serial_platform_data2[] = {
103 {
104 .membase = OMAP2_IO_ADDRESS(OMAP_UART3_BASE),
105 .mapbase = OMAP_UART3_BASE,
106 .irq = 74,
107 .flags = UPF_BOOT_AUTOCONF,
108 .iotype = UPIO_MEM,
109 .regshift = 2,
110 .uartclk = OMAP24XX_BASE_BAUD * 16,
111 }, {
112 #ifdef CONFIG_ARCH_OMAP4
113 .membase = IO_ADDRESS(OMAP_UART4_BASE),
114 .mapbase = OMAP_UART4_BASE,
115 .irq = 70,
116 .flags = UPF_BOOT_AUTOCONF,
117 .iotype = UPIO_MEM,
118 .regshift = 2,
119 .uartclk = OMAP24XX_BASE_BAUD * 16,
120 }, {
121 #endif
122 .flags = 0
123 }
124 };
This patch (ARM: OMAP4: Add UART4) was generated when there was single structure holding all three UARTs and fourth UART was added accordingly. And now it's been merged with serial.c which has UART's structures separated already.
Below patch fixes the same but don't know what is the way to get merged in such cases.
Tony,
Could you please review it?
>From c8be9f1b5d4fe1dce06b6f33be33fe57f376ea7f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 20 Aug 2009 18:33:43 +0530
Subject: [PATCH] OMAP4: UART4 : Reworked patch to fix merge conflicts.
This patch adds UART4 support on OMAP4430 development platform.
The serial omap-patches has split the UART platform
data into separate structure hence needs rework.
Without this patch omap_serial_init() would produce kernel crash
on OMAP4430 platform while looping for the 4 th UART platform
data.
Signed-off-by: Syed Rafiuddin <rafiuddin.syed@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 2 +-
arch/arm/mach-omap2/serial.c | 27 ++++++++++++++++++++++++++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index b0c7402..1b22307 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -39,7 +39,7 @@ static struct platform_device *sdp4430_devices[] __initdata = {
};
static struct omap_uart_config sdp4430_uart_config __initdata = {
- .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2),
+ .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3),
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a7421a5..b96cac4 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -112,7 +112,21 @@ static struct plat_serial8250_port serial_platform_data2[] = {
.flags = 0
}
};
-
+#ifdef CONFIG_ARCH_OMAP4
+static struct plat_serial8250_port serial_platform_data3[] = {
+ {
+ .membase = IO_ADDRESS(OMAP_UART4_BASE),
+ .mapbase = OMAP_UART3_BASE,
+ .irq = 70,
+ .flags = UPF_BOOT_AUTOCONF,
+ .iotype = UPIO_MEM,
+ .regshift = 2,
+ .uartclk = OMAP24XX_BASE_BAUD * 16,
+ }, {
+ .flags = 0
+ }
+};
+#endif
static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
int offset)
{
@@ -550,6 +564,17 @@ static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS] = {
},
},
},
+#ifdef CONFIG_ARCH_OMAP4
+ {
+ .pdev = {
+ .name = "serial8250",
+ .id = PLAT8250_DEV_PLATFORM2,
+ .dev = {
+ .platform_data = serial_platform_data2,
+ },
+ },
+ },
+#endif
};
void __init omap_serial_init(void)
--
1.5.4.7
Regrads
Santosh
^ permalink raw reply related
* RE: linux-next: manual merge of the omap tree with the arm tree
From: Shilimkar, Santosh @ 2009-08-20 13:13 UTC (permalink / raw)
To: Shilimkar, Santosh, Tony Lindgren, Stephen Rothwell
Cc: linux-omap@vger.kernel.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Syed, Rafiuddin, Russell King,
Kalle Valo
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02BA29B949@dbde02.ent.ti.com>
(Resending with a correction)
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Thursday, August 20, 2009 6:33 PM
> To: Tony Lindgren; Stephen Rothwell
> Cc: linux-omap@vger.kernel.org; linux-next@vger.kernel.org; linux-
> kernel@vger.kernel.org; Syed, Rafiuddin; Russell King; Kalle Valo
> Subject: RE: linux-next: manual merge of the omap tree with the arm tree
>
> > > Today's linux-next merge of the omap tree got a conflict in
> > > arch/arm/mach-omap2/board-4430sdp.c between commit
> > > 085b54d99b8ee999e7905b8f16e201e0da8ba369 ("ARM: OMAP4: Add UART4
> > > support") from the arm tree and commit
> > > 4c29fa3e47342666e12e46f35f40dd90b12cd1a4 ("OMAP: remove
> OMAP_TAG_UART")
> > > from the omap tree.
> > >
> > > Just context changes (I think). I fixed it up (see below) and can
> carry
> > > the fix as necessary.
> >
> > Thanks yeh the fix looks right. I'll take a look if I can squeeze
> > something
> > like that into my queue so the merge conflict disappears.
>
> There is another issue with the same merge I noticed which not seems to be
> correct.
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-
> next.git;a=commit;h=a11128de5baf523cf73176170659902fe1335527
>
> < Code snippet >
>
> 102 static struct plat_serial8250_port serial_platform_data2[] = {
> 103 {
> 104 .membase = OMAP2_IO_ADDRESS(OMAP_UART3_BASE),
> 105 .mapbase = OMAP_UART3_BASE,
> 106 .irq = 74,
> 107 .flags = UPF_BOOT_AUTOCONF,
> 108 .iotype = UPIO_MEM,
> 109 .regshift = 2,
> 110 .uartclk = OMAP24XX_BASE_BAUD * 16,
> 111 }, {
> 112 #ifdef CONFIG_ARCH_OMAP4
> 113 .membase = IO_ADDRESS(OMAP_UART4_BASE),
> 114 .mapbase = OMAP_UART4_BASE,
> 115 .irq = 70,
> 116 .flags = UPF_BOOT_AUTOCONF,
> 117 .iotype = UPIO_MEM,
> 118 .regshift = 2,
> 119 .uartclk = OMAP24XX_BASE_BAUD * 16,
> 120 }, {
> 121 #endif
> 122 .flags = 0
> 123 }
> 124 };
>
> This patch (ARM: OMAP4: Add UART4) was generated when there was single
> structure holding all three UARTs and fourth UART was added accordingly.
> And now it's been merged with serial.c which has UART's structures
> separated already.
> Below patch fixes the same but don't know what is the way to get merged in
> such cases.
>
> Tony,
> Could you please review it?
>From c8be9f1b5d4fe1dce06b6f33be33fe57f376ea7f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 20 Aug 2009 18:33:43 +0530
Subject: [PATCH] OMAP4: UART4 : Reworked patch to fix merge conflicts.
This patch adds UART4 support on OMAP4430 development platform.
The serial omap patches has split the UART platform
data into separate structure hence needs rework.
Without this patch omap_serial_init() would produce kernel crash
on OMAP4430 platform while looping for the 4 th UART platform
data.
Signed-off-by: Syed Rafiuddin <rafiuddin.syed@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 2 +-
arch/arm/mach-omap2/serial.c | 27 ++++++++++++++++++++++++++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index b0c7402..1b22307 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -39,7 +39,7 @@ static struct platform_device *sdp4430_devices[] __initdata = {
};
static struct omap_uart_config sdp4430_uart_config __initdata = {
- .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2),
+ .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3),
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a7421a5..b96cac4 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -112,7 +112,21 @@ static struct plat_serial8250_port serial_platform_data2[] = {
.flags = 0
}
};
-
+#ifdef CONFIG_ARCH_OMAP4
+static struct plat_serial8250_port serial_platform_data3[] = {
+ {
+ .membase = IO_ADDRESS(OMAP_UART4_BASE),
+ .mapbase = OMAP_UART4_BASE,
+ .irq = 70,
+ .flags = UPF_BOOT_AUTOCONF,
+ .iotype = UPIO_MEM,
+ .regshift = 2,
+ .uartclk = OMAP24XX_BASE_BAUD * 16,
+ }, {
+ .flags = 0
+ }
+};
+#endif
static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
int offset)
{
@@ -550,6 +564,17 @@ static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS] = {
},
},
},
+#ifdef CONFIG_ARCH_OMAP4
+ {
+ .pdev = {
+ .name = "serial8250",
+ .id = PLAT8250_DEV_PLATFORM2,
+ .dev = {
+ .platform_data = serial_platform_data3,
+ },
+ },
+ },
+#endif
};
void __init omap_serial_init(void)
--
1.5.4.7
Regards,
Santosh
^ permalink raw reply related
* Re: linux-next: manual merge of the omap tree with the arm tree
From: Tony Lindgren @ 2009-08-20 13:55 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: Stephen Rothwell, linux-omap@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Syed, Rafiuddin, Russell King, Kalle Valo
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02BA29B961@dbde02.ent.ti.com>
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [090820 16:13]:
> (Resending with a correction)
>
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> > Sent: Thursday, August 20, 2009 6:33 PM
> > To: Tony Lindgren; Stephen Rothwell
> > Cc: linux-omap@vger.kernel.org; linux-next@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Syed, Rafiuddin; Russell King; Kalle Valo
> > Subject: RE: linux-next: manual merge of the omap tree with the arm tree
> >
> > > > Today's linux-next merge of the omap tree got a conflict in
> > > > arch/arm/mach-omap2/board-4430sdp.c between commit
> > > > 085b54d99b8ee999e7905b8f16e201e0da8ba369 ("ARM: OMAP4: Add UART4
> > > > support") from the arm tree and commit
> > > > 4c29fa3e47342666e12e46f35f40dd90b12cd1a4 ("OMAP: remove
> > OMAP_TAG_UART")
> > > > from the omap tree.
> > > >
> > > > Just context changes (I think). I fixed it up (see below) and can
> > carry
> > > > the fix as necessary.
> > >
> > > Thanks yeh the fix looks right. I'll take a look if I can squeeze
> > > something
> > > like that into my queue so the merge conflict disappears.
> >
> > There is another issue with the same merge I noticed which not seems to be
> > correct.
> > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-
> > next.git;a=commit;h=a11128de5baf523cf73176170659902fe1335527
> >
> > < Code snippet >
> >
> > 102 static struct plat_serial8250_port serial_platform_data2[] = {
> > 103 {
> > 104 .membase = OMAP2_IO_ADDRESS(OMAP_UART3_BASE),
> > 105 .mapbase = OMAP_UART3_BASE,
> > 106 .irq = 74,
> > 107 .flags = UPF_BOOT_AUTOCONF,
> > 108 .iotype = UPIO_MEM,
> > 109 .regshift = 2,
> > 110 .uartclk = OMAP24XX_BASE_BAUD * 16,
> > 111 }, {
> > 112 #ifdef CONFIG_ARCH_OMAP4
> > 113 .membase = IO_ADDRESS(OMAP_UART4_BASE),
> > 114 .mapbase = OMAP_UART4_BASE,
> > 115 .irq = 70,
> > 116 .flags = UPF_BOOT_AUTOCONF,
> > 117 .iotype = UPIO_MEM,
> > 118 .regshift = 2,
> > 119 .uartclk = OMAP24XX_BASE_BAUD * 16,
> > 120 }, {
> > 121 #endif
> > 122 .flags = 0
> > 123 }
> > 124 };
> >
> > This patch (ARM: OMAP4: Add UART4) was generated when there was single
> > structure holding all three UARTs and fourth UART was added accordingly.
> > And now it's been merged with serial.c which has UART's structures
> > separated already.
> > Below patch fixes the same but don't know what is the way to get merged in
> > such cases.
> >
> > Tony,
> > Could you please review it?
Looks OK, except the OMAP_IO_ADDRESS() has been split to OMAP1_IO_ADDRESS()
and OMAP2_IO_ADDRESS in omap for-next tree.
Regards,
Tony
>
> From c8be9f1b5d4fe1dce06b6f33be33fe57f376ea7f Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Thu, 20 Aug 2009 18:33:43 +0530
> Subject: [PATCH] OMAP4: UART4 : Reworked patch to fix merge conflicts.
>
> This patch adds UART4 support on OMAP4430 development platform.
> The serial omap patches has split the UART platform
> data into separate structure hence needs rework.
>
> Without this patch omap_serial_init() would produce kernel crash
> on OMAP4430 platform while looping for the 4 th UART platform
> data.
>
> Signed-off-by: Syed Rafiuddin <rafiuddin.syed@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/board-4430sdp.c | 2 +-
> arch/arm/mach-omap2/serial.c | 27 ++++++++++++++++++++++++++-
> 2 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index b0c7402..1b22307 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -39,7 +39,7 @@ static struct platform_device *sdp4430_devices[] __initdata = {
> };
>
> static struct omap_uart_config sdp4430_uart_config __initdata = {
> - .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2),
> + .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3),
> };
>
> static struct omap_lcd_config sdp4430_lcd_config __initdata = {
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index a7421a5..b96cac4 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -112,7 +112,21 @@ static struct plat_serial8250_port serial_platform_data2[] = {
> .flags = 0
> }
> };
> -
> +#ifdef CONFIG_ARCH_OMAP4
> +static struct plat_serial8250_port serial_platform_data3[] = {
> + {
> + .membase = IO_ADDRESS(OMAP_UART4_BASE),
> + .mapbase = OMAP_UART4_BASE,
> + .irq = 70,
> + .flags = UPF_BOOT_AUTOCONF,
> + .iotype = UPIO_MEM,
> + .regshift = 2,
> + .uartclk = OMAP24XX_BASE_BAUD * 16,
> + }, {
> + .flags = 0
> + }
> +};
> +#endif
> static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
> int offset)
> {
> @@ -550,6 +564,17 @@ static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS] = {
> },
> },
> },
> +#ifdef CONFIG_ARCH_OMAP4
> + {
> + .pdev = {
> + .name = "serial8250",
> + .id = PLAT8250_DEV_PLATFORM2,
> + .dev = {
> + .platform_data = serial_platform_data3,
> + },
> + },
> + },
> +#endif
> };
>
> void __init omap_serial_init(void)
> --
> 1.5.4.7
>
> Regards,
> Santosh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox