* Re: [PATCH 1/2] powerpc, 5200: add support for charon board
From: Wolfram Sang @ 2010-12-06 6:44 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <4CFC82C3.3090307@denx.de>
[-- Attachment #1: Type: text/plain, Size: 369 bytes --]
On Mon, Dec 06, 2010 at 07:29:23AM +0100, Heiko Schocher wrote:
> Thanks for the review,
You're welcome. Oh, just to make sure: It is really a MPC5200 and not a
MPC5200B?
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, 5200: add support for charon board
From: Heiko Schocher @ 2010-12-06 6:55 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20101206064444.GA31994@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Mon, Dec 06, 2010 at 07:29:23AM +0100, Heiko Schocher wrote:
>
>> Thanks for the review,
>
> You're welcome. Oh, just to make sure: It is really a MPC5200 and not a
> MPC5200B?
Yep, it is a MPC5200
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 7:30 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20101204211734.GD671@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Sat, Dec 04, 2010 at 09:21:54AM +0100, Heiko Schocher wrote:
>
> There shall be only one mpc5200-defconfig. Does the genric one work with your
> board?
Just tried, mpc5200_defconfig works for me, but...
... I miss there the LM81 and RTC DS1374 support ... and in another
patchset from me, I add SM501 support for this board ... also
for example, I don;t need CONFIG_FB_RADEON*, CONFIG_SPI* defines
Hmm.. I understand that maintaining the board_defconfigs is a nightmare.
Just a fast thought (I am not a kconfig expert):
As there is a mpc5200_defconfig, couldn;t we get rid of the board
defconfig(s), and add instead a possibility to store only the changes
against the mpc5200_defconfig in a file? That would save a lot of unneeded
lines, and maintaining would be easier as common 5200 config options
are stored in mpc5200_defconfig ... and a "make board_settings" would do:
- call "make mpc5200_defconfig"
- process differences stored in "board_settings"
(something like menuconfig, just not interactive)
(we could generalize that approach, because I think, all defconfigs
are not easy to maintain, if we say first line is always the defconfig
we call, following lines are options different to that ...)
Example for the charon board "charon_settings" file:
call mpc5200_defconfig // call "make mpc5200_defconfig"
enable SENSORS_LM80 // call something like "make menuconfig -e SENSORS_LM80"
disable FB_RADEON // call something like "make menuconfig -d FB_RADEON"
disable SPI
disable RTC_DRV_DS1307
enable RTC_DRV_DS1374
...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Anatolij Gustschin @ 2010-12-06 8:49 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <4CFC911D.4070306@denx.de>
Hello Heiko,
On Mon, 06 Dec 2010 08:30:37 +0100
Heiko Schocher <hs@denx.de> wrote:
> Hello Wolfram,
>
> Wolfram Sang wrote:
> > On Sat, Dec 04, 2010 at 09:21:54AM +0100, Heiko Schocher wrote:
> >
> > There shall be only one mpc5200-defconfig. Does the genric one work with your
> > board?
>
> Just tried, mpc5200_defconfig works for me, but...
>
> ... I miss there the LM81 and RTC DS1374 support ... and in another
> patchset from me, I add SM501 support for this board ... also
> for example, I don;t need CONFIG_FB_RADEON*, CONFIG_SPI* defines
>
> Hmm.. I understand that maintaining the board_defconfigs is a nightmare.
> Just a fast thought (I am not a kconfig expert):
>
> As there is a mpc5200_defconfig, couldn;t we get rid of the board
> defconfig(s), and add instead a possibility to store only the changes
> against the mpc5200_defconfig in a file? That would save a lot of unneeded
> lines, and maintaining would be easier as common 5200 config options
> are stored in mpc5200_defconfig ... and a "make board_settings" would do:
You can save a reduced config file in ./defconfig by running
"make savedefconfig". This ./defconfig file can also be used as a
board config file in arch/powerpc/configs/52xx/. Look e.g. at the
config files under arch/powerpc/configs/52xx/.
Anatolij
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 9:13 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20101206094925.3dd90271@wker>
Hello Anatolij,
Anatolij Gustschin wrote:
> On Mon, 06 Dec 2010 08:30:37 +0100
> Heiko Schocher <hs@denx.de> wrote:
>
>> Hello Wolfram,
>>
>> Wolfram Sang wrote:
>>> On Sat, Dec 04, 2010 at 09:21:54AM +0100, Heiko Schocher wrote:
>>>
>>> There shall be only one mpc5200-defconfig. Does the genric one work with your
>>> board?
>> Just tried, mpc5200_defconfig works for me, but...
>>
>> ... I miss there the LM81 and RTC DS1374 support ... and in another
>> patchset from me, I add SM501 support for this board ... also
>> for example, I don;t need CONFIG_FB_RADEON*, CONFIG_SPI* defines
>>
>> Hmm.. I understand that maintaining the board_defconfigs is a nightmare.
>> Just a fast thought (I am not a kconfig expert):
>>
>> As there is a mpc5200_defconfig, couldn;t we get rid of the board
>> defconfig(s), and add instead a possibility to store only the changes
>> against the mpc5200_defconfig in a file? That would save a lot of unneeded
>> lines, and maintaining would be easier as common 5200 config options
>> are stored in mpc5200_defconfig ... and a "make board_settings" would do:
>
> You can save a reduced config file in ./defconfig by running
> "make savedefconfig". This ./defconfig file can also be used as a
> board config file in arch/powerpc/configs/52xx/. Look e.g. at the
> config files under arch/powerpc/configs/52xx/.
Ah, Ok, great.
If such a file is accepted in mainline, I make a v2 post.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Wolfram Sang @ 2010-12-06 9:31 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <4CFCA91C.9030107@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
> If such a file is accepted in mainline, I make a v2 post.
===
commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Mon Jan 21 11:22:22 2008 -0700
[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
There is no reason to have separate defconfigs for each mpc5200 board.
Instead, here is a common defconfig that can be used for all supported
platforms.
Merging the defconfigs means there are fewer configuration to test when
compile testing all of arch/powerpc and should make support easier.
Supported boards:
Lite5200(b), Efika, TQM5200, CM5200, MotionPro
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
===
A defconfig which brings the board up is good enough. Specific projects tend to
have specialized configs anyhow.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 9:49 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20101206093148.GA7320@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
>> If such a file is accepted in mainline, I make a v2 post.
>
> ===
>
> commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
> Author: Grant Likely <grant.likely@secretlab.ca>
> Date: Mon Jan 21 11:22:22 2008 -0700
>
> [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
>
> There is no reason to have separate defconfigs for each mpc5200 board.
> Instead, here is a common defconfig that can be used for all supported
> platforms.
>
> Merging the defconfigs means there are fewer configuration to test when
> compile testing all of arch/powerpc and should make support easier.
>
> Supported boards:
> Lite5200(b), Efika, TQM5200, CM5200, MotionPro
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> ===
>
> A defconfig which brings the board up is good enough. Specific projects tend to
> have specialized configs anyhow.
Hmm.. applies this also to the DTS?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-06 9:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291613340.11896.216.camel@concordia>
Thank you for the detailed answer. I'm trying to digest it...
> > What's a good source, besides grepping the kernel to no end ?
>
> Nothing really I'm afraid.
8-|
> So you have a device, it appears in your device tree, and you want to
> write a driver for it.
That's the idea. Communication between usermode and the driver is limited to
simple ioctl calls and the driver receives an interrupt when certain data has
been placed in memory blocks by the hardware (like a DMA). Then the user prog
figures out where that latest data buffer is (mmap) and saves it.
> The first issue is that someone needs to create a device for your node,
> it doesn't necessarily happen by default. For many platforms this will
> all happen "automagically" as long as the device node that describes
> your device appears in the right place, but I'll describe it in full
> anyway.
I'm on a minimalist embedded system (buildroot+busybox+uclibc), so I'm pretty
sure I have to do the whole thing. No udev/HAL here.
> In most cases your device will appear below a node that represents a
> bus, eg:
>
> foobus@xyz {
> compatible = "vendor,foobus-v1.m.n", "simple-bus";
> ...
> yournode@abc {
> ...
> }
> }
>
> If that isn't the case you need to arrange for it somehow [1].
Commenting on your [1] here. So should I just add "simple-bus" or does the
VHDL needs to be modified so as to generate this additional bus info ?
I indeed have:
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,virtex405", "xlnx,virtex";
model = "testing";
...
plb: plb@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.05.a", "xlnx,plb-v46-1.00.a", "simple-
bus";
ranges ;
...
xps_acqui_data_0: xps-acqui-data@c9800000 {
compatible = "xlnx,xps-acqui-data-3.00.a";
...
}
...
}
...
}
> Somewhere there needs to be code to probe that bus and create devices on
> it. That is usually done in platform code with of_platform_bus_probe().
Isn't the of_* code outdated (just been told that on a previous message) ?
Or was it just for of_register_platform_driver ?
> If you don't know what platform you're on, you can look at a boot log
> for a line saying "Using <blah> machine description", it will be very
> early in the log. "blah" is then the name of the platform you're on, and
> you should be able to grep for it in arch/powerpc/platforms.
"Using Xilinx Virtex machine description"
> Once you've found the .c file for your platform, there should be a call
> somewhere to of_platform_bus_probe(), with a list of ids, and one of
> those ids should match the compatible property of your bus node. In a
> lot of cases that is just "simple-bus".
That'd be:
arch/powerpc/platforms/40x/virtex.c:51: .name = "Xilinx Virtex",
and
arch/powerpc/platforms/40x/virtex.c:21: { .compatible = "simple-bus", },
No match for simple-bus of acqui-data in dmesg.
> To check a device is being created for your device node, you can look
> in /sys/devices. The device names don't match 100% with what's in the
> device tree, but the name should be there, so in your case:
>
> # find /sys/devices -name '*xps-acqui-data*'
Indeed:
# ll /sys/devices/plb.0/c9800000.xps-acqui-data
-r--r--r-- 1 root root 4.0K Dec 6 09:47 devspec
-r--r--r-- 1 root root 4.0K Dec 6 09:47 modalias
-r--r--r-- 1 root root 4.0K Dec 6 09:47 name
lrwxrwxrwx 1 root root 0 Dec 6 09:47 subsystem ->
../../../bus/of_platform/
-rw-r--r-- 1 root root 4.0K Dec 6 09:47 uevent
So that's created on boot, right ?
> [...code snipped...]
I still need a platform_device_register() after your sample init, right ?
I'll get on to adapting your sample code now. Thanks a lot.
--
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Wolfram Sang @ 2010-12-06 10:01 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <4CFCB195.8000306@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
> Wolfram Sang wrote:
> > On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
> >> If such a file is accepted in mainline, I make a v2 post.
> >
> > ===
> >
> > commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
> > Author: Grant Likely <grant.likely@secretlab.ca>
> > Date: Mon Jan 21 11:22:22 2008 -0700
> >
> > [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
> >
> > There is no reason to have separate defconfigs for each mpc5200 board.
> > Instead, here is a common defconfig that can be used for all supported
> > platforms.
> >
> > Merging the defconfigs means there are fewer configuration to test when
> > compile testing all of arch/powerpc and should make support easier.
> >
> > Supported boards:
> > Lite5200(b), Efika, TQM5200, CM5200, MotionPro
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > ===
> >
> > A defconfig which brings the board up is good enough. Specific projects tend to
> > have specialized configs anyhow.
>
> Hmm.. applies this also to the DTS?
How should that work? :) There is one kernel with all needed options
(the optional ones being modules) and the DTS selects what is needed.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 10:25 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20101206100116.GB7320@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
>> Wolfram Sang wrote:
>>> On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
>>>> If such a file is accepted in mainline, I make a v2 post.
>>> ===
>>>
>>> commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
>>> Author: Grant Likely <grant.likely@secretlab.ca>
>>> Date: Mon Jan 21 11:22:22 2008 -0700
>>>
>>> [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
>>>
>>> There is no reason to have separate defconfigs for each mpc5200 board.
>>> Instead, here is a common defconfig that can be used for all supported
>>> platforms.
>>>
>>> Merging the defconfigs means there are fewer configuration to test when
>>> compile testing all of arch/powerpc and should make support easier.
>>>
>>> Supported boards:
>>> Lite5200(b), Efika, TQM5200, CM5200, MotionPro
>>>
>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>>
>>> ===
>>>
>>> A defconfig which brings the board up is good enough. Specific projects tend to
>>> have specialized configs anyhow.
>> Hmm.. applies this also to the DTS?
>
> How should that work? :) There is one kernel with all needed options
> (the optional ones being modules) and the DTS selects what is needed.
Ok, so I post a v2 without defconfig patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-06 11:56 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <201012061435.07393.jk@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
On Mon, 2010-12-06 at 14:35 +0800, Jeremy Kerr wrote:
> Hi Michael,
>
> > So you have a device, it appears in your device tree, and you want to
> > write a driver for it.
>
> Nice write up, mind if I steal this for the devicetree.org wiki?
Sure thing, feel free to correct any mistakes too ;D
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-06 12:07 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012061058.37612.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 5284 bytes --]
On Mon, 2010-12-06 at 10:58 +0100, Guillaume Dargaud wrote:
> Thank you for the detailed answer. I'm trying to digest it...
>
> > > What's a good source, besides grepping the kernel to no end ?
> >
> > Nothing really I'm afraid.
> 8-|
>
> > So you have a device, it appears in your device tree, and you want to
> > write a driver for it.
> That's the idea. Communication between usermode and the driver is limited to
> simple ioctl calls and the driver receives an interrupt when certain data has
> been placed in memory blocks by the hardware (like a DMA). Then the user prog
> figures out where that latest data buffer is (mmap) and saves it.
OK, that should be all pretty straight forward, and covered by the
material in LDD and similar references. You just need to get your device
probed.
> > The first issue is that someone needs to create a device for your node,
> > it doesn't necessarily happen by default. For many platforms this will
> > all happen "automagically" as long as the device node that describes
> > your device appears in the right place, but I'll describe it in full
> > anyway.
>
> I'm on a minimalist embedded system (buildroot+busybox+uclibc), so I'm pretty
> sure I have to do the whole thing. No udev/HAL here.
That's another problem. The device I'm talking about here is just the
minimal struct in the kernel that you need in order for your driver to
probe against it. Once your driver has matched against a device then you
(might) need to worry about exposing a device to userspace in /dev.
> > In most cases your device will appear below a node that represents a
> > bus, eg:
> >
> > foobus@xyz {
> > compatible = "vendor,foobus-v1.m.n", "simple-bus";
> > ...
> > yournode@abc {
> > ...
> > }
> > }
> >
> > If that isn't the case you need to arrange for it somehow [1].
>
> Commenting on your [1] here. So should I just add "simple-bus" or does the
> VHDL needs to be modified so as to generate this additional bus info ?
Doesn't look like it:
> I indeed have:
>
> /dts-v1/;
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,virtex405", "xlnx,virtex";
> model = "testing";
> ...
> plb: plb@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,plb-v46-1.05.a", "xlnx,plb-v46-1.00.a", "simple-bus";
> ranges ;
> ...
> xps_acqui_data_0: xps-acqui-data@c9800000 {
> compatible = "xlnx,xps-acqui-data-3.00.a";
> ...
> }
> ...
> }
> ...
> }
That looks good.
> > Somewhere there needs to be code to probe that bus and create devices on
> > it. That is usually done in platform code with of_platform_bus_probe().
>
> Isn't the of_* code outdated (just been told that on a previous message) ?
> Or was it just for of_register_platform_driver ?
No it's just that platform_drivers are now able to do all the things an
of_platform_driver can do, so new code should just use platform_driver.
I'm not sure if of_platform_bus_probe() will go away eventually, but for
now it is the only way to achieve what you need.
> > If you don't know what platform you're on, you can look at a boot log
> > for a line saying "Using <blah> machine description", it will be very
> > early in the log. "blah" is then the name of the platform you're on, and
> > you should be able to grep for it in arch/powerpc/platforms.
>
> "Using Xilinx Virtex machine description"
Cool.
> > Once you've found the .c file for your platform, there should be a call
> > somewhere to of_platform_bus_probe(), with a list of ids, and one of
> > those ids should match the compatible property of your bus node. In a
> > lot of cases that is just "simple-bus".
>
> That'd be:
> arch/powerpc/platforms/40x/virtex.c:51: .name = "Xilinx Virtex",
> and
> arch/powerpc/platforms/40x/virtex.c:21: { .compatible = "simple-bus", },
Perfect.
> No match for simple-bus of acqui-data in dmesg.
That's normal, if the kernel printed out every device it found you'd
drown in messages. If you want to you can put a printk in
of_platform_device_create() and you should see it.
> > To check a device is being created for your device node, you can look
> > in /sys/devices. The device names don't match 100% with what's in the
> > device tree, but the name should be there, so in your case:
> >
> > # find /sys/devices -name '*xps-acqui-data*'
>
> Indeed:
> # ll /sys/devices/plb.0/c9800000.xps-acqui-data
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 devspec
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 modalias
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 name
> lrwxrwxrwx 1 root root 0 Dec 6 09:47 subsystem -> ../../../bus/of_platform/
> -rw-r--r-- 1 root root 4.0K Dec 6 09:47 uevent
>
> So that's created on boot, right ?
Yep, so that is all working fine. You just need to write a driver that
will match against that device.
> > [...code snipped...]
>
> I still need a platform_device_register() after your sample init, right ?
I had one in there already, in foo_driver_init(), didn't I?
> I'll get on to adapting your sample code now. Thanks a lot.
No worries.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: Getting the IRQ number (Was: Basic driver devel questions ?)
From: David Laight @ 2010-12-06 12:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <201012061058.37612.dargaud@lpsc.in2p3.fr>
=20
> That's the idea. Communication between usermode and the driver is
limited to=20
> simple ioctl calls and the driver receives an interrupt when certain
data has=20
> been placed in memory blocks by the hardware (like a DMA).=20
> Then the user prog figures out where that latest data buffer is (mmap)
and saves it.=20
I've used pread() and pwrite() to directly copy data to/from a devices
PCI memory space.
The driver just verifies the offset and calls copy_to/from_user() [1].
High offsets can be used to access driver specific data.
The userspace code for pread/write is less painful than using ioctl()
for everything.
This also lets you dump the device memory space with hexdump.
I also made the device interrupt generate POLLIN (this needs a bit of
care since the interrupt can arrive before poll() is called).
David
[1] I actually had to use the PCIe dma controller to get adequate
throughput.
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-06 14:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291637228.21242.14.camel@concordia>
Hello all,
> OK, that should be all pretty straight forward, and covered by the
> material in LDD and similar references. You just need to get your device
> probed.
I'm not sure what you mean with that term: simply identifying that the device
works using device specific code ?
I've looked at several *_probe functions from other drivers and they are all
completely different with no common code...
Or do you mean calling of_platform_bus_probe() ? What does that function do ?
> No it's just that platform_drivers are now able to do all the things an
> of_platform_driver can do, so new code should just use platform_driver.
>
> I'm not sure if of_platform_bus_probe() will go away eventually, but for
> now it is the only way to achieve what you need.
I assume the kernel needs to be compiled with CONFIG_OF.
...hmm I had to "git pull" in order for this to compile your snippet. That's
really recent! Unfortunately i need to reflash my device with the new kernel
before i can begin testing my module.
When I try to compile your (adapted) snippet, I got this minor problems:
.probe = foo_driver_probe,
^ warning: initialization from incompatible pointer type
Shouldn't foo_driver_probe be:
static int foo_driver_probe(struct platform_device *pdev)
instead of:
static int foo_driver_probe(struct platform_device *device,
const struct of_device_id *device_id)
Also:
struct foo_device *foo;
That's where I put my own content, right ?
And needs to be kfreed in a foo_driver_remove() function, right ?
> > I still need a platform_device_register() after your sample init, right ?
>
> I had one in there already, in foo_driver_init(), didn't I?
You had platform_driver_register(), not that I'm all clear yet on the
distinction...
Another question: I just spent 10 minutes trying to find where "struct device"
was defined. (ack-)grep was absolutely no use. Isn't there a way to cross-
reference my own kernel, the way I've compiled it ?
--
Guillaume Dargaud
http://www.gdargaud.net/Climbing/
^ permalink raw reply
* RE: Getting the IRQ number (Was: Basic driver devel questions ?)
From: David Laight @ 2010-12-06 14:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <201012061544.40124.dargaud@lpsc.in2p3.fr>
=20
> Another question: I just spent 10 minutes trying to find
> where "struct device" was defined.
Dirty trick #4:
At the top of a source file (before the first include) add:
struct device { int fubar; };
Then try to compile it.
The compiler will the tell where it is defined!
David
^ permalink raw reply
* [PATCH 0/4] V2 Add ability to link device blob(s) into vmlinux
From: dirk.brandewie @ 2010-12-06 17:35 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch set adds the ability to link device tree blobs into
vmlinux.
Patch 1 implements the changes to include/asm-generic/vmlinux.lds.h and
adds a generic rule for generating DTB objects to be linked vmlinux.
Patch 2 implements linking a DTB into an x86 image.
Patch 3-4 move {powerpc,microblaze}/boot/Makefile to use the dtc rule
in patch 1.
This patch set has been tested on x86.
Powerpc and Microblaze have been compile tested with and without patch
3 and 4 applied.
Changes from V1:
Documentation added for dtc command in Makefile.lib to
Documentation/kbuild/makefiles.txt
Separate DTB_ALIGNMENT define removed.
FORCE removed from dtc rule.
Removed hardcoded path to dts files from dtc command.
Moved %.dtb: %.dts rule to arch specific makefiles.
Patch for adding kernel command line option to pass in dtb_compat
string dropped from this set will be submitted seperately.
Dirk Brandewie (4):
of: Add support for linking device tree blobs into vmlinux
x86/of: Add building device tree blob(s) into image.
of/powerpc: Use generic rule to build dtb's
microblaze/of: Use generic rule to build dtb's
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
arch/microblaze/boot/Makefile | 10 ++--------
arch/powerpc/boot/Makefile | 8 +++-----
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
include/asm-generic/vmlinux.lds.h | 15 ++++++++++++---
scripts/Makefile.lib | 21 ++++++++++++++++++++-
6 files changed, 62 insertions(+), 17 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: dirk.brandewie @ 2010-12-06 17:35 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291656753.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds support for linking device tree blob(s) into
vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
.dtb sections into vmlinux. To maintain compatiblity with the of/fdt
driver code platforms MUST copy the blob to a non-init memory location
before the kernel frees the .init.* sections in the image.
Modifies scripts/Makefile.lib to add a kbuild command to
compile DTS files to device tree blobs and a rule to create objects to
wrap the blobs for linking.
STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
create wrapper objects for the dtb in Makefile.lib. The
STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
STRUCT_ALIGNMENT definition.
The DTB's are placed on 32 byte boundries to allow parsing the blob
with driver/of/fdt.c during early boot without having to copy the blob
to get the structure alignment GCC expects.
A DTB is linked in by adding the DTB object to the list of objects to
be linked into vmlinux in the archtecture specific Makefile using
obj-y += foo.dtb.o
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
include/asm-generic/vmlinux.lds.h | 15 ++++++++++++---
scripts/Makefile.lib | 21 ++++++++++++++++++++-
3 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 0ef00bd..fc18bb1 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
resulting in the target file being recompiled for no
obvious reason.
+ dtc
+ Create flattend device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
+
+ Example:
+ #arch/x86/platform/ce4100/Makefile
+ clean-files := *dtb.S
+
+ DTC_FLAGS := -p 1024
+ obj-y += foo.dtb.o
+
+ $(obj)/%.dtb: $(src)/%.dts
+ $(call if_changed,dtc)
--- 6.7 Custom kbuild commands
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bd69d79..024d3b9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -23,7 +23,7 @@
* _etext = .;
*
* _sdata = .;
- * RO_DATA_SECTION(PAGE_SIZE)
+* RO_DATA_SECTION(PAGE_SIZE)
* RW_DATA_SECTION(...)
* _edata = .;
*
@@ -67,7 +67,8 @@
* Align to a 32 byte boundary equal to the
* alignment gcc 4.5 uses for a struct
*/
-#define STRUCT_ALIGN() . = ALIGN(32)
+#define STRUCT_ALIGNMENT 32
+#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
/* The actual configuration determine if the init/exit sections
* are handled as text/data or they can be discarded (which
@@ -146,6 +147,13 @@
#define TRACE_SYSCALLS()
#endif
+
+#define KERNEL_DTB() \
+ STRUCT_ALIGN(); \
+ VMLINUX_SYMBOL(__dtb_start) = .; \
+ *(.dtb.init.rodata) \
+ VMLINUX_SYMBOL(__dtb_end) = .;
+
/* .data section */
#define DATA_DATA \
*(.data) \
@@ -468,7 +476,8 @@
MCOUNT_REC() \
DEV_DISCARD(init.rodata) \
CPU_DISCARD(init.rodata) \
- MEM_DISCARD(init.rodata)
+ MEM_DISCARD(init.rodata) \
+ KERNEL_DTB()
#define INIT_TEXT \
*(.init.text) \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4c72c11..937eabbb 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -200,7 +200,26 @@ quiet_cmd_gzip = GZIP $@
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
(rm -f $@ ; false)
-
+# DTC
+# ---------------------------------------------------------------------------
+
+# Generate an assembly file to wrap the output of the device tree compiler
+$(obj)/%.dtb.S: $(obj)/%.dtb
+ @echo '#include <asm-generic/vmlinux.lds.h>' > $@
+ @echo '.section .dtb.init.rodata,"a"' >> $@
+ @echo '.balign STRUCT_ALIGNMENT' >> $@
+ @echo '.global __dtb_$(*F)_begin' >> $@
+ @echo '__dtb_$(*F)_begin:' >> $@
+ @echo '.incbin "$<" ' >> $@
+ @echo '__dtb_$(*F)_end:' >> $@
+ @echo '.global __dtb_$(*F)_end' >> $@
+ @echo '.balign STRUCT_ALIGNMENT' >> $@
+
+DTC = $(objtree)/scripts/dtc/dtc
+
+quiet_cmd_dtc = DTC $@
+ cmd_dtc = $(DTC) -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
+ooo
# Bzip2
# ---------------------------------------------------------------------------
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: dirk.brandewie @ 2010-12-06 17:36 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291656753.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds linking device tree blob into vmlinux. DTB's are
added by adding the blob object name to list of objects to be linked
into the image.
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
index 91fc929..3b49187 100644
--- a/arch/x86/platform/ce4100/Makefile
+++ b/arch/x86/platform/ce4100/Makefile
@@ -1 +1,11 @@
obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
+clean-files := *dtb.S
+
+ifdef CONFIG_X86_OF
+###
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
+
+$(obj)/%.dtb: $(src)/%.dts
+ $(call if_changed,dtc)
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-06 17:36 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291656753.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/powerpc/boot/Makefile | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..3afb33a 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -35,7 +35,7 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-DTS_FLAGS ?= -p 1024
+DTC_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
@@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
-
-$(obj)/%.dtb: $(dtstree)/%.dts
- $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts
+$(obj)/%.dtb: $(src)/dts/%.dts
+ $(call if_changed,dtc)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/4] microblaze/of: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-06 17:36 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291656753.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/microblaze/boot/Makefile | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index be01d78..52430e5 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -10,9 +10,6 @@ targets := linux.bin linux.bin.gz simpleImage.%
OBJCOPYFLAGS := -O binary
-# Where the DTS files live
-dtstree := $(srctree)/$(src)/dts
-
# Ensure system.dtb exists
$(obj)/linked_dtb.o: $(obj)/system.dtb
@@ -51,14 +48,11 @@ $(obj)/simpleImage.%: vmlinux FORCE
$(call if_changed,strip)
@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
-# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
# Rule to build device tree blobs
-quiet_cmd_dtc = DTC $@
- cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
+DTC_FLAGS := -p 1024
-$(obj)/%.dtb: $(dtstree)/%.dts FORCE
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
$(call if_changed,dtc)
clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] Make auto-loading of therm_pm72 possible
From: kevin diggs @ 2010-12-06 18:25 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Linux PPC Development
In-Reply-To: <1291561537-1943-1-git-send-email-maz@misterjones.org>
Hi,
On a sort of related issue, if anyone out there has a PowerMac7,3
(dual 2.5 GHz 970Fx, PCI-X), I would appreciate it if you could do me
a favor.
I think this therm_pm72 thing creates the sysfs temperature and
voltage attributes for the cpus. I noticed on my machine that if I use
the cpufreq driver for this thing the frequencies were like 2.0 and
2.5. The problem is that the cpu voltages were something like 1.25 and
1.37 respectively. At 1.37 and 2.5 GHz, cpu 1 would zoom to 110+ under
load.
When I finally managed to get a compiler built that could build a
kernel past 2.6.28, I removed the cpufreq driver. Now this thing runs
at 2.5 GHz all the time. Under load cpu1 tops out at like 74 ish. I
eventually noticed that the voltage was 1.25. Huh? I thought this
voltage scaling business used the high voltage for the high frequency.
How can this thing be running at its high speed at the lower
voltage???
Can someone please confirm this behavior on a different 7,3? I did get
this thing off of ebay and might have myself a franken G5?
Thanks!
kevin
P.S.: I also don't get the 2.0 GHz low speed? I thought with the FX
the speed would be 2.5 / 2 or 1.25? Does this beast NOT use the FX's
frequency scaling capabilities?
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Sam Ravnborg @ 2010-12-06 19:02 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
linux-kernel, sodaville, linuxppc-dev
In-Reply-To: <76a37fa459aeadce5d11db8a7cc044687a2e0e8c.1291656753.git.dirk.brandewie@gmail.com>
On Mon, Dec 06, 2010 at 09:35:59AM -0800, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> This patch adds support for linking device tree blob(s) into
> vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
> .dtb sections into vmlinux. To maintain compatiblity with the of/fdt
> driver code platforms MUST copy the blob to a non-init memory location
> before the kernel frees the .init.* sections in the image.
>
> Modifies scripts/Makefile.lib to add a kbuild command to
> compile DTS files to device tree blobs and a rule to create objects to
> wrap the blobs for linking.
>
> STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
> create wrapper objects for the dtb in Makefile.lib. The
> STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
> STRUCT_ALIGNMENT definition.
>
> The DTB's are placed on 32 byte boundries to allow parsing the blob
> with driver/of/fdt.c during early boot without having to copy the blob
> to get the structure alignment GCC expects.
>
> A DTB is linked in by adding the DTB object to the list of objects to
> be linked into vmlinux in the archtecture specific Makefile using
> obj-y += foo.dtb.o
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
> ---
> Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
> include/asm-generic/vmlinux.lds.h | 15 ++++++++++++---
> scripts/Makefile.lib | 21 ++++++++++++++++++++-
> 3 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
> index 0ef00bd..fc18bb1 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
> resulting in the target file being recompiled for no
> obvious reason.
>
> + dtc
> + Create flattend device tree blob object suitable for linking
> + into vmlinux. Device tree blobs linked into vmlinux are placed
> + in an init section in the image. Platform code *must* copy the
> + blob to non-init memory prior to calling unflatten_device_tree().
> +
> + Example:
> + #arch/x86/platform/ce4100/Makefile
> + clean-files := *dtb.S
> +
> + DTC_FLAGS := -p 1024
> + obj-y += foo.dtb.o
> +
> + $(obj)/%.dtb: $(src)/%.dts
> + $(call if_changed,dtc)
When using "if_changed" you need to add your target to targets-y.
And you need to specify FORCE as a prerequisite to force kbuild
to use the if_changed logic.
The purpose of if_changed is to check if the commandlien has changed
and execute the command again also if the commandline has changed.
The simpler variant is $(call cmd,dtc) where you do not check
the command line and do not need FORCE.
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index bd69d79..024d3b9 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -23,7 +23,7 @@
> * _etext = .;
> *
> * _sdata = .;
> - * RO_DATA_SECTION(PAGE_SIZE)
> +* RO_DATA_SECTION(PAGE_SIZE)
> * RW_DATA_SECTION(...)
> * _edata = .;
> *
Change seems wrong.
> @@ -67,7 +67,8 @@
> * Align to a 32 byte boundary equal to the
> * alignment gcc 4.5 uses for a struct
> */
> -#define STRUCT_ALIGN() . = ALIGN(32)
> +#define STRUCT_ALIGNMENT 32
> +#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
>
> /* The actual configuration determine if the init/exit sections
> * are handled as text/data or they can be discarded (which
> @@ -146,6 +147,13 @@
> #define TRACE_SYSCALLS()
> #endif
>
> +
> +#define KERNEL_DTB() \
> + STRUCT_ALIGN(); \
> + VMLINUX_SYMBOL(__dtb_start) = .; \
> + *(.dtb.init.rodata) \
> + VMLINUX_SYMBOL(__dtb_end) = .;
> +
> /* .data section */
> #define DATA_DATA \
> *(.data) \
> @@ -468,7 +476,8 @@
> MCOUNT_REC() \
> DEV_DISCARD(init.rodata) \
> CPU_DISCARD(init.rodata) \
> - MEM_DISCARD(init.rodata)
> + MEM_DISCARD(init.rodata) \
> + KERNEL_DTB()
>
> #define INIT_TEXT \
> *(.init.text) \
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 4c72c11..937eabbb 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -200,7 +200,26 @@ quiet_cmd_gzip = GZIP $@
> cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
> (rm -f $@ ; false)
>
> -
> +# DTC
> +# ---------------------------------------------------------------------------
> +
> +# Generate an assembly file to wrap the output of the device tree compiler
> +$(obj)/%.dtb.S: $(obj)/%.dtb
> + @echo '#include <asm-generic/vmlinux.lds.h>' > $@
> + @echo '.section .dtb.init.rodata,"a"' >> $@
> + @echo '.balign STRUCT_ALIGNMENT' >> $@
> + @echo '.global __dtb_$(*F)_begin' >> $@
> + @echo '__dtb_$(*F)_begin:' >> $@
> + @echo '.incbin "$<" ' >> $@
> + @echo '__dtb_$(*F)_end:' >> $@
> + @echo '.global __dtb_$(*F)_end' >> $@
> + @echo '.balign STRUCT_ALIGNMENT' >> $@
> +
If we really want this rule in Makefile.lib then at least make it less verbose,
and more secure.
Something like this:
quiet_dt_S_dtb_cmd = DTB $@
dt_S_dtb_cmd = \
( \
@echo '#include <asm-generic/vmlinux.lds.h>'; \
@echo '.section .dtb.init.rodata,"a"'; \
@echo '.balign STRUCT_ALIGNMENT'; \
echo '.global __dtb_$(*F)_begin'; \
echo '__dtb_$(*F)_begin:'; \
echo '.incbin "$<" '; \
echo '__dtb_$(*F)_end:'; \
echo '.global __dtb_$(*F)_end'; \
echo '.balign STRUCT_ALIGNMENT'; \
) > $@
$(obj)/%.dtb.S: $(obj)/%.dtb
$(call cmd,dt_S_dtb)
> +DTC = $(objtree)/scripts/dtc/dtc
If this is the only spot where we use DTC then drop the variable.
> +
> +quiet_cmd_dtc = DTC $@
> + cmd_dtc = $(DTC) -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
> +ooo
What is the purpose of these "ooo"? A debugging left-over?
Sam
^ permalink raw reply
* [PATCH] powerpc/watchdog: Propagate Book E WDT period changes to all cores
From: Randy Vinson @ 2010-12-06 21:02 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linux-watchdog, Kumar Gala
When the watchdog period is changed, it needs to be propagated to all cores
in addition to the core that performed the change.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
drivers/watchdog/booke_wdt.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index d11ffb0..c8ffa6c 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -85,6 +85,22 @@ static unsigned int sec_to_period(unsigned int secs)
return 0;
}
+static void __booke_wdt_set(void *data)
+{
+ u32 val;
+
+ val = mfspr(SPRN_TCR);
+ val &= ~WDTP_MASK;
+ val |= WDTP(booke_wdt_period);
+
+ mtspr(SPRN_TCR, val);
+}
+
+static void booke_wdt_set(void)
+{
+ on_each_cpu(__booke_wdt_set, NULL, 0);
+}
+
static void __booke_wdt_ping(void *data)
{
mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
@@ -181,8 +197,7 @@ static long booke_wdt_ioctl(struct file *file,
#else
booke_wdt_period = tmp;
#endif
- mtspr(SPRN_TCR, (mfspr(SPRN_TCR) & ~WDTP_MASK) |
- WDTP(booke_wdt_period));
+ booke_wdt_set();
return 0;
case WDIOC_GETTIMEOUT:
return put_user(booke_wdt_period, p);
--
1.6.3.3.328.ge81f
^ permalink raw reply related
* [RFC/PATCH 0/7] powerpc: Implement lazy save of FP, VMX and VSX state in SMP
From: Michael Neuling @ 2010-12-06 23:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala; +Cc: linuxppc-dev, linux-kernel
This implements lazy save of FP, VMX and VSX state on SMP 64bit and 32
bit powerpc.
Currently we only do lazy save in UP, but this patch set extends this to
SMP. We always do lazy restore.
For VMX, on a context switch we do the following:
- if we are switching to a CPU that currently holds the new processes
state, just turn on VMX in the MSR (this is the lazy/quick case)
- if the new processes state is in the thread_struct, turn VMX off.
- if the new processes state is in someone else's CPU, IPI that CPU to
giveup it's state and turn VMX off in the MSR (slow IPI case).
We always start the new process at this point, irrespective of if we
have the state or not in the thread struct or current CPU.
So in the slow case, we attempt to avoid the IPI latency by starting
the process immediately and only waiting for the state to be flushed
when the process actually needs VMX. ie. when we take the VMX
unavailable exception after the context switch.
FP is implemented in a similar way. VSX reuses the FP and VMX code as
it doesn't have any additional state over what FP and VMX used.
I've been benchmarking with Anton Blanchard's context_switch.c benchmark
found here:
http://ozlabs.org/~anton/junkcode/context_switch.c
Using this benchmark as is gives no degradation in performance with these
patches applied.
Inserting a simple FP instruction into one of the threads (gives the
nice save/restore lazy case), I get about a 4% improvement in context
switching rates with my patches applied. I get similar results VMX.
With a simple VSX instruction (VSX state is 64x128bit registers) in 1
thread I get an 8% bump in performance with these patches.
With FP/VMX/VSX instructions in both threads, I get no degradation in
performance.
Running lmbench doesn't have any degradation in performance.
Most of my benchmarking and testing has been done on 64 bit systems.
I've tested 32 bit FP but I've not tested 32 bit VMX at all.
There is probably some optimisations to my asm code that can also be
made. I've been concentrating on correctness, as opposed to speed
with the asm code, since if you get a lazy context switch, you skip
all the asm now anyway.
Whole series is bisectable to compile with various 64/32bit SMP/UP
FPU/VMX/VSX config options on and off.
I really hate the include file changes in this series. Getting the
call_single_data in the powerpc threads_struct was a PITA :-)
Mikey
Signed-off-by: Michael Neuling <mikey@neuling.org>
^ permalink raw reply
* [RFC/PATCH 1/7] Add csd_locked function
From: Michael Neuling @ 2010-12-06 23:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101206234043.083045003@neuling.org>
Add csd_locked function to determine if a struct call_single_data is
currently locked. This can be used to see if an IPI can be called
again using this call_single_data.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
kernel/smp.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Index: linux-lazy/kernel/smp.c
===================================================================
--- linux-lazy.orig/kernel/smp.c
+++ linux-lazy/kernel/smp.c
@@ -12,6 +12,7 @@
#include <linux/gfp.h>
#include <linux/smp.h>
#include <linux/cpu.h>
+#include <linux/hardirq.h>
static struct {
struct list_head queue;
@@ -131,6 +132,22 @@
}
/*
+ * Determine if a csd is currently locked. This can be used to
+ * determine if an IPI is currently pending using this csd already.
+ */
+int csd_locked(struct call_single_data *data)
+{
+ WARN_ON(preemptible());
+
+ /* Ensure flags have propagated */
+ smp_mb();
+
+ if (data->flags & CSD_FLAG_LOCK)
+ return 1;
+ return 0;
+}
+
+/*
* Insert a previously allocated call_single_data element
* for execution on the given CPU. data must already have
* ->func, ->info, and ->flags set.
^ 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