* Re: [RFC PATCH 14/15] dt: Eliminate of_platform_{,un}register_driver
From: Rob Herring @ 2011-02-23 16:56 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, devicetree-discuss, linux-kernel, sparclinux, linuxppc-dev,
davem
In-Reply-To: <20110223043447.20795.80653.stgit@localhost6.localdomain6>
Grant,
On 02/22/2011 10:34 PM, Grant Likely wrote:
> Final step to eliminate of_platform_bus_type. They're all just
> platform drivers now.
>
> Signed-off-by: Grant Likely<grant.likely@secretlab.ca>
> ---
snip
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
> index b6ae6e9..132951d 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2556,8 +2556,7 @@ static struct pci_driver ipmi_pci_driver = {
>
>
> #ifdef CONFIG_PPC_OF
> -static int __devinit ipmi_of_probe(struct platform_device *dev,
> - const struct of_device_id *match)
> +static int __devinit ipmi_of_probe(struct platform_device *dev)
> {
> struct smi_info *info;
> struct resource resource;
> @@ -2568,6 +2567,9 @@ static int __devinit ipmi_of_probe(struct platform_device *dev,
>
> dev_info(&dev->dev, "probing via device tree\n");
>
> + if (!dev->dev.of_match)
> + return -EINVAL;
> +
> ret = of_address_to_resource(np, 0,&resource);
> if (ret) {
> dev_warn(&dev->dev, PFX "invalid address from OF\n");
> @@ -2600,7 +2602,7 @@ static int __devinit ipmi_of_probe(struct platform_device *dev,
> return -ENOMEM;
> }
>
> - info->si_type = (enum si_type) match->data;
> + info->si_type = (enum si_type) dev->dev.of_match->data;
> info->addr_source = SI_DEVICETREE;
> info->irq_setup = std_irq_setup;
>
> @@ -2652,9 +2654,9 @@ static struct of_device_id ipmi_match[] =
> {},
> };
>
> -static struct of_platform_driver ipmi_of_platform_driver = {
> +static struct platform_driver ipmi_of_platform_driver = {
> .driver = {
> - .name = "ipmi",
> + .name = "of-ipmi",
> .owner = THIS_MODULE,
> .of_match_table = ipmi_match,
> },
> @@ -3396,7 +3398,7 @@ static int __devinit init_ipmi_si(void)
> #endif
>
> #ifdef CONFIG_PPC_OF
> - of_register_platform_driver(&ipmi_of_platform_driver);
> + platform_driver_register(&ipmi_of_platform_driver);
> of_registered = 1;
> #endif
>
> @@ -3457,7 +3459,7 @@ static int __devinit init_ipmi_si(void)
>
> #ifdef CONFIG_PPC_OF
> if (of_registered)
> - of_unregister_platform_driver(&ipmi_of_platform_driver);
> + platform_driver_unregister(&ipmi_of_platform_driver);
> #endif
> driver_unregister(&ipmi_driver.driver);
> printk(KERN_WARNING PFX
> @@ -3558,7 +3560,7 @@ static void __exit cleanup_ipmi_si(void)
>
> #ifdef CONFIG_PPC_OF
> if (of_registered)
> - of_unregister_platform_driver(&ipmi_of_platform_driver);
> + platform_driver_unregister(&ipmi_of_platform_driver);
> #endif
>
> mutex_lock(&smi_infos_lock);
Um, you are doing exactly what you said I should not do. Now the driver
has 2 platform drivers defined. I have an updated patch that addresses
your previous comments. I will send it out later today.
Rob
^ permalink raw reply
* Re: [RFC PATCH 14/15] dt: Eliminate of_platform_{,un}register_driver
From: Grant Likely @ 2011-02-23 17:22 UTC (permalink / raw)
To: Rob Herring
Cc: sfr, devicetree-discuss, linux-kernel, sparclinux, linuxppc-dev,
davem
In-Reply-To: <4D653C48.4090608@gmail.com>
On Wed, Feb 23, 2011 at 9:56 AM, Rob Herring <robherring2@gmail.com> wrote:
> Grant,
>
> On 02/22/2011 10:34 PM, Grant Likely wrote:
>>
>> Final step to eliminate of_platform_bus_type. =A0They're all just
>> platform drivers now.
>>
>> Signed-off-by: Grant Likely<grant.likely@secretlab.ca>
>> ---
>
> snip
>
>> diff --git a/drivers/char/ipmi/ipmi_si_intf.c
>> b/drivers/char/ipmi/ipmi_si_intf.c
>> index b6ae6e9..132951d 100644
>> --- a/drivers/char/ipmi/ipmi_si_intf.c
>> +++ b/drivers/char/ipmi/ipmi_si_intf.c
>> @@ -2556,8 +2556,7 @@ static struct pci_driver ipmi_pci_driver =3D {
>>
>>
>> =A0#ifdef CONFIG_PPC_OF
>> -static int __devinit ipmi_of_probe(struct platform_device *dev,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const struct of_device_=
id *match)
>> +static int __devinit ipmi_of_probe(struct platform_device *dev)
>> =A0{
>> =A0 =A0 =A0 =A0struct smi_info *info;
>> =A0 =A0 =A0 =A0struct resource resource;
>> @@ -2568,6 +2567,9 @@ static int __devinit ipmi_of_probe(struct
>> platform_device *dev,
>>
>> =A0 =A0 =A0 =A0dev_info(&dev->dev, "probing via device tree\n");
>>
>> + =A0 =A0 =A0 if (!dev->dev.of_match)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> +
>> =A0 =A0 =A0 =A0ret =3D of_address_to_resource(np, 0,&resource);
>> =A0 =A0 =A0 =A0if (ret) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_warn(&dev->dev, PFX "invalid address =
from OF\n");
>> @@ -2600,7 +2602,7 @@ static int __devinit ipmi_of_probe(struct
>> platform_device *dev,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENOMEM;
>> =A0 =A0 =A0 =A0}
>>
>> - =A0 =A0 =A0 info->si_type =A0 =A0 =A0 =A0 =A0 =3D (enum si_type) match=
->data;
>> + =A0 =A0 =A0 info->si_type =A0 =A0 =A0 =A0 =A0 =3D (enum si_type) dev->=
dev.of_match->data;
>> =A0 =A0 =A0 =A0info->addr_source =A0 =A0 =A0 =3D SI_DEVICETREE;
>> =A0 =A0 =A0 =A0info->irq_setup =A0 =A0 =A0 =A0 =3D std_irq_setup;
>>
>> @@ -2652,9 +2654,9 @@ static struct of_device_id ipmi_match[] =3D
>> =A0 =A0 =A0 =A0{},
>> =A0};
>>
>> -static struct of_platform_driver ipmi_of_platform_driver =3D {
>> +static struct platform_driver ipmi_of_platform_driver =3D {
>> =A0 =A0 =A0 =A0.driver =3D {
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 .name =3D "ipmi",
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .name =3D "of-ipmi",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.owner =3D THIS_MODULE,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.of_match_table =3D ipmi_match,
>> =A0 =A0 =A0 =A0},
>> @@ -3396,7 +3398,7 @@ static int __devinit init_ipmi_si(void)
>> =A0#endif
>>
>> =A0#ifdef CONFIG_PPC_OF
>> - =A0 =A0 =A0 of_register_platform_driver(&ipmi_of_platform_driver);
>> + =A0 =A0 =A0 platform_driver_register(&ipmi_of_platform_driver);
>> =A0 =A0 =A0 =A0of_registered =3D 1;
>> =A0#endif
>>
>> @@ -3457,7 +3459,7 @@ static int __devinit init_ipmi_si(void)
>>
>> =A0#ifdef CONFIG_PPC_OF
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (of_registered)
>> -
>> of_unregister_platform_driver(&ipmi_of_platform_driver);
>> +
>> platform_driver_unregister(&ipmi_of_platform_driver);
>> =A0#endif
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0driver_unregister(&ipmi_driver.driver);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_WARNING PFX
>> @@ -3558,7 +3560,7 @@ static void __exit cleanup_ipmi_si(void)
>>
>> =A0#ifdef CONFIG_PPC_OF
>> =A0 =A0 =A0 =A0if (of_registered)
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_unregister_platform_driver(&ipmi_of_pla=
tform_driver);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 platform_driver_unregister(&ipmi_of_platfo=
rm_driver);
>> =A0#endif
>>
>> =A0 =A0 =A0 =A0mutex_lock(&smi_infos_lock);
>
> Um, you are doing exactly what you said I should not do. Now the driver h=
as
> 2 platform drivers defined. I have an updated patch that addresses your
> previous comments. I will send it out later today.
Thanks. I wacked this whole series out one evening and converted all
the drivers at once, so it's not surprising that I missed some
duplications. Send me your patch and I'll drop my changes here.
g.
^ permalink raw reply
* Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Scott Wood @ 2011-02-23 17:26 UTC (permalink / raw)
To: Grant Likely
Cc: Mike Frysinger, Christoph Lameter, Russell King, Arnd Bergmann,
Peter Zijlstra, linux-api, Richard Cochran, linuxppc-dev,
linux-kernel, David Miller, Paul Mackerras, linux-arm-kernel,
netdev, John Stultz, Thomas Gleixner, Rodolfo Giometti,
devicetree-discuss, Alan Cox, Krzysztof Halasa
In-Reply-To: <20110223165058.GE14597@angua.secretlab.ca>
On Wed, 23 Feb 2011 09:50:58 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Feb 23, 2011 at 11:38:17AM +0100, Richard Cochran wrote:
> > +
> > +* Gianfar PTP clock nodes
> > +
> > +General Properties:
> > +
> > + - compatible Should be "fsl,etsec-ptp"
>
> Should specify an *exact* part; ie: "fsl,mpc8313-etsec-ptp" instead of
> trying to define a generic catchall. The reason is that the same
> marketing name can end up getting applied to a wide range of parts.
>
> Instead, choose one specific device to stand in as the 'common'
> implementation and get all parts with the same core to claim
> compatibility with it. ie: a p2020 might have:
>
> compatible = "fsl,mpc2020-etsec-ptp", "fsl,mpc8313-etsec-ptp";
eTSEC is versioned, that's more reliable than the chip name since chips
have revisions (rev 2.1 of mpc8313 has eTSEC 1.6, not sure about previous
revs of mpc8313). Logic blocks can be and have been uprevved between one
revision of a chip to the next. I think "fsl,mpc8313rev2.1-etsec-ptp"
would be taking things a bit too far (and there could be board-level bugs
too...).
If you really need to know the exact SoC you're on, look in SVR (which
will provide revision info as well). Isn't the device tree for things that
can't be probed?
The eTSEC revision is probeable as well, but due the way PTP is described as
a separate node, the driver doesn't have straightforward access to those
registers.
Insisting on an explicit chip also encourages people to claim compatibility
with that chip without ensuring that it really is fully compatible.
-Scott
^ permalink raw reply
* Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Grant Likely @ 2011-02-23 17:54 UTC (permalink / raw)
To: Scott Wood
Cc: Mike Frysinger, Christoph Lameter, Russell King, Arnd Bergmann,
Peter Zijlstra, linux-api, Richard Cochran, linuxppc-dev,
linux-kernel, David Miller, Paul Mackerras, linux-arm-kernel,
netdev, John Stultz, Thomas Gleixner, Rodolfo Giometti,
devicetree-discuss, Alan Cox, Krzysztof Halasa
In-Reply-To: <20110223112612.30071995@schlenkerla>
On Wed, Feb 23, 2011 at 11:26:12AM -0600, Scott Wood wrote:
> On Wed, 23 Feb 2011 09:50:58 -0700
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
> > On Wed, Feb 23, 2011 at 11:38:17AM +0100, Richard Cochran wrote:
> > > +
> > > +* Gianfar PTP clock nodes
> > > +
> > > +General Properties:
> > > +
> > > + - compatible Should be "fsl,etsec-ptp"
> >
> > Should specify an *exact* part; ie: "fsl,mpc8313-etsec-ptp" instead of
> > trying to define a generic catchall. The reason is that the same
> > marketing name can end up getting applied to a wide range of parts.
> >
> > Instead, choose one specific device to stand in as the 'common'
> > implementation and get all parts with the same core to claim
> > compatibility with it. ie: a p2020 might have:
> >
> > compatible = "fsl,mpc2020-etsec-ptp", "fsl,mpc8313-etsec-ptp";
>
> eTSEC is versioned, that's more reliable than the chip name since chips
> have revisions (rev 2.1 of mpc8313 has eTSEC 1.6, not sure about previous
> revs of mpc8313). Logic blocks can be and have been uprevved between one
> revision of a chip to the next. I think "fsl,mpc8313rev2.1-etsec-ptp"
> would be taking things a bit too far (and there could be board-level bugs
> too...).
>
> If you really need to know the exact SoC you're on, look in SVR (which
> will provide revision info as well). Isn't the device tree for things that
> can't be probed?
This is far more about the binding than it is about the chip revision.
When documenting a binding it makes far more sense to anchor it to a
specific implementation than to try and come up with a 'generic'
catchall. A new binding means new compatible value and dropping any
claims of being compatible with the old.
It is not about the logic block version, particularly when it is
detectable by the driver as you say.
>
> The eTSEC revision is probeable as well, but due the way PTP is described as
> a separate node, the driver doesn't have straightforward access to those
> registers.
Ignorant question: Should the ptp be described as a separate node?
>
> Insisting on an explicit chip also encourages people to claim compatibility
> with that chip without ensuring that it really is fully compatible.
In practise, I've not seen this to be an issue.
g.
^ permalink raw reply
* Re: [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Linux User #330250 @ 2011-02-23 17:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1298326851.8833.75.camel@pasglop>
---------- Original message ----------
Subject: Re: [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
Date: Montag, 21. Februar 2011N
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Takashi Iwai <tiwai@suse.de>
> So somebody else can just pick the "documentation" that layout ID 21
> works just like 22 for us, and write an "acceptable" patch...
Actually, the G4 "Quicksilver" PowerMac3,5 is propably more alike to the G4
"Digital Audio" PowerMac3,4 in this regard. The device ID on the Digital Audio
is decimal 14. The Quicksilver is decimal 21.
PowerMac3,4 Digital Audio: Device ID 14, ??? chip
PowerMac3,5 Quicksilver: Device ID 21, TAS 3001C CODEC chip
PowerMac3,6 Mirrored Drive Doors: Device ID 22, TAS3004 CODEC chip
$LINUX/sound/aoa/codecs/tas.c driver was originally made for the TAS3004,
which I figure because only "tas 3004" is mentioned in the source, no other.
Since the Quicksilver, which is newer than the Digital Audio, doesn't have the
TAS3004 chip (Mac OS X System Profiler states "Texas Intruments TAS3001C"), but
the Digital Audio seemed to work fine with the aoa-tas codec too (it's already
in the kernel) I tried it with the Quicksilver as well.
The modules loads without errors, the sound card is listed
(/proc/asound/cards) and the volume controls are usable.
I played some sound and everything seemed to work fine. So I submitted the
patch.
So now I have to appologize. And I'm glad the patch hasn't been accepted. Why?
Because I had booted with the wrong kernel when I tested if the sound played
okay. I must have still used the powermac sound module, not aoa.
BIG APPOLOGIES.
I tested again yesterday and today and can't get it to play a sound. I also
checked the logs and all the ALSA stuff (in /proc/asound). Everything seems
okay. I then tried a different mixer: pavucontrol -- because I have trouble to
unmute without this on my PC too.
Now the surprise: it won't let me unmute.
Maybe it's just my system. I use Gentoo Linux and just recently updated the
whole system to use Pulse Audio.
If anyone else could try the patch or write a new one on their G4 Quicksilvers
I'd be happy.
And: I do understand the sign-off limiting to real names. It's a good thing.
Cheers,
Andreas aka Mac User #330250
^ permalink raw reply
* Re: [RFC PATCH 07/15] dt: uartlite: merge platform and of_platform driver bindings
From: Grant Likely @ 2011-02-23 18:10 UTC (permalink / raw)
To: Peter Korsgaard
Cc: sfr, devicetree-discuss, linux-kernel, sparclinux, linuxppc-dev,
davem
In-Reply-To: <877hcryvom.fsf@macbook.be.48ers.dk>
On Wed, Feb 23, 2011 at 09:58:01AM +0100, Peter Korsgaard wrote:
> >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
>
> Grant> of_platform_driver is getting removed, and a single platform_driver
> Grant> can now support both devicetree and non-devicetree use cases. This
> Grant> patch merges the two driver registrations.
>
> Wee!
>
> Grant> static int __devinit ulite_probe(struct platform_device *pdev)
> Grant> {
> Grant> struct resource *res, *res2;
> Grant> + const __be32 *prop;
> Grant> + int id = pdev->id;
>
> Grant> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> Grant> if (!res)
> Grant> @@ -583,7 +586,13 @@ static int __devinit ulite_probe(struct platform_device *pdev)
> Grant> if (!res2)
> Grant> return -ENODEV;
>
> Grant> - return ulite_assign(&pdev->dev, pdev->id, res->start, res2->start);
> Grant> +#ifdef CONFIG_OF
> Grant> + prop = of_get_property(pdev->dev.of_node, "port-number", NULL);
> Grant> + if (prop)
> Grant> + id = be32_to_cpup(prop);
> Grant> +#endif
> Grant> +
> Grant> + return ulite_assign(&pdev->dev, id, res->start, res2->start);
> Grant> }
>
> Isn't this going to give a build warning about prop being unused on
> !CONFIG_OF builds? Perhaps move it down into the CONFIG_OF conditional?
I'd actually like to be rid of 'port-number' entirely; but that's
another day's debate. I'll fix this up.
g.
^ permalink raw reply
* Re: [RFC PATCH 02/15] dt: add a match table pointer to struct device
From: Rob Herring @ 2011-02-23 18:29 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, devicetree-discuss, linux-kernel, sparclinux, linuxppc-dev,
davem
In-Reply-To: <20110223043345.20795.2936.stgit@localhost6.localdomain6>
Grant,
On 02/22/2011 10:33 PM, Grant Likely wrote:
> Add a new .of_match field to struct device which points at the
> matching device driver .of_match_table entry when a device is probed
> via the device tree
>
> Signed-off-by: Grant Likely<grant.likely@secretlab.ca>
> ---
> include/linux/device.h | 1 +
> include/linux/of_device.h | 5 +++--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index ca5d252..8d8e267 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -441,6 +441,7 @@ struct device {
> struct dev_archdata archdata;
>
> struct device_node *of_node; /* associated device tree node */
> + const struct of_device_id *of_match; /* matching of_device_id from driver */
Couldn't of_match/of_match_table be merged into the platform dev/drv
id_entry/id_table. Handling MODALIAS for a driver that does both OF
style and normal platform device matching may be a problem though.
Rob
^ permalink raw reply
* Re: [RFC PATCH 02/15] dt: add a match table pointer to struct device
From: Grant Likely @ 2011-02-23 18:44 UTC (permalink / raw)
To: Rob Herring
Cc: sfr, devicetree-discuss, linux-kernel, sparclinux, linuxppc-dev,
davem
In-Reply-To: <4D6551EF.70207@gmail.com>
On Wed, Feb 23, 2011 at 12:29:03PM -0600, Rob Herring wrote:
> Grant,
>
> On 02/22/2011 10:33 PM, Grant Likely wrote:
> >Add a new .of_match field to struct device which points at the
> >matching device driver .of_match_table entry when a device is probed
> >via the device tree
> >
> >Signed-off-by: Grant Likely<grant.likely@secretlab.ca>
> >---
> > include/linux/device.h | 1 +
> > include/linux/of_device.h | 5 +++--
> > 2 files changed, 4 insertions(+), 2 deletions(-)
> >
> >diff --git a/include/linux/device.h b/include/linux/device.h
> >index ca5d252..8d8e267 100644
> >--- a/include/linux/device.h
> >+++ b/include/linux/device.h
> >@@ -441,6 +441,7 @@ struct device {
> > struct dev_archdata archdata;
> >
> > struct device_node *of_node; /* associated device tree node */
> >+ const struct of_device_id *of_match; /* matching of_device_id from driver */
>
> Couldn't of_match/of_match_table be merged into the platform dev/drv
> id_entry/id_table. Handling MODALIAS for a driver that does both OF
> style and normal platform device matching may be a problem though.
.of_match & .of_match_table works on all devices, not just
platform devices. It allows the common library of device tree support
routines to be used with any bus type.
g.
^ permalink raw reply
* Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Scott Wood @ 2011-02-23 19:24 UTC (permalink / raw)
To: Grant Likely
Cc: Mike Frysinger, Christoph Lameter, Russell King, Arnd Bergmann,
Peter Zijlstra, linux-api, Richard Cochran, linuxppc-dev,
linux-kernel, David Miller, Paul Mackerras, linux-arm-kernel,
netdev, John Stultz, Thomas Gleixner, Rodolfo Giometti,
devicetree-discuss, Alan Cox, Krzysztof Halasa
In-Reply-To: <20110223175459.GH14597@angua.secretlab.ca>
On Wed, 23 Feb 2011 10:54:59 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Feb 23, 2011 at 11:26:12AM -0600, Scott Wood wrote:
> > eTSEC is versioned, that's more reliable than the chip name since chips
> > have revisions (rev 2.1 of mpc8313 has eTSEC 1.6, not sure about previous
> > revs of mpc8313). Logic blocks can be and have been uprevved between one
> > revision of a chip to the next. I think "fsl,mpc8313rev2.1-etsec-ptp"
> > would be taking things a bit too far (and there could be board-level bugs
> > too...).
> >
> > If you really need to know the exact SoC you're on, look in SVR (which
> > will provide revision info as well). Isn't the device tree for things that
> > can't be probed?
>
> This is far more about the binding than it is about the chip revision.
> When documenting a binding it makes far more sense to anchor it to a
> specific implementation than to try and come up with a 'generic'
> catchall.
Whatever string is used should be written into a binding document.
fsl,etsec-v1.6-ptp seems like it would be just as good for that purpose.
Even just fsl,etsec-ptp will identify the binding, though it's lacking in
identifying the hardware (in the absence of access to the eTSEC ID
registers).
If somehow Freescale makes something completely different in the future
called "etsec-ptp", then we'll just have to pick a different name for
*that* compatible (after we smack whoever was responsible for reusing the
name). The point of the vendor namespacing is to constrain this problem to
a manageable scope.
> > The eTSEC revision is probeable as well, but due the way PTP is described as
> > a separate node, the driver doesn't have straightforward access to those
> > registers.
>
> Ignorant question: Should the ptp be described as a separate node?
Probably not.
> > Insisting on an explicit chip also encourages people to claim compatibility
> > with that chip without ensuring that it really is fully compatible.
>
> In practise, I've not seen this to be an issue.
I see it often enough in our BSPs (though the BSP device trees tend to be
problematic in a variety of ways), especially on things like guts and
pmc.
It's a question of how strong a statement people are asked to make -- in a
place where fixing errors is somewhat painful, and we don't really need that
strong statement of compatibility to be made, as long as there's another
way to fully identify the hardware (e.g. SVR, top-level board compatible) if
some strange workaround needs to be made[1].
To turn things around, in practice, I've not seen compatibles that don't
encode a specific chip name to be a problem, as long as it's well
documented what it means.
-Scott
[1] IIRC, this was the original reason for citing a specific chip, but it
doesn't hold up if that chip gets cited by other chips as compatible. If
compatibliity includes having all the same bugs, then very little will be
able to claim compatibility, and we'll be back to long lists of device
IDs in the driver. Not to mention errata that are discovered after a
device tree claiming compatibility is released...
^ permalink raw reply
* rtc on PowerMac7,3
From: kevin diggs @ 2011-02-23 19:39 UTC (permalink / raw)
To: Linux PPC Development
Hi,
Sorry for the noise.
How do I access the rtc on a PowerMac7,3 (dual 2.5 GHz 970FX) using
2.6.36? rtc-generic does not seem to work. It will work on my 8600. I
do see this:
[ 15.014542] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
Is it the hwclock binary:
hwclock from util-linux-2.13-pre7
I think I could get this to work in 2.6.28 using rtc-ppc.
Thanks!
kevin
^ permalink raw reply
* Re: rtc on PowerMac7,3
From: Benjamin Herrenschmidt @ 2011-02-23 19:42 UTC (permalink / raw)
To: kevin diggs; +Cc: Linux PPC Development
In-Reply-To: <AANLkTinz=CrCTEeAPQjE8B=yjQx+WLs_FKj2u+0-JeAS@mail.gmail.com>
On Wed, 2011-02-23 at 13:39 -0600, kevin diggs wrote:
> Hi,
>
> Sorry for the noise.
>
> How do I access the rtc on a PowerMac7,3 (dual 2.5 GHz 970FX) using
> 2.6.36? rtc-generic does not seem to work. It will work on my 8600. I
> do see this:
>
> [ 15.014542] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
rtc-generic should work...
Cheers,
Ben.
> Is it the hwclock binary:
>
> hwclock from util-linux-2.13-pre7
>
> I think I could get this to work in 2.6.28 using rtc-ppc.
>
> Thanks!
>
> kevin
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH][v1] RTC driver(Linux) for PT7C4338 chip.
From: Timur Tabi @ 2011-02-23 20:10 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Paul Gortmaker, Aggrwal Poonam-B10812, rtc-linux@googlegroups.com,
Jain Priyanka-B32167, Gala Kumar-B11780, Gupta Maneesh-B18878,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <470DB7CE2CD0944E9436E7ADEFC02FE31370D8@039-SN1MPN1-003.039d.mgd.msft.net>
On Wed, Feb 23, 2011 at 4:00 AM, Jain Priyanka-B32167
<B32167@freescale.com> wrote:
> Hi,
>
> =A0Please review and acknowledge this patch.
Alessandro,
Aren't you the RTC maintainer? Priyanka has been asking for months
for you to review and ack this patch, and then pick up for the next
kernel release. Is there something else that she needs to do to get
your attention? You can find it in patchworks here:
http://patchwork.ozlabs.org/patch/69206/
Notice that it was originally posted back in October, so it could have
been included in 2.6.38.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* mpc85xx: kexec build broken by "powerpc/kexec: Remove ppc_md.machine_kexec"
From: Moffett, Kyle D @ 2011-02-23 20:54 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Cc: Anton Blanchard, Livingston, John A, Matthew McClintock
Hello everyone,
I just started trying to update some patches for our P2020-based unit to th=
e latest Linus upstream, hoping to take advantage of the recent mpc85xx kex=
ec() support.
Unfortunately I'm getting a compile error:
arch/powerpc/platforms/85xx/smp.c:241: error: 'struct machdep_calls' has no=
member named 'machine_kexec'
As far as I can tell, "machine_kexec" was removed in commit c9486878 (power=
pc/kexec: Remove ppc_md.machine_kexec) on Jan 6th, 2011, which claims that =
it was not used.
Unfortunately it looks like it *is* used by the mpc85xx kexec() support (co=
mmit f933a41e), added on Jul 21, 2010.
Cheers,
Kyle Moffett
^ permalink raw reply
* Open Firmware and interrupt trigger
From: Robert Thorhuus @ 2011-02-23 21:18 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4D6551EF.70207@gmail.com>
Hello!
I'm quite new to linux and Open Firmware.
I have a PPC processor. To this I have a Compact Flash connected. The Compa=
ct Flash is using external interrupt 0 of the processor.
In my DTS file I have specified a Compact Flash node and within it I have a=
n interrupt element:
interrupt =3D <0 2 0 0>;
Here I thought the first number was the ID of the interrupt and the second =
one should be a number indicating how the interrupt is triggered (high, low=
, raising, falling).
The interrupt is active low.
But I could not get it to work which ever value I chose.
Looking in the code I found this in function __devinit pata_of_platform_pro=
be in file pata_of_platform.c:
ret =3D of_irq_to_resource(dn, 0, &irq_res);
if (ret =3D=3D NO_IRQ)
irq_res.start =3D irq_res.end =3D 0;
else
irq_res.flags =3D 0;
Here "flags" will be zero whatever I do in the DTS. As far as I can underst=
and the flags are defined in interrupts.h:
#define IRQF_TRIGGER_NONE 0x00000000
#define IRQF_TRIGGER_RISING 0x00000001
#define IRQF_TRIGGER_FALLING 0x00000002
#define IRQF_TRIGGER_HIGH 0x00000004
#define IRQF_TRIGGER_LOW 0x00000008
So modifying the code to:
else
irq_res.flags =3D 2;
I get it to work.
Could someone please explain to me why the "flags" parameter is hardcoded z=
ero or just point in a good direction.
Thank you
BR
Robert=
^ permalink raw reply
* Re: mpc85xx: kexec build broken by "powerpc/kexec: Remove ppc_md.machine_kexec"
From: Anton Blanchard @ 2011-02-23 22:11 UTC (permalink / raw)
To: Moffett, Kyle D
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Livingston, John A, Matthew McClintock
In-Reply-To: <B87A2622-0006-4FC8-893A-41DBBF0CA170@boeing.com>
Hi Kyle,
> As far as I can tell, "machine_kexec" was removed in commit c9486878
> (powerpc/kexec: Remove ppc_md.machine_kexec) on Jan 6th, 2011, which
> claims that it was not used.
>
> Unfortunately it looks like it *is* used by the mpc85xx kexec()
> support (commit f933a41e), added on Jul 21, 2010.
Thanks for the report. Testing a patch now.
Anton
^ permalink raw reply
* powerpc/kexec: Restore ppc_md.machine_kexec
From: Anton Blanchard @ 2011-02-23 22:46 UTC (permalink / raw)
To: benh, msm, john.a.livingston, Kyle.D.Moffett; +Cc: linuxppc-dev, linux-kernel
Kyle Moffett points out that mpc85xx has started using the
ppc_md.machine_kexec hook. As such, revert patch c94868788cf2
(powerpc/kexec: Remove ppc_md.machine_kexec).
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 991d599..fe56a23 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -240,6 +240,12 @@ struct machdep_calls {
* claims to support kexec.
*/
int (*machine_kexec_prepare)(struct kimage *image);
+
+ /* Called to perform the _real_ kexec.
+ * Do NOT allocate memory or fail here. We are past the point of
+ * no return.
+ */
+ void (*machine_kexec)(struct kimage *image);
#endif /* CONFIG_KEXEC */
#ifdef CONFIG_SUSPEND
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index 49a170a..a5f8672 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -87,7 +87,10 @@ void machine_kexec(struct kimage *image)
save_ftrace_enabled = __ftrace_enabled_save();
- default_machine_kexec(image);
+ if (ppc_md.machine_kexec)
+ ppc_md.machine_kexec(image);
+ else
+ default_machine_kexec(image);
__ftrace_enabled_restore(save_ftrace_enabled);
^ permalink raw reply related
* Re: rtc on PowerMac7,3
From: kevin diggs @ 2011-02-23 23:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <1298490130.8833.212.camel@pasglop>
On Wed, Feb 23, 2011 at 1:42 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>> [ =A0 15.014542] rtc-generic rtc-generic: rtc core: registered rtc-gener=
ic as rtc0
>
> rtc-generic should work...
>
> Cheers,
> Ben.
>
It probably does on everyone else's 7,3. The 8600 probably infected
it. ... I hear the two of them out there late at night. Mumbling to
each other ... plotting ...
kevin
^ permalink raw reply
* Re: powerpc/ptrace: Fix bug in signal handling
From: Michael Neuling @ 2011-02-24 0:02 UTC (permalink / raw)
To: mjw, Michael Wolf; +Cc: linuxppc-dev, anton
In-Reply-To: <1298406645.9824.3.camel@w500>
Mike,
> Subject: powerpc/ptrace: Fix bug in signal handling
Maybe something more descriptive here like:
powerpc/ptrace: remove BUG_ON when full register set not available
> In some cases during a threaded core dump not all
> the threads will have a full register set. This
> will cause problems when the sigkill is sent to
> the thread
Please add a description for how you are solving this. Something like
"Solve this by putting poison values in the registers". Similar inline
comments would be good too.
Also, I'm not convinced this is the right solution... not that I have a
have a better one to suggest :-)
<snip>
> +static inline int user_regset_copyout_poison(unsigned int *pos,
> + unsigned int *count,
> + void **kbuf, void __user **ubuf,
> + const int start_pos,
> + const int end_pos)
> +{
> + long poison_data[17] = { [0 ... 16] = 0xdeadbeefdeadbeefUL };
Why only poison 17 registers?
Mikey
^ permalink raw reply
* Re: rtc on PowerMac7,3
From: Benjamin Herrenschmidt @ 2011-02-24 0:09 UTC (permalink / raw)
To: kevin diggs; +Cc: Linux PPC Development
In-Reply-To: <AANLkTinB+CLhJsiu3SBygC7TW+vnOH3e7==h_7nEGWts@mail.gmail.com>
On Wed, 2011-02-23 at 17:24 -0600, kevin diggs wrote:
> It probably does on everyone else's 7,3. The 8600 probably infected
> it. ... I hear the two of them out there late at night. Mumbling to
> each other ... plotting ...
Not sure, I haven't looked at that RTC stuff for ages. Basically the
platform code provides generic RTC hooks (in that G5 it's going to be
via the via-pmu) and it should "just work". That code hasn't been
touched for eons.
Cheers,
Ben.
^ permalink raw reply
* Flushing data cache on PPC405 in Linux
From: John Linn @ 2011-02-24 1:04 UTC (permalink / raw)
To: linuxppc-dev
I have a situation that requires a flush the data cache at specific time
periods to help with memory scrubbing.
On the 405, I don't see any easy way to do this since you don't know
what the cache has in it and there's not an instruction to flush the
whole cache. It looks like a kernel driver is needed to map pages then
flush that data cache for the pages. =
I'm concerned there will be side affects I don't realize as I'm assuming
the driver would slowly go thru all of physical memory mapping pages
(cached or non-cached) and then flushing all addresses in the page(s).
Any thoughts?
Thanks,
John
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Flushing data cache on PPC405 in Linux
From: Dan Malek @ 2011-02-24 3:38 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <ef11a825-8824-460f-91c0-82cb8029ed81@VA3EHSMHS029.ehs.local>
Hi John.
On Feb 23, 2011, at 5:04 PM, John Linn wrote:
> Any thoughts?
I can come up with two methods, but before I describe them
ensure you consider the actual implementation of your 405 core.
My comments are based on the "standard" ppc405 processor,
but since you can configure the embedded cores to your liking,
the cache size may be different that the 16K bytes on the old
processor.
Method one. Just 'memset()' 16K of data that will replace all cache
lines and push out modified lines. This 16K must be physically
contiguous, so allocate in your favorite way, with with the cache
coherent DMA functions, bootmem, reserved, whatever. Just
ensure that this 16K is also cached, as I've implemented
dma_cache_coherent into uncached VM space in the past :-)
Method two. Use 'dcread' to read the cache tags. If the line is
modified, form an EA that will match that line and 'dcbf' the line.
This is a little more tricky because the tags are physical addresses,
so you would need to do this with the MMU disabled to ensure
the physical EA you generated also hits the cache. The upside
is you only perform the actual required flush operations, and you
didn't blow the cache away requiring a refill latency.
Have fun!
-- Dan
^ permalink raw reply
* [PATCH] fsl_pci: Add support for FSL PCIe controllers v2.x
From: Prabhakar Kushwaha @ 2011-02-24 9:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meet2prabhu, Prabhakar Kushwaha
FSL PCIe controller v2.1:
- New MSI inbound window
- Same Inbound windows address as PCIe controller v1.x
Added new pit_t member(pmit) to struct ccsr_pci for MSI inbound window
FSL PCIe controller v2.2 and v2.3:
- Different addresses for PCIe inbound window 3,2,1
- Exposed PCIe inbound window 0
- New PCIe interrupt status register
Added new config and interrupt Status register to struct ccsr_pci & updated
pit_t array size to reflect the 4 inbound windows.
Device tree is used to maintain backward compatibility i.e. update inbound
window 1 index depending upon "compatible" field witin PCIE node.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Acked-by: Kumar Gala <kumar.gala@freescale.com>
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch master )
arch/powerpc/sysdev/fsl_pci.c | 15 +++++++++++----
arch/powerpc/sysdev/fsl_pci.h | 17 ++++++++++-------
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 818f7c6..f8f7f28 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1,7 +1,7 @@
/*
* MPC83xx/85xx/86xx PCI/PCIE support routing.
*
- * Copyright 2007-2010 Freescale Semiconductor, Inc.
+ * Copyright 2007-2011 Freescale Semiconductor, Inc.
* Copyright 2008-2009 MontaVista Software, Inc.
*
* Initial author: Xianghua Xiao <x.xiao@freescale.com>
@@ -99,7 +99,7 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
struct resource *rsrc)
{
struct ccsr_pci __iomem *pci;
- int i, j, n, mem_log, win_idx = 2;
+ int i, j, n, mem_log, win_idx = 3, start_idx = 1, end_idx = 4;
u64 mem, sz, paddr_hi = 0;
u64 paddr_lo = ULLONG_MAX;
u32 pcicsrbar = 0, pcicsrbar_sz;
@@ -109,6 +109,13 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
pr_debug("PCI memory map start 0x%016llx, size 0x%016llx\n",
(u64)rsrc->start, (u64)rsrc->end - (u64)rsrc->start + 1);
+
+ if (of_device_is_compatible(hose->dn, "fsl,qoriq-pcie-v2.2")) {
+ win_idx = 2;
+ start_idx = 0;
+ end_idx = 3;
+ }
+
pci = ioremap(rsrc->start, rsrc->end - rsrc->start + 1);
if (!pci) {
dev_err(hose->parent, "Unable to map ATMU registers\n");
@@ -118,7 +125,7 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
/* Disable all windows (except powar0 since it's ignored) */
for(i = 1; i < 5; i++)
out_be32(&pci->pow[i].powar, 0);
- for(i = 0; i < 3; i++)
+ for (i = start_idx; i < end_idx; i++)
out_be32(&pci->piw[i].piwar, 0);
/* Setup outbound MEM window */
@@ -204,7 +211,7 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
mem_log++;
}
- piwar |= (mem_log - 1);
+ piwar |= ((mem_log - 1) & PIWAR_SZ_MASK);
/* Setup inbound memory window */
out_be32(&pci->piw[win_idx].pitar, 0x00000000);
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index 8ad72a1..a39ed5c 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -1,7 +1,7 @@
/*
* MPC85xx/86xx PCI Express structure define
*
- * Copyright 2007 Freescale Semiconductor, Inc
+ * Copyright 2007,2011 Freescale Semiconductor, Inc
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -21,6 +21,7 @@
#define PIWAR_TGI_LOCAL 0x00f00000 /* target - local memory */
#define PIWAR_READ_SNOOP 0x00050000
#define PIWAR_WRITE_SNOOP 0x00005000
+#define PIWAR_SZ_MASK 0x0000003f
/* PCI/PCI Express outbound window reg */
struct pci_outbound_window_regs {
@@ -49,7 +50,9 @@ struct ccsr_pci {
__be32 int_ack; /* 0x.008 - PCI Interrupt Acknowledge Register */
__be32 pex_otb_cpl_tor; /* 0x.00c - PCIE Outbound completion timeout register */
__be32 pex_conf_tor; /* 0x.010 - PCIE configuration timeout register */
- u8 res2[12];
+ __be32 pex_config; /* 0x.014 - PCIE CONFIG Register */
+ __be32 pex_int_status; /* 0x.018 - PCIE interrupt status */
+ u8 res2[4];
__be32 pex_pme_mes_dr; /* 0x.020 - PCIE PME and message detect register */
__be32 pex_pme_mes_disr; /* 0x.024 - PCIE PME and message disable register */
__be32 pex_pme_mes_ier; /* 0x.028 - PCIE PME and message interrupt enable register */
@@ -62,14 +65,14 @@ struct ccsr_pci {
* in all of the other outbound windows.
*/
struct pci_outbound_window_regs pow[5];
-
- u8 res14[256];
-
-/* PCI/PCI Express inbound window 3-1
+ u8 res14[96];
+ struct pci_inbound_window_regs pmit; /* 0xd00 - 0xd9c Inbound MSI */
+ u8 res6[96];
+/* PCI/PCI Express inbound window 3-0
* inbound window 1 supports only a 32-bit base address and does not
* define an inbound window base extended address register.
*/
- struct pci_inbound_window_regs piw[3];
+ struct pci_inbound_window_regs piw[4];
__be32 pex_err_dr; /* 0x.e00 - PCI/PCIE error detect register */
u8 res21[4];
--
1.7.3
^ permalink raw reply related
* RE: Flushing data cache on PPC405 in Linux
From: John Linn @ 2011-02-24 14:15 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <B5790C8E-AC59-4588-B4C5-A636A4EC1F98@digitaldans.com>
> -----Original Message-----
> From: Dan Malek [mailto:ppc6dev@digitaldans.com]
> Sent: Wednesday, February 23, 2011 8:39 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: Flushing data cache on PPC405 in Linux
> =
> =
> Hi John.
> =
> On Feb 23, 2011, at 5:04 PM, John Linn wrote:
> =
> > Any thoughts?
> =
> I can come up with two methods, but before I describe them
> ensure you consider the actual implementation of your 405 core.
> My comments are based on the "standard" ppc405 processor,
> but since you can configure the embedded cores to your liking,
> the cache size may be different that the 16K bytes on the old
> processor.
> =
> Method one. Just 'memset()' 16K of data that will replace all cache
> lines and push out modified lines. This 16K must be physically
> contiguous, so allocate in your favorite way, with with the cache
> coherent DMA functions, bootmem, reserved, whatever. Just
> ensure that this 16K is also cached, as I've implemented
> dma_cache_coherent into uncached VM space in the past :-)
Awesome Dan, that seems reasonable to me and much easier than I was
thinking :)
I was obviously making it harder than it had to be as usual. Seems like
I can just kmalloc the memory then memset it. =
Appreciate the help and suggestions.
-- John
> =
> Method two. Use 'dcread' to read the cache tags. If the line is
> modified, form an EA that will match that line and 'dcbf' the line.
> This is a little more tricky because the tags are physical addresses,
> so you would need to do this with the MMU disabled to ensure
> the physical EA you generated also hits the cache. The upside
> is you only perform the actual required flush operations, and you
> didn't blow the cache away requiring a refill latency.
> =
> Have fun!
> =
> -- Dan
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* RE: Flushing data cache on PPC405 in Linux
From: John Linn @ 2011-02-24 14:43 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <B5790C8E-AC59-4588-B4C5-A636A4EC1F98@digitaldans.com>
> -----Original Message-----
> From: John Linn
> Sent: Thursday, February 24, 2011 7:15 AM
> To: 'Dan Malek'
> Cc: linuxppc-dev@ozlabs.org; grant.likely@secretlab.ca
> Subject: RE: Flushing data cache on PPC405 in Linux
> =
> > -----Original Message-----
> > From: Dan Malek [mailto:ppc6dev@digitaldans.com]
> > Sent: Wednesday, February 23, 2011 8:39 PM
> > To: John Linn
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: Flushing data cache on PPC405 in Linux
> >
> >
> > Hi John.
> >
> > On Feb 23, 2011, at 5:04 PM, John Linn wrote:
> >
> > > Any thoughts?
> >
> > I can come up with two methods, but before I describe them
> > ensure you consider the actual implementation of your 405 core.
> > My comments are based on the "standard" ppc405 processor,
> > but since you can configure the embedded cores to your liking,
> > the cache size may be different that the 16K bytes on the old
> > processor.
> >
> > Method one. Just 'memset()' 16K of data that will replace all cache
> > lines and push out modified lines. This 16K must be physically
> > contiguous, so allocate in your favorite way, with with the cache
> > coherent DMA functions, bootmem, reserved, whatever. Just
> > ensure that this 16K is also cached, as I've implemented
> > dma_cache_coherent into uncached VM space in the past :-)
> =
> Awesome Dan, that seems reasonable to me and much easier than I was
thinking :)
> =
> I was obviously making it harder than it had to be as usual. Seems
like I can just kmalloc the memory
> then memset it.
It seems like this also depends on that fact that __GFP_COLD will work,
otherwise some of the data could =
already be in the cache such that you're not guaranteed to get
everything out of the cache.
Do we know that works on arch/powerpc, or I'm not understanding it
right? I'm doing some digging to make sure.
Thanks,
John
> =
> Appreciate the help and suggestions.
> =
> -- John
> =
> >
> > Method two. Use 'dcread' to read the cache tags. If the line is
> > modified, form an EA that will match that line and 'dcbf' the line.
> > This is a little more tricky because the tags are physical
addresses,
> > so you would need to do this with the MMU disabled to ensure
> > the physical EA you generated also hits the cache. The upside
> > is you only perform the actual required flush operations, and you
> > didn't blow the cache away requiring a refill latency.
> >
> > Have fun!
> >
> > -- Dan
> >
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [RFC PATCH 01/15] dt/powerpc: move of_bus_type infrastructure to ibmebus
From: Arnd Bergmann @ 2011-02-24 14:46 UTC (permalink / raw)
To: devicetree-discuss; +Cc: sfr, linux-kernel, sparclinux, linuxppc-dev, davem
In-Reply-To: <20110223043340.20795.84024.stgit@localhost6.localdomain6>
On Wednesday 23 February 2011, Grant Likely wrote:
> arch/powerpc/kernel/ibmebus.c is the only remaining user of the
> of_bus_type support code for initializing the bus and registering
> drivers. All others have either been switched to the vanilla platform
> bus or already have their own infrastructure.
>
> This patch moves the functionality that ibmebus is using out of
> drivers/of/{platform,device}.c and into ibmebus.c where it is actually
> used. Also renames the moved symbols from of_platform_* to
> ibmebus_bus_* to reflect the actual usage.
>
> This patch is part of moving all of the of_platform_bus_type users
> over to the platform_bus_type.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
The ibmebus is essentially the platform bus of the IBM Power Systems (a.k.a.
pSeries a.k.a. System p), I think it would make a lot of sense to convert
the two drivers (ehca and ehea) on this bus into platform drivers as well.
The original reason for this bus was to provide a different IOMMU for them
than what is used on the PCI devices. This should now be possible in simpler
ways.
>
> +static void ibmebus_bus_device_shutdown(struct device *dev)
> +{
> + struct platform_device *of_dev = to_platform_device(dev);
> + struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
> +
> + if (dev->driver && drv->shutdown)
> + drv->shutdown(of_dev);
> +}
neither of the drivers provides a shutdown function.
> +#ifdef CONFIG_PM_SLEEP
> +static int ibmebus_bus_legacy_suspend(struct device *dev, pm_message_t mesg)
> +{
> + struct platform_device *of_dev = to_platform_device(dev);
> + struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
> + int ret = 0;
> +
> + if (dev->driver && drv->suspend)
> + ret = drv->suspend(of_dev, mesg);
> + return ret;
> +}
> +
> +static int ibmebus_bus_legacy_resume(struct device *dev)
> +{
> + struct platform_device *of_dev = to_platform_device(dev);
> + struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
> + int ret = 0;
> +
> + if (dev->driver && drv->resume)
> + ret = drv->resume(of_dev);
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_prepare(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (drv && drv->pm && drv->pm->prepare)
> + ret = drv->pm->prepare(dev);
> +
> + return ret;
> +}
> +
> +static void ibmebus_bus_pm_complete(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> +
> + if (drv && drv->pm && drv->pm->complete)
> + drv->pm->complete(dev);
> +}
> +
> +#ifdef CONFIG_SUSPEND
> +
> +static int ibmebus_bus_pm_suspend(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->suspend)
> + ret = drv->pm->suspend(dev);
> + } else {
> + ret = ibmebus_bus_legacy_suspend(dev, PMSG_SUSPEND);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_suspend_noirq(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->suspend_noirq)
> + ret = drv->pm->suspend_noirq(dev);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_resume(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->resume)
> + ret = drv->pm->resume(dev);
> + } else {
> + ret = ibmebus_bus_legacy_resume(dev);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_resume_noirq(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->resume_noirq)
> + ret = drv->pm->resume_noirq(dev);
> + }
> +
> + return ret;
> +}
These are also unused in the drivers.
> +#ifdef CONFIG_HIBERNATION
> +
> +static int ibmebus_bus_pm_freeze(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->freeze)
> + ret = drv->pm->freeze(dev);
> + } else {
> + ret = ibmebus_bus_legacy_suspend(dev, PMSG_FREEZE);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_freeze_noirq(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->freeze_noirq)
> + ret = drv->pm->freeze_noirq(dev);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_thaw(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->thaw)
> + ret = drv->pm->thaw(dev);
> + } else {
> + ret = ibmebus_bus_legacy_resume(dev);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_thaw_noirq(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->thaw_noirq)
> + ret = drv->pm->thaw_noirq(dev);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_poweroff(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->poweroff)
> + ret = drv->pm->poweroff(dev);
> + } else {
> + ret = ibmebus_bus_legacy_suspend(dev, PMSG_HIBERNATE);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_poweroff_noirq(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->poweroff_noirq)
> + ret = drv->pm->poweroff_noirq(dev);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_restore(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->restore)
> + ret = drv->pm->restore(dev);
> + } else {
> + ret = ibmebus_bus_legacy_resume(dev);
> + }
> +
> + return ret;
> +}
> +
> +static int ibmebus_bus_pm_restore_noirq(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + int ret = 0;
> +
> + if (!drv)
> + return 0;
> +
> + if (drv->pm) {
> + if (drv->pm->restore_noirq)
> + ret = drv->pm->restore_noirq(dev);
> + }
> +
> + return ret;
> +}
And these, too.
Arnd
^ 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