From: greg@kroah.com (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 09/10] MCDE: Add build files and bus
Date: Tue, 30 Nov 2010 15:05:33 -0800 [thread overview]
Message-ID: <20101130230533.GA11342@kroah.com> (raw)
In-Reply-To: <20101130220550.GD8521@n2100.arm.linux.org.uk>
On Tue, Nov 30, 2010 at 10:05:50PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
> > On Tue, Nov 30, 2010 at 06:40:49PM +0000, Russell King - ARM Linux wrote:
> > > There's lots of static devices, not only platform devices, in the ARM
> > > tree. It's going to be a hell of a lot of work to fix this all up
> > > properly.
> >
> > I agree, it's been abused for many years this way :(
>
> I don't agree that it is abuse - it was something explicitly allowed by
> the original device model design by Patrick, with the condition that
> such a device was never unregistered. That's exactly the way we treat
> these devices.
I understand Pat allowed this, I just don't agree that it's the correct
thing to do :)
-mm had a patch for a long time that would throw up warnings if you ever
did this for x86 so that arch should be clean of this issue by now.
> What I'm slightly concerned about is that this is going to needlessly
> bloat the kernel - we're going to have to find some other way to store
> this information, and create devices from that - which means additional
> code to do the creation, and data structures for it to create these from.
> There will be additional wastage from kmalloc as kmalloc doesn't allocate
> just the size you ask for, but normally a power of two which will contain
> the size.
>
> That could potentially mean that as the device structure is 216 bytes,
> kmalloc will use the 256 byte allocation size, which means a wastage of
> 40 bytes per device structure. On top of that goes the size of
> resources with the allocation slop on top for that, and then there's
> another allocation for the platform data.
>
> Has anyone considered these implications before making this choice?
Yes, I have, which is one reason I haven't done this type of change yet.
I need to figure out a way to not drasticly increase the size and still
make it easy and simple for the platform and driver write their code.
It's a work in progress, but wherever possible, I encourage people to
not make 'struct device' static.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>,
Linus Walleij <linus.walleij@linaro.org>,
Jimmy RUBIN <jimmy.rubin@stericsson.com>,
Dan JOHANSSON <dan.johansson@stericsson.com>,
Marcus LORENTZON <marcus.xm.lorentzon@stericsson.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH 09/10] MCDE: Add build files and bus
Date: Tue, 30 Nov 2010 15:05:33 -0800 [thread overview]
Message-ID: <20101130230533.GA11342@kroah.com> (raw)
In-Reply-To: <20101130220550.GD8521@n2100.arm.linux.org.uk>
On Tue, Nov 30, 2010 at 10:05:50PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
> > On Tue, Nov 30, 2010 at 06:40:49PM +0000, Russell King - ARM Linux wrote:
> > > There's lots of static devices, not only platform devices, in the ARM
> > > tree. It's going to be a hell of a lot of work to fix this all up
> > > properly.
> >
> > I agree, it's been abused for many years this way :(
>
> I don't agree that it is abuse - it was something explicitly allowed by
> the original device model design by Patrick, with the condition that
> such a device was never unregistered. That's exactly the way we treat
> these devices.
I understand Pat allowed this, I just don't agree that it's the correct
thing to do :)
-mm had a patch for a long time that would throw up warnings if you ever
did this for x86 so that arch should be clean of this issue by now.
> What I'm slightly concerned about is that this is going to needlessly
> bloat the kernel - we're going to have to find some other way to store
> this information, and create devices from that - which means additional
> code to do the creation, and data structures for it to create these from.
> There will be additional wastage from kmalloc as kmalloc doesn't allocate
> just the size you ask for, but normally a power of two which will contain
> the size.
>
> That could potentially mean that as the device structure is 216 bytes,
> kmalloc will use the 256 byte allocation size, which means a wastage of
> 40 bytes per device structure. On top of that goes the size of
> resources with the allocation slop on top for that, and then there's
> another allocation for the platform data.
>
> Has anyone considered these implications before making this choice?
Yes, I have, which is one reason I haven't done this type of change yet.
I need to figure out a way to not drasticly increase the size and still
make it easy and simple for the platform and driver write their code.
It's a work in progress, but wherever possible, I encourage people to
not make 'struct device' static.
thanks,
greg k-h
next prev parent reply other threads:[~2010-11-30 23:05 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <F45880696056844FA6A73F415B568C6953604E802E@EXDCVYMBSTM006.EQ1STM.local>
2010-11-25 12:25 ` [PATCH 09/10] MCDE: Add build files and bus Marcus LORENTZON
2010-11-25 16:47 ` Arnd Bergmann
2010-11-25 18:00 ` Marcus LORENTZON
2010-11-26 11:24 ` Arnd Bergmann
2010-11-26 11:24 ` Arnd Bergmann
2010-11-26 11:24 ` Arnd Bergmann
2010-11-30 14:18 ` Linus Walleij
2010-11-30 14:18 ` Linus Walleij
2010-11-30 15:21 ` Arnd Bergmann
2010-11-30 15:21 ` Arnd Bergmann
2010-11-30 16:24 ` Greg KH
2010-11-30 16:24 ` Greg KH
2010-11-30 18:40 ` Russell King - ARM Linux
2010-11-30 18:40 ` Russell King - ARM Linux
2010-11-30 18:48 ` Greg KH
2010-11-30 18:48 ` Greg KH
2010-11-30 22:05 ` Russell King - ARM Linux
2010-11-30 22:05 ` Russell King - ARM Linux
2010-11-30 23:05 ` Greg KH [this message]
2010-11-30 23:05 ` Greg KH
2010-11-30 23:42 ` Russell King - ARM Linux
2010-11-30 23:42 ` Russell King - ARM Linux
2010-11-30 23:49 ` Greg KH
2010-11-30 23:49 ` Greg KH
2010-11-30 23:49 ` Greg KH
2010-12-01 12:53 ` Peter Stuge
2010-12-01 12:53 ` Peter Stuge
2010-12-01 13:02 ` Russell King - ARM Linux
2010-12-01 13:02 ` Russell King - ARM Linux
2010-12-01 15:39 ` Arnd Bergmann
2010-12-01 15:39 ` Arnd Bergmann
2010-12-01 15:39 ` Arnd Bergmann
2010-12-04 6:52 ` Dave Airlie
2010-12-04 6:52 ` Dave Airlie
2010-12-04 6:52 ` Dave Airlie
2010-12-04 21:34 ` Alex Deucher
2010-12-04 21:34 ` Alex Deucher
2010-12-05 11:28 ` Daniel Vetter
2010-12-05 11:28 ` Daniel Vetter
2010-12-05 11:28 ` Daniel Vetter
2011-03-12 15:59 ` Rob Clark
2011-03-12 15:59 ` Rob Clark
2011-03-12 15:59 ` Rob Clark
2011-03-14 14:03 ` Marcus Lorentzon
2011-03-14 14:03 ` Marcus Lorentzon
2011-03-14 20:35 ` Rob Clark
2011-03-14 20:35 ` Rob Clark
2011-03-14 20:35 ` Rob Clark
2010-12-16 18:26 ` Marcus Lorentzon
2010-12-16 18:26 ` Marcus Lorentzon
2010-12-16 18:26 ` Marcus Lorentzon
2010-12-17 11:22 ` Arnd Bergmann
2010-12-17 11:22 ` Arnd Bergmann
2010-12-17 12:02 ` Marcus Lorentzon
2010-12-17 12:02 ` Marcus Lorentzon
2010-11-10 12:04 [PATCH 00/10] MCDE: Add frame buffer device driver Jimmy Rubin
2010-11-10 12:04 ` [PATCH 01/10] MCDE: Add hardware abstraction layer Jimmy Rubin
2010-11-10 12:04 ` [PATCH 02/10] MCDE: Add configuration registers Jimmy Rubin
2010-11-10 12:04 ` [PATCH 03/10] MCDE: Add pixel processing registers Jimmy Rubin
2010-11-10 12:04 ` [PATCH 04/10] MCDE: Add formatter registers Jimmy Rubin
2010-11-10 12:04 ` [PATCH 05/10] MCDE: Add dsi link registers Jimmy Rubin
2010-11-10 12:04 ` [PATCH 06/10] MCDE: Add generic display Jimmy Rubin
2010-11-10 12:04 ` [PATCH 07/10] MCDE: Add display subsystem framework Jimmy Rubin
2010-11-10 12:04 ` [PATCH 08/10] MCDE: Add frame buffer device Jimmy Rubin
2010-11-10 12:04 ` [PATCH 09/10] MCDE: Add build files and bus Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-12 16:23 ` Arnd Bergmann
2010-11-12 16:23 ` Arnd Bergmann
2010-11-12 16:23 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101130230533.GA11342@kroah.com \
--to=greg@kroah.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.