* Re: [PATCH][DTC] Add an option to pad the blob that is generated
From: Jon Loeliger @ 2007-12-04 13:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711281020240.5095@blarg.am.freescale.net>
So, like, the other day Kumar Gala mumbled:
> There are times when we need extra space in the blob and just want
> to have it added on w/o know the exact size to make it.
>
> The padding and min size options are mutually exclusive.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Fix uninitialized use of structure_ok
From: Jon Loeliger @ 2007-12-04 13:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071204004943.GD32577@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> My rework of the tree checking code introduced a potentially nasty bug
> - it uses the structure_ok variable uninitialized. This patch fixes
> the problem. It's a fairly ugly bandaid approach, but the ugly will
> disappear once future patches have folded the semantic checks into the
> new framework.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks!
jdl
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] pasemi: Register i2c_board_info
From: David Woodhouse @ 2007-12-04 13:28 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071130032923.GB25580@lixom.net>
On Thu, 2007-11-29 at 21:29 -0600, Olof Johansson wrote:
> + continue;
> +
> + info.addr = *addr;
> +
> + i2c_register_board_info(PCI_FUNC(pdev->devfn),
> &info,
> + 1);
> + }
> + }
+ /* Ensure that buses up to 2 are reserved */
+ i2c_register_board_info(2, NULL, 0);
+
> + return 0;
> +}
> +device_initcall(pasemi_register_i2c_devices);
> +#endif
Otherwise when you make i2c-pasemi use i2c_add_numbered_adapter(), it
might fail to register the third bus -- because there were no devices
preregistered on it, so something else might have stolen that bus number
already.
You might want to add the patch to use i2c_add_numbered_adapter() to
your tree, btw.
--
dwmw2
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
From: Grant Likely @ 2007-12-04 13:36 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, olof
In-Reply-To: <Pine.LNX.4.62.0712041320250.12181@pademelon.sonytel.be>
On 12/4/07, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Sat, 1 Dec 2007, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > This patch makes the platform code use the new machine-specific initcall
> > hooks. This has the advantage of not needing to explicitly test
> > machine_is() at the top of every initcall function.
>
> You seem to have missed the PS3 *_initcall()s.
> Probably because they test for firmware_has_feature(FW_FEATURE_PS3_LV1) instead
> of machine_is(ps3).
That's exactly why; I didn't know if 'machine_is(ps3)' was a suitable
substitute so I left it alone.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
From: Geert Uytterhoeven @ 2007-12-04 13:43 UTC (permalink / raw)
To: Grant Likely, Geoff Levand; +Cc: olof, Linux/PPC Development
In-Reply-To: <fa686aa40712040536h18bd60d3xf89af1f89f6a92ad@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1414 bytes --]
On Tue, 4 Dec 2007, Grant Likely wrote:
> On 12/4/07, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > On Sat, 1 Dec 2007, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > This patch makes the platform code use the new machine-specific initcall
> > > hooks. This has the advantage of not needing to explicitly test
> > > machine_is() at the top of every initcall function.
> >
> > You seem to have missed the PS3 *_initcall()s.
> > Probably because they test for firmware_has_feature(FW_FEATURE_PS3_LV1) instead
> > of machine_is(ps3).
>
> That's exactly why; I didn't know if 'machine_is(ps3)' was a suitable
> substitute so I left it alone.
I think it's OK. But...
Geoff: is there any specific reason why you used
firmware_has_feature(FW_FEATURE_PS3_LV1)?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: dtc: Add may const qualifications
From: Jon Loeliger @ 2007-12-04 13:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071204032615.GK32577@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This adds 'const' qualifiers to many variables and functions. In
> particular it's now used for passing names to the tree accesor
> functions.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Typo fixed, rebased and applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
From: Grant Likely @ 2007-12-04 14:21 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, olof
In-Reply-To: <fa686aa40712040536h18bd60d3xf89af1f89f6a92ad@mail.gmail.com>
On 12/4/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 12/4/07, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > On Sat, 1 Dec 2007, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > This patch makes the platform code use the new machine-specific initcall
> > > hooks. This has the advantage of not needing to explicitly test
> > > machine_is() at the top of every initcall function.
> >
> > You seem to have missed the PS3 *_initcall()s.
> > Probably because they test for firmware_has_feature(FW_FEATURE_PS3_LV1) instead
> > of machine_is(ps3).
>
> That's exactly why; I didn't know if 'machine_is(ps3)' was a suitable
> substitute so I left it alone.
On that topic; I left some pseries and iseries stuff alone also for
the same reason.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-12-04 14:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Rafael J. Wysocki, linux-scsi, Matthew Wilcox, LKML,
Kyle McMartin, linuxppc-dev, Andrew Morton, Balbir Singh
In-Reply-To: <20071204122005.GA27286@elte.hu>
Ingo Molnar wrote:
> * Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>>> So 2.6.24-rc3 was OK and 2.6.24-rc3-git2 is not?
>> Yes, the 2.6.24-rc3 was Ok and this is seen from 2.6.24-rc3-git2/3/4.
>
> just to make sure: this is a real lockup and failed bootup (or device
> init), not just a message, right?
>
> Ingo
> --
Hi Ingo,
This softlockup is seen in the 2.6.24-rc4 either and looks like a message because
this is seen while running tbench and machine continues running other test's after
the softlockup messages and some times seen with the bootup, but the machines reaches the
login prompt and able to continue running tests.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: Merge dtc
From: Josh Boyer @ 2007-12-04 15:26 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Paul, David Woodhouse, Mackerras, David Gibson
In-Reply-To: <E1IzXmf-0005RJ-27@jdl.com>
On Tue, 04 Dec 2007 07:25:57 -0600
Jon Loeliger <jdl@jdl.com> wrote:
> So, like, the other day David Woodhouse mumbled:
> >
> > I think this is a bad idea -- it's hardly a difficult for those people
> > who _do_ need dts to obtain it separately.
> >
> > We shouldn't be merging _more_ stuff in.
>
> Thanks for chiming in here, David W. As far as I can tell
> so far, the only two people who have voiced an opinion on
> this issue are Dave G, submitting patches, and me disagreeing
> with the approach. :-)
>
> Anyone else?
I don't see an overwhelmingly great reason to merge it. It might help
test people who do automated rebuilds, etc and aren't used to dealing
with powerpc and it's requirements. Outside of that, I see it as
dual-maintenance.
But I'm not doing the maintenance, and it doesn't effect me too much.
I only ask that a decision is made and executed on soon so we can move
on.
josh
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-12-04 15:32 UTC (permalink / raw)
To: Scott Wood; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <20071204130841.GA5765@loki.buserror.net>
Hi, Scott!
Scott Wood schrieb:
>>> How would you tell the
>>> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c
>>> bus
>>> 0, and a "bar" chip at address 0x68 on i2c bus 1?
>>
>> I would prefer to not tell the driver for 'foo' that it should attach to
>> 0-0068
>> because it should attach to the first i2c bus (0) it finds per default.
>
> Absolutely wrong.
Hmm... Why?
> What if foo is on bus 1?
Then I would need to tell the driver 'foo' that it should attach
to 1-0068. Sorry, I really don't understand your problem here.
If we have 'foo' on both busses, I need of course tell it
to attach to 0-0068 as well as 1-0068.
Propably you should see the bigger picture here:
We just need to tell what we have, if it's not some default...
statically (kconfig) or dynamically (of/dt) to get it right
because we cannot probe for sure what we have (in contrast to PCI).
I just don't want to be pushed into configuring things twice or on
two different places because that's error prone.
>> Then I would need to tell 'bar' to attach to 1-0068. Where is the problem?
>
> OK, now say there's another foo on bus 2, and a pair of bars on buses 3 and
> 4?
Okay, let's play that game:
foo -> connect an instance to 0-0068 and 2-0068
bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068
If i.e. bar is a 8-page eeprom which hw-configurable addresses nailed
down to 0x50 and 0x58 to have a contigous eeprom area from 0x50 to 0x5f
it can also look like:
bar -> connect an instance to 1-0050 and 1-0058
I still don't see a conflict here.
You cannot connect more than one device to an address, that would
violate the I2C Spec. If you have different devices with the same
address, you have to nail down which ones belong together.
>> The 0068 is already redundant in the case of these RTCs because they are
>> fixed.
>
> How do you know I'm even talking about RTCs?
Well, the subject is about RTCs.
But still the same applys for other i2c devices.
> Those chips at 0x68 could be
> anything. There are many chips that don't have a single fixed address.
Sure. Just to make sure
>> There is already an example in the kernel for a very similar configuration
>> issue: see CONFIG_RTC_HCTOSYS_DEVICE.
>
> That's not remotely the same. That's telling a kernel init procedure what
> kernel device to use, not describing the layout of hardware.
I was trying to tell you that the structure to embed above information
is already there.
>>> The structure for this already present in kconfig,
>
> It is not.
Okay, our point of view is different here.
> We really should try to get the table populated with names for all of the
> new-style drivers in the kernel, though.
Yes. That's what's really necessary to put usability back in.
>> linux-2.6/Documentation/powerpc$ grep "rtc" *
>> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant,
>> btw.).
>> which could give a clue what's going on here.
>> linux-2.6/Documentation/powerpc$ grep "fsl_soc" *
>> - nothing -
>
> Uh, did you try grepping for "i2c"?
No, I've just read the whole file from time to time.
>> The configuration process is away from KISS - I would simply
>> state: it's broken - or - it's a regression from 2.6.22.
>
> The transition could have been done more smoothly if the i2c driver model
> allowed a driver to be both new-style and old-style at the same time
> (subject to a config option to shut off old-style if it's screwing things
> up), I'll agree with that much.
> But please, try to understand that the
> device tree really does help.
That was discussed already in detail in several threads and there
were already decisions made that the DT went into the kernel - no problem
with that.
I just don't see that it 'really does help' in it's current state if
things are broken in a way they are hard to fix for non DT-familiar
developers, almost impossible to fix for users which just need to
compile their own kernel to achieve their project goal.
Well... let's take it easy. I'll dig into the pcf8563 code now.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* [PATCH] lparcfg: remove useless buffer allocation
From: Nathan Lynch @ 2007-12-04 16:03 UTC (permalink / raw)
To: linuxppc-dev
The 'data' member of proc_ppc64_lparcfg is unused, but the lparcfg
module's init routine allocates 4K for it.
Remove the code which allocates and frees this buffer.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/lparcfg.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
Tested with "cat /proc/ppc64/lparcfg" on Power5.
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index ff781b2..dcb89a8 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -41,7 +41,6 @@
/* #define LPARCFG_DEBUG */
static struct proc_dir_entry *proc_ppc64_lparcfg;
-#define LPARCFG_BUFF_SIZE 4096
/*
* Track sum of all purrs across all processors. This is used to further
@@ -595,13 +594,6 @@ int __init lparcfg_init(void)
ent = create_proc_entry("ppc64/lparcfg", mode, NULL);
if (ent) {
ent->proc_fops = &lparcfg_fops;
- ent->data = kmalloc(LPARCFG_BUFF_SIZE, GFP_KERNEL);
- if (!ent->data) {
- printk(KERN_ERR
- "Failed to allocate buffer for lparcfg\n");
- remove_proc_entry("lparcfg", ent->parent);
- return -ENOMEM;
- }
} else {
printk(KERN_ERR "Failed to create ppc64/lparcfg\n");
return -EIO;
@@ -613,10 +605,8 @@ int __init lparcfg_init(void)
void __exit lparcfg_cleanup(void)
{
- if (proc_ppc64_lparcfg) {
- kfree(proc_ppc64_lparcfg->data);
+ if (proc_ppc64_lparcfg)
remove_proc_entry("lparcfg", proc_ppc64_lparcfg->parent);
- }
}
module_init(lparcfg_init);
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: Merge dtc
From: Kumar Gala @ 2007-12-04 16:04 UTC (permalink / raw)
To: Jon Loeliger, David Gibson
Cc: linuxppc-dev, Paul Mackerras, David Woodhouse, Paul
In-Reply-To: <20071204092611.79e08953@zod.rchland.ibm.com>
On Dec 4, 2007, at 9:26 AM, Josh Boyer wrote:
> On Tue, 04 Dec 2007 07:25:57 -0600
> Jon Loeliger <jdl@jdl.com> wrote:
>
>> So, like, the other day David Woodhouse mumbled:
>>>
>>> I think this is a bad idea -- it's hardly a difficult for those
>>> people
>>> who _do_ need dts to obtain it separately.
>>>
>>> We shouldn't be merging _more_ stuff in.
>>
>> Thanks for chiming in here, David W. As far as I can tell
>> so far, the only two people who have voiced an opinion on
>> this issue are Dave G, submitting patches, and me disagreeing
>> with the approach. :-)
>>
>> Anyone else?
>
> I don't see an overwhelmingly great reason to merge it. It might help
> test people who do automated rebuilds, etc and aren't used to dealing
> with powerpc and it's requirements. Outside of that, I see it as
> dual-maintenance.
>
> But I'm not doing the maintenance, and it doesn't effect me too much.
> I only ask that a decision is made and executed on soon so we can move
> on.
I'm also in disagreement of duplicating dtc in the kernel.
However, if we are going to do this we should make the path expansion
for labels work before we do it.
- k
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Scott Wood @ 2007-12-04 16:08 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <4755731D.4050106@anagramm.de>
Clemens Koller wrote:
> Scott Wood schrieb:
> >> I would prefer to not tell the driver for 'foo' that it should attach to
> >> 0-0068
> >> because it should attach to the first i2c bus (0) it finds per default.
> >
> > Absolutely wrong.
>
> Hmm... Why?
It's error prone.
> > What if foo is on bus 1?
>
> Then I would need to tell the driver 'foo' that it should attach
> to 1-0068.
So we're back to the situation where drivers that aren't explicitly told
where to look are making assumptions that are possibly incorrect. You
should be able to enable drivers without harm, even if the hardware
isn't there.
> Propably you should see the bigger picture here:
Pot, meet kettle. :-)
> We just need to tell what we have, if it's not some default...
> statically (kconfig) or dynamically (of/dt) to get it right
> because we cannot probe for sure what we have (in contrast to PCI).
>
> I just don't want to be pushed into configuring things twice or on
> two different places because that's error prone.
The new system is far less error prone than the old system. You seem to
be suggesting a third system, with a radically different kconfig format
and no multiplatform support (again, this was one of your complaints in
your original e-mail -- why do you ignore it now?). Please show us the
code, or at least some description of how you would change kconfig to
get it up to the task, and how you would handle multiplatform kernels.
> >> Then I would need to tell 'bar' to attach to 1-0068. Where is the
> problem?
> >
> > OK, now say there's another foo on bus 2, and a pair of bars on buses
> 3 and
> > 4?
>
> Okay, let's play that game:
> foo -> connect an instance to 0-0068 and 2-0068
> bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068
That doesn't resemble kconfig in the least -- and even if you transform
it into some sort of runtime-parsable textual list, what do those bus
numbers mean, anyway? How do you associate those with various i2c
buses, potentially coming from different i2c drivers? How do you
specify IRQs? How do you specify device variants among those the driver
supports? By the time you fix all of that, you'll basically have the
device tree.
The device tree provides a hierarchy that is well suited to handling
this sort of problem, and it also logically separates what the kernel
supports from what the hardware has (which is *necessary* for
multiplatform support).
> >> The 0068 is already redundant in the case of these RTCs because they
> are
> >> fixed.
> >
> > How do you know I'm even talking about RTCs?
>
> Well, the subject is about RTCs.
Not really, it's about a change in the i2c subsystem (I noticed you
didn't include the i2c list or linuxppc-dev... you'd get a larger
audience of the people that actually made the change that way). That it
happens to be an RTC chip you're using on the i2c bus is an
inconsequential detail.
> >> linux-2.6/Documentation/powerpc$ grep "rtc" *
> >> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant,
> >> btw.).
> >> which could give a clue what's going on here.
> >> linux-2.6/Documentation/powerpc$ grep "fsl_soc" *
> >> - nothing -
> >
> > Uh, did you try grepping for "i2c"?
>
> No, I've just read the whole file from time to time.
OK, it seems the description of i2c devices didn't make it into that
file. I'm not sure why.
> That was discussed already in detail in several threads and there
> were already decisions made that the DT went into the kernel - no problem
> with that.
> I just don't see that it 'really does help' in it's current state if
> things are broken in a way they are hard to fix for non DT-familiar
> developers, almost impossible to fix for users which just need to
> compile their own kernel to achieve their project goal.
I agree there's been excessive roughness in the transition -- but in
this case, it's largely due to the i2c subsystem change, whereby a
driver can't be new-style and old-style at the same time. Thus, once
the driver is converted, all platforms have to register the device. On
powerpc, we happen to do it using the device tree (though you could do
it with board-specific platform code the way other arches do if you
really wanted).
> Well... let's take it easy. I'll dig into the pcf8563 code now.
BTW, there were patches posted recently by Jon Smirl to convert that
driver to new-style, and to change the i2c subsystem to have the OF
matches in the driver itself.
-Scott
^ permalink raw reply
* [FDT][PATCH] Fix padding options
From: Kumar Gala @ 2007-12-04 16:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
commit 22e787ca2b1e49a9a0f3c43262564ab1038c5c3c broke the padding
support. We were updating the fdt header after writing it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
flattree.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/flattree.c b/flattree.c
index c860b63..eb9c82c 100644
--- a/flattree.c
+++ b/flattree.c
@@ -399,6 +399,12 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
if (padsize > 0)
padlen = padsize;
+ if (padlen > 0) {
+ int tsize = be32_to_cpu(fdt.totalsize);
+ tsize += padlen;
+ fdt.totalsize = cpu_to_be32(tsize);
+ }
+
/*
* Assemble the blob: start with the header, add with alignment
* the reserve buffer, add the reserve map terminating zeroes,
@@ -414,12 +420,8 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
/*
* If the user asked for more space than is used, pad out the blob.
*/
- if (padlen > 0) {
- int tsize = be32_to_cpu(fdt.totalsize);
- tsize += padlen;
+ if (padlen > 0)
blob = data_append_zeroes(blob, padlen);
- fdt.totalsize = cpu_to_be32(tsize);
- }
fwrite(blob.val, blob.len, 1, f);
--
1.5.3.4
^ permalink raw reply related
* [FDT][PATCH] Print out the total size as part of ftdump
From: Kumar Gala @ 2007-12-04 16:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
ftdump.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/ftdump.c b/ftdump.c
index 577c2cf..53343d7 100644
--- a/ftdump.c
+++ b/ftdump.c
@@ -87,6 +87,7 @@ static void dump_blob(void *blob)
char *p_struct = blob + be32_to_cpu(bph->off_dt_struct);
char *p_strings = blob + be32_to_cpu(bph->off_dt_strings);
uint32_t version = be32_to_cpu(bph->version);
+ uint32_t totalsize = be32_to_cpu(bph->totalsize);
uint32_t tag;
char *p;
char *s, *t;
@@ -98,6 +99,7 @@ static void dump_blob(void *blob)
shift = 4;
printf("// Version 0x%x tree\n", version);
+ printf("// Totalsize 0x%x(%d)\n", totalsize, totalsize);
for (i = 0; ; i++) {
addr = be64_to_cpu(p_rsvmap[i].address);
size = be64_to_cpu(p_rsvmap[i].size);
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH v2] Fix hardware IRQ time accounting problem.
From: Johannes Berg @ 2007-12-04 16:44 UTC (permalink / raw)
To: Tony Breeds
Cc: LinuxPPC-dev, Frederik Himpe, Paul Mackerras, Linux Kernel ML,
linux-usb-devel
In-Reply-To: <20071204055144.GR24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]
On Tue, 2007-12-04 at 16:51 +1100, Tony Breeds wrote:
> The commit fa13a5a1f25f671d084d8884be96fc48d9b68275 (sched: restore
> deterministic CPU accounting on powerpc), unconditionally calls
> update_process_tick() in system context. In the deterministic accounting case
> this is the correct thing to do. However, in the non-deterministic accounting
> case we need to not do this, and results in the time accounted as hardware irq
> time being artificially elevated.
Cool, I wouldn't have stood a chance of tracking this down :) Thanks,
I'll apply it to my testing tree later today.
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
> The problem was seen and reported by Johannes Berg and Frederik Himpe.
> Paul, I think this is good for 2.6.24.
>
> Changes since v1:
> - I noticed that the #define was explictly using "current" rather than
> the task passed in. Using tsk is the right thing to do.
> - The whiteapce changes dirty-up the patch and are un-needed with the
> change above.
>
> arch/powerpc/kernel/process.c | 2 +-
> include/asm-powerpc/time.h | 8 ++------
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 41e13f4..b9d8837 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -350,7 +350,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
> local_irq_save(flags);
>
> account_system_vtime(current);
> - account_process_tick(current, 0);
> + account_process_vtime(current);
> calculate_steal_time();
>
> last = _switch(old_thread, new_thread);
> diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
> index 780f826..a7281e0 100644
> --- a/include/asm-powerpc/time.h
> +++ b/include/asm-powerpc/time.h
> @@ -237,18 +237,14 @@ struct cpu_usage {
>
> DECLARE_PER_CPU(struct cpu_usage, cpu_usage_array);
>
> -#ifdef CONFIG_VIRT_CPU_ACCOUNTING
> -extern void account_process_vtime(struct task_struct *tsk);
> -#else
> -#define account_process_vtime(tsk) do { } while (0)
> -#endif
> -
> #if defined(CONFIG_VIRT_CPU_ACCOUNTING)
> extern void calculate_steal_time(void);
> extern void snapshot_timebases(void);
> +#define account_process_vtime(tsk) account_process_tick(tsk, 0);
> #else
> #define calculate_steal_time() do { } while (0)
> #define snapshot_timebases() do { } while (0)
> +#define account_process_vtime(tsk) do { } while (0)
> #endif
>
> extern void secondary_cpu_time_init(void);
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH v2 0/4] OF-platform PATA driver
From: Anton Vorontsov @ 2007-12-04 17:04 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Cc: Jeff Garzik, Arnd Bergmann, Paul Mundt, Olof Johansson
Hi all,
Here is the second version of the OF-platform PATA driver and
related patches.
Arnd, the first patch has been changed, so technically it lost your
Acked-by.
- - -
Changes since v1:
- __pata_platform_probe now accepts pio_mask argument;
- pata-platform compatible property renamed to ata-generic;
- pata_of_platform understands pio-mode property. It's used to pass
pio_mask to the __pata_platform_probe. That is, in ata-generic
context pio-mode means "pio mode the bus already configured for";
- New optional patch that renames pata_platform_info's
ioport_shift to reg_shift.
Changes since RFC:
- nuked drivers/ata/pata_platform.h;
- powerpc bits: proper localbus node added.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v2 1/4] [libata] pata_platform: make probe and remove functions device type neutral
From: Anton Vorontsov @ 2007-12-04 17:06 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Cc: Jeff Garzik, Arnd Bergmann, Paul Mundt, Olof Johansson
In-Reply-To: <20071204170442.GA10460@localhost.localdomain>
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits;
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/ata/pata_platform.c | 143 ++++++++++++++++++++++++-----------------
include/linux/pata_platform.h | 9 +++
2 files changed, 94 insertions(+), 58 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index ac03a90..d4cb231 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -93,14 +93,9 @@ static struct ata_port_operations pata_platform_port_ops = {
};
static void pata_platform_setup_port(struct ata_ioports *ioaddr,
- struct pata_platform_info *info)
+ unsigned int shift)
{
- unsigned int shift = 0;
-
/* Fixup the port shift for platforms that need it */
- if (info && info->ioport_shift)
- shift = info->ioport_shift;
-
ioaddr->data_addr = ioaddr->cmd_addr + (ATA_REG_DATA << shift);
ioaddr->error_addr = ioaddr->cmd_addr + (ATA_REG_ERR << shift);
ioaddr->feature_addr = ioaddr->cmd_addr + (ATA_REG_FEATURE << shift);
@@ -114,8 +109,12 @@ static void pata_platform_setup_port(struct ata_ioports *ioaddr,
}
/**
- * pata_platform_probe - attach a platform interface
- * @pdev: platform device
+ * __pata_platform_probe - attach a platform interface
+ * @dev: device
+ * @io_res: Resource representing I/O base
+ * @ctl_res: Resource representing CTL base
+ * @irq_res: Resource representing IRQ and its flags
+ * @ioport_shift: I/O port shift
*
* Register a platform bus IDE interface. Such interfaces are PIO and we
* assume do not support IRQ sharing.
@@ -135,42 +134,18 @@ static void pata_platform_setup_port(struct ata_ioports *ioaddr,
*
* If no IRQ resource is present, PIO polling mode is used instead.
*/
-static int __devinit pata_platform_probe(struct platform_device *pdev)
+int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift,
+ int __pio_mask)
{
- struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
- struct pata_platform_info *pp_info;
unsigned int mmio;
- int irq;
-
- /*
- * Simple resource validation ..
- */
- if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
- dev_err(&pdev->dev, "invalid number of resources\n");
- return -EINVAL;
- }
-
- /*
- * Get the I/O base first
- */
- io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (io_res == NULL) {
- io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(io_res == NULL))
- return -EINVAL;
- }
-
- /*
- * Then the CTL base
- */
- ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
- if (ctl_res == NULL) {
- ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (unlikely(ctl_res == NULL))
- return -EINVAL;
- }
+ int irq = 0;
+ int irq_flags = 0;
/*
* Check for MMIO
@@ -181,20 +156,21 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
/*
* And the IRQ
*/
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- irq = 0; /* no irq */
+ if (irq_res && irq_res->start > 0) {
+ irq = irq_res->start;
+ irq_flags = irq_res->flags;
+ }
/*
* Now that that's out of the way, wire up the port..
*/
- host = ata_host_alloc(&pdev->dev, 1);
+ host = ata_host_alloc(dev, 1);
if (!host)
return -ENOMEM;
ap = host->ports[0];
ap->ops = &pata_platform_port_ops;
- ap->pio_mask = pio_mask;
+ ap->pio_mask = __pio_mask;
ap->flags |= ATA_FLAG_SLAVE_POSS;
/*
@@ -209,25 +185,24 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
* Handle the MMIO case
*/
if (mmio) {
- ap->ioaddr.cmd_addr = devm_ioremap(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioremap(dev, io_res->start,
io_res->end - io_res->start + 1);
- ap->ioaddr.ctl_addr = devm_ioremap(&pdev->dev, ctl_res->start,
+ ap->ioaddr.ctl_addr = devm_ioremap(dev, ctl_res->start,
ctl_res->end - ctl_res->start + 1);
} else {
- ap->ioaddr.cmd_addr = devm_ioport_map(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioport_map(dev, io_res->start,
io_res->end - io_res->start + 1);
- ap->ioaddr.ctl_addr = devm_ioport_map(&pdev->dev, ctl_res->start,
+ ap->ioaddr.ctl_addr = devm_ioport_map(dev, ctl_res->start,
ctl_res->end - ctl_res->start + 1);
}
if (!ap->ioaddr.cmd_addr || !ap->ioaddr.ctl_addr) {
- dev_err(&pdev->dev, "failed to map IO/CTL base\n");
+ dev_err(dev, "failed to map IO/CTL base\n");
return -ENOMEM;
}
ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
- pp_info = pdev->dev.platform_data;
- pata_platform_setup_port(&ap->ioaddr, pp_info);
+ pata_platform_setup_port(&ap->ioaddr, ioport_shift);
ata_port_desc(ap, "%s cmd 0x%llx ctl 0x%llx", mmio ? "mmio" : "ioport",
(unsigned long long)io_res->start,
@@ -235,26 +210,78 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
/* activate */
return ata_host_activate(host, irq, irq ? ata_interrupt : NULL,
- pp_info ? pp_info->irq_flags : 0,
- &pata_platform_sht);
+ irq_flags, &pata_platform_sht);
}
+EXPORT_SYMBOL_GPL(__pata_platform_probe);
/**
- * pata_platform_remove - unplug a platform interface
- * @pdev: platform device
+ * __pata_platform_remove - unplug a platform interface
+ * @dev: device
*
* A platform bus ATA device has been unplugged. Perform the needed
* cleanup. Also called on module unload for any active devices.
*/
-static int __devexit pata_platform_remove(struct platform_device *pdev)
+int __devexit __pata_platform_remove(struct device *dev)
{
- struct device *dev = &pdev->dev;
struct ata_host *host = dev_get_drvdata(dev);
ata_host_detach(host);
return 0;
}
+EXPORT_SYMBOL_GPL(__pata_platform_remove);
+
+static int __devinit pata_platform_probe(struct platform_device *pdev)
+{
+ struct resource *io_res;
+ struct resource *ctl_res;
+ struct resource *irq_res;
+ struct pata_platform_info *pp_info = pdev->dev.platform_data;
+
+ /*
+ * Simple resource validation ..
+ */
+ if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
+ dev_err(&pdev->dev, "invalid number of resources\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Get the I/O base first
+ */
+ io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (io_res == NULL) {
+ io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (unlikely(io_res == NULL))
+ return -EINVAL;
+ }
+
+ /*
+ * Then the CTL base
+ */
+ ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
+ if (ctl_res == NULL) {
+ ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (unlikely(ctl_res == NULL))
+ return -EINVAL;
+ }
+
+ /*
+ * And the IRQ
+ */
+ irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (irq_res)
+ irq_res->flags = pp_info ? pp_info->irq_flags : 0;
+
+ return __pata_platform_probe(&pdev->dev, io_res, ctl_res, irq_res,
+ pp_info ? pp_info->ioport_shift : 0,
+ pio_mask);
+}
+
+static int __devexit pata_platform_remove(struct platform_device *pdev)
+{
+ return __pata_platform_remove(&pdev->dev);
+}
static struct platform_driver pata_platform_driver = {
.probe = pata_platform_probe,
diff --git a/include/linux/pata_platform.h b/include/linux/pata_platform.h
index 5799e8d..6a7a92d 100644
--- a/include/linux/pata_platform.h
+++ b/include/linux/pata_platform.h
@@ -15,4 +15,13 @@ struct pata_platform_info {
unsigned int irq_flags;
};
+extern int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift,
+ int __pio_mask);
+
+extern int __devexit __pata_platform_remove(struct device *dev);
+
#endif /* __LINUX_PATA_PLATFORM_H */
--
1.5.2.2
^ permalink raw reply related
* [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
From: Anton Vorontsov @ 2007-12-04 17:07 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Cc: Jeff Garzik, Arnd Bergmann, Paul Mundt, Olof Johansson
In-Reply-To: <20071204170442.GA10460@localhost.localdomain>
This driver nicely wraps around pata_platform library functions,
and provides OF platform bus bindings to the PATA devices.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/ata/Kconfig | 10 ++++
drivers/ata/Makefile | 1 +
drivers/ata/pata_of_platform.c | 102 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 113 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/pata_of_platform.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..5a492fa 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -614,6 +614,16 @@ config PATA_PLATFORM
If unsure, say N.
+config PATA_OF_PLATFORM
+ tristate "OpenFirmware platform device PATA support"
+ depends on PATA_PLATFORM && PPC_OF
+ help
+ This option enables support for generic directly connected ATA
+ devices commonly found on embedded systems with OpenFirmware
+ bindings.
+
+ If unsure, say N.
+
config PATA_ICSIDE
tristate "Acorn ICS PATA support"
depends on ARM && ARCH_ACORN
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b13feb2..ebcee64 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
obj-$(CONFIG_PATA_SCC) += pata_scc.o
obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o
obj-$(CONFIG_PATA_PLATFORM) += pata_platform.o
+obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o
obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
# Should be last but two libata driver
obj-$(CONFIG_PATA_ACPI) += pata_acpi.o
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
new file mode 100644
index 0000000..738f9e0
--- /dev/null
+++ b/drivers/ata/pata_of_platform.c
@@ -0,0 +1,102 @@
+/*
+ * OF-platform PATA driver
+ *
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/pata_platform.h>
+
+static int __devinit pata_of_platform_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct device_node *dn = ofdev->node;
+ struct resource io_res;
+ struct resource ctl_res;
+ struct resource irq_res;
+ unsigned int reg_shift = 0;
+ int pio_mode = 0;
+ int pio_mask;
+ const u32 *prop;
+
+ ret = of_address_to_resource(dn, 0, &io_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get IO address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_irq_to_resource(dn, 0, &irq_res);
+ if (ret == NO_IRQ)
+ irq_res.start = irq_res.end = -1;
+ else
+ irq_res.flags = 0;
+
+ prop = (u32 *)of_get_property(dn, "reg-shift", NULL);
+ if (prop)
+ reg_shift = *prop;
+
+ prop = (u32 *)of_get_property(dn, "pio-mode", NULL);
+ if (prop) {
+ pio_mode = *prop;
+ if (pio_mode > 6) {
+ dev_err(&ofdev->dev, "invalid pio-mode\n");
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&ofdev->dev, "pio-mode unspecified, assuming PIO0\n");
+ }
+
+ pio_mask = 1 << pio_mode;
+ pio_mask |= (1 << pio_mode) - 1;
+
+ return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, &irq_res,
+ reg_shift, pio_mask);
+}
+
+static int __devexit pata_of_platform_remove(struct of_device *ofdev)
+{
+ return __pata_platform_remove(&ofdev->dev);
+}
+
+static struct of_device_id pata_of_platform_match[] = {
+ { .compatible = "ata-generic", },
+};
+
+static struct of_platform_driver pata_of_platform_driver = {
+ .name = "pata_of_platform",
+ .match_table = pata_of_platform_match,
+ .probe = pata_of_platform_probe,
+ .remove = __devexit_p(pata_of_platform_remove),
+};
+
+static int __init pata_of_platform_init(void)
+{
+ return of_register_platform_driver(&pata_of_platform_driver);
+}
+module_init(pata_of_platform_init);
+
+static void __exit pata_of_platform_exit(void)
+{
+ of_unregister_platform_driver(&pata_of_platform_driver);
+}
+module_exit(pata_of_platform_exit);
+
+MODULE_DESCRIPTION("OF-platform PATA driver");
+MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
+MODULE_LICENSE("GPL");
--
1.5.2.2
^ permalink raw reply related
* [PATCH v2 3/4] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2007-12-04 17:07 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Cc: Jeff Garzik, Arnd Bergmann, Paul Mundt, Olof Johansson
In-Reply-To: <20071204170442.GA10460@localhost.localdomain>
This patch adds localbus and pata nodes to use CF IDE interface
on MPC8349E-mITX boards.
Patch also adds code to probe localbus.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 18 +++++++++++++++++-
arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +++++++++++++++++
2 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5072f6d..c459b0a 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -249,6 +249,22 @@
device_type = "pci";
};
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8349emitx-localbus",
+ "fsl,mpc8349e-localbus",
+ "fsl,pq2pro-localbus";
+ reg = <e0005000 d8>;
+ ranges = <3 0 f0000000 210>;
-
+ pata@3,0 {
+ compatible = "fsl,mpc8349emitx-pata", "ata-generic";
+ reg = <3 0 10 3 20c 4>;
+ reg-shift = <1>;
+ pio-mode = <6>;
+ interrupts = <17 8>;
+ interrupt-parent = <&ipic>;
+ };
+ };
};
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index aa76819..ea5f176 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -23,6 +23,7 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
+#include <linux/of_platform.h>
#include <asm/system.h>
#include <asm/atomic.h>
@@ -37,6 +38,22 @@
#include "mpc83xx.h"
+static struct of_device_id mpc834x_itx_ids[] = {
+ { .name = "localbus", },
+ {},
+};
+
+static int __init mpc834x_itx_declare_of_platform_devices(void)
+{
+ if (!machine_is(mpc834x_itx))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc834x_itx_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc834x_itx_declare_of_platform_devices);
+
/* ************************************************************************
*
* Setup the architecture
--
1.5.2.2
^ permalink raw reply related
* [PATCH v2 4/4] [libata] pata_platform: s/ioport_shift/reg_shift/g
From: Anton Vorontsov @ 2007-12-04 17:07 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Cc: Jeff Garzik, Arnd Bergmann, Paul Mundt, Olof Johansson
In-Reply-To: <20071204170442.GA10460@localhost.localdomain>
This patch renames ioport_shift member of pata_platform_info
structure to reg_shift. Users of pata_platform are followed
appropriately.
Rationale of that change is: shifting applies to the whole memory
mapped region, not only to the command block of the ATA registers,
despite the fact that shifting is meaningless for ctl register.
This patch should make Sergei Shtylyov a bit more happy. ;-)
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/arm/mach-rpc/riscpc.c | 2 +-
arch/blackfin/mach-bf527/boards/ezkit.c | 2 +-
arch/blackfin/mach-bf533/boards/cm_bf533.c | 2 +-
arch/blackfin/mach-bf533/boards/ezkit.c | 2 +-
arch/blackfin/mach-bf533/boards/stamp.c | 2 +-
arch/blackfin/mach-bf537/boards/cm_bf537.c | 2 +-
arch/blackfin/mach-bf537/boards/generic_board.c | 2 +-
arch/blackfin/mach-bf537/boards/stamp.c | 2 +-
arch/blackfin/mach-bf561/boards/cm_bf561.c | 2 +-
arch/blackfin/mach-bf561/boards/ezkit.c | 2 +-
arch/sh/boards/landisk/setup.c | 2 +-
arch/sh/boards/renesas/r7780rp/setup.c | 2 +-
arch/sh/boards/renesas/rts7751r2d/setup.c | 2 +-
drivers/ata/pata_platform.c | 8 ++++----
drivers/ide/legacy/ide_platform.c | 4 ++--
include/linux/pata_platform.h | 4 ++--
16 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-rpc/riscpc.c b/arch/arm/mach-rpc/riscpc.c
index a454451..be413c1 100644
--- a/arch/arm/mach-rpc/riscpc.c
+++ b/arch/arm/mach-rpc/riscpc.c
@@ -161,7 +161,7 @@ static struct platform_device serial_device = {
};
static struct pata_platform_info pata_platform_data = {
- .ioport_shift = 2,
+ .reg_shift = 2,
};
static struct resource pata_resources[] = {
diff --git a/arch/blackfin/mach-bf527/boards/ezkit.c b/arch/blackfin/mach-bf527/boards/ezkit.c
index 003e2ac..c9b20bd 100644
--- a/arch/blackfin/mach-bf527/boards/ezkit.c
+++ b/arch/blackfin/mach-bf527/boards/ezkit.c
@@ -685,7 +685,7 @@ static struct platform_device bfin_sport1_uart_device = {
#define PATA_INT 55
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 1,
+ .reg_shift = 1,
.irq_type = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/blackfin/mach-bf533/boards/cm_bf533.c b/arch/blackfin/mach-bf533/boards/cm_bf533.c
index 21df2f3..6cc697d 100644
--- a/arch/blackfin/mach-bf533/boards/cm_bf533.c
+++ b/arch/blackfin/mach-bf533/boards/cm_bf533.c
@@ -289,7 +289,7 @@ static struct platform_device isp1362_hcd_device = {
#define PATA_INT 38
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 2,
+ .reg_shift = 2,
.irq_type = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/blackfin/mach-bf533/boards/ezkit.c b/arch/blackfin/mach-bf533/boards/ezkit.c
index be85203..030dc64 100644
--- a/arch/blackfin/mach-bf533/boards/ezkit.c
+++ b/arch/blackfin/mach-bf533/boards/ezkit.c
@@ -223,7 +223,7 @@ static struct platform_device bfin_uart_device = {
#define PATA_INT 55
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 1,
+ .reg_shift = 1,
.irq_type = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/blackfin/mach-bf533/boards/stamp.c b/arch/blackfin/mach-bf533/boards/stamp.c
index 8fde8d8..6ff0b88 100644
--- a/arch/blackfin/mach-bf533/boards/stamp.c
+++ b/arch/blackfin/mach-bf533/boards/stamp.c
@@ -340,7 +340,7 @@ static struct platform_device bfin_sport1_uart_device = {
#define PATA_INT 55
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 1,
+ .reg_shift = 1,
.irq_type = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/blackfin/mach-bf537/boards/cm_bf537.c b/arch/blackfin/mach-bf537/boards/cm_bf537.c
index c0fb06d..031da0f 100644
--- a/arch/blackfin/mach-bf537/boards/cm_bf537.c
+++ b/arch/blackfin/mach-bf537/boards/cm_bf537.c
@@ -340,7 +340,7 @@ static struct platform_device bfin_mac_device = {
#define PATA_INT 64
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 2,
+ .reg_shift = 2,
.irq_type = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/blackfin/mach-bf537/boards/generic_board.c b/arch/blackfin/mach-bf537/boards/generic_board.c
index 09f4bfb..e217eb2 100644
--- a/arch/blackfin/mach-bf537/boards/generic_board.c
+++ b/arch/blackfin/mach-bf537/boards/generic_board.c
@@ -613,7 +613,7 @@ static struct platform_device bfin_sport1_uart_device = {
#define PATA_INT 55
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 1,
+ .reg_shift = 1,
.irq_type = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c b/arch/blackfin/mach-bf537/boards/stamp.c
index 07b0dc2..daeb0d5 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -640,7 +640,7 @@ static struct platform_device bfin_sport1_uart_device = {
#define PATA_INT 55
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 1,
+ .reg_shift = 1,
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/blackfin/mach-bf561/boards/cm_bf561.c b/arch/blackfin/mach-bf561/boards/cm_bf561.c
index c19cd29..5628e34 100644
--- a/arch/blackfin/mach-bf561/boards/cm_bf561.c
+++ b/arch/blackfin/mach-bf561/boards/cm_bf561.c
@@ -280,7 +280,7 @@ static struct platform_device bfin_uart_device = {
#define PATA_INT 119
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 2,
+ .reg_shift = 2,
.irq_type = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/blackfin/mach-bf561/boards/ezkit.c b/arch/blackfin/mach-bf561/boards/ezkit.c
index 4ff8f6e..6894472 100644
--- a/arch/blackfin/mach-bf561/boards/ezkit.c
+++ b/arch/blackfin/mach-bf561/boards/ezkit.c
@@ -213,7 +213,7 @@ static struct spi_board_info bfin_spi_board_info[] __initdata = {
#define PATA_INT 55
static struct pata_platform_info bfin_pata_platform_data = {
- .ioport_shift = 1,
+ .reg_shift = 1,
.irq_type = IRQF_TRIGGER_HIGH | IRQF_DISABLED,
};
diff --git a/arch/sh/boards/landisk/setup.c b/arch/sh/boards/landisk/setup.c
index eda7176..46330f7 100644
--- a/arch/sh/boards/landisk/setup.c
+++ b/arch/sh/boards/landisk/setup.c
@@ -31,7 +31,7 @@ static void landisk_power_off(void)
static struct resource cf_ide_resources[3];
static struct pata_platform_info pata_info = {
- .ioport_shift = 1,
+ .reg_shift = 1,
};
static struct platform_device cf_ide_device = {
diff --git a/arch/sh/boards/renesas/r7780rp/setup.c b/arch/sh/boards/renesas/r7780rp/setup.c
index 0fdc0bc..1fc9c9b 100644
--- a/arch/sh/boards/renesas/r7780rp/setup.c
+++ b/arch/sh/boards/renesas/r7780rp/setup.c
@@ -94,7 +94,7 @@ static struct resource cf_ide_resources[] = {
};
static struct pata_platform_info pata_info = {
- .ioport_shift = 1,
+ .reg_shift = 1,
};
static struct platform_device cf_ide_device = {
diff --git a/arch/sh/boards/renesas/rts7751r2d/setup.c b/arch/sh/boards/renesas/rts7751r2d/setup.c
index 8125d20..8bcca50 100644
--- a/arch/sh/boards/renesas/rts7751r2d/setup.c
+++ b/arch/sh/boards/renesas/rts7751r2d/setup.c
@@ -62,7 +62,7 @@ static struct resource cf_ide_resources[] = {
};
static struct pata_platform_info pata_info = {
- .ioport_shift = 1,
+ .reg_shift = 1,
};
static struct platform_device cf_ide_device = {
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index d4cb231..3e7d2eb 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -114,7 +114,7 @@ static void pata_platform_setup_port(struct ata_ioports *ioaddr,
* @io_res: Resource representing I/O base
* @ctl_res: Resource representing CTL base
* @irq_res: Resource representing IRQ and its flags
- * @ioport_shift: I/O port shift
+ * @reg_shift: I/O port shift
*
* Register a platform bus IDE interface. Such interfaces are PIO and we
* assume do not support IRQ sharing.
@@ -138,7 +138,7 @@ int __devinit __pata_platform_probe(struct device *dev,
struct resource *io_res,
struct resource *ctl_res,
struct resource *irq_res,
- unsigned int ioport_shift,
+ unsigned int reg_shift,
int __pio_mask)
{
struct ata_host *host;
@@ -202,7 +202,7 @@ int __devinit __pata_platform_probe(struct device *dev,
ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
- pata_platform_setup_port(&ap->ioaddr, ioport_shift);
+ pata_platform_setup_port(&ap->ioaddr, reg_shift);
ata_port_desc(ap, "%s cmd 0x%llx ctl 0x%llx", mmio ? "mmio" : "ioport",
(unsigned long long)io_res->start,
@@ -274,7 +274,7 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
irq_res->flags = pp_info ? pp_info->irq_flags : 0;
return __pata_platform_probe(&pdev->dev, io_res, ctl_res, irq_res,
- pp_info ? pp_info->ioport_shift : 0,
+ pp_info ? pp_info->reg_shift : 0,
pio_mask);
}
diff --git a/drivers/ide/legacy/ide_platform.c b/drivers/ide/legacy/ide_platform.c
index 7bb79f5..3cee1b2 100644
--- a/drivers/ide/legacy/ide_platform.c
+++ b/drivers/ide/legacy/ide_platform.c
@@ -41,9 +41,9 @@ static ide_hwif_t *__devinit plat_ide_locate_hwif(void __iomem *base,
hwif->io_ports[IDE_DATA_OFFSET] = port;
- port += (1 << pdata->ioport_shift);
+ port += (1 << pdata->reg_shift);
for (i = IDE_ERROR_OFFSET; i <= IDE_STATUS_OFFSET;
- i++, port += (1 << pdata->ioport_shift))
+ i++, port += (1 << pdata->reg_shift))
hwif->io_ports[i] = port;
hwif->io_ports[IDE_CONTROL_OFFSET] = (unsigned long)ctrl;
diff --git a/include/linux/pata_platform.h b/include/linux/pata_platform.h
index 6a7a92d..a0fc6b0 100644
--- a/include/linux/pata_platform.h
+++ b/include/linux/pata_platform.h
@@ -7,7 +7,7 @@ struct pata_platform_info {
* constantly spaced and need larger than the 1-byte
* spacing used by ata_std_ports().
*/
- unsigned int ioport_shift;
+ unsigned int reg_shift;
/*
* Indicate platform specific irq types and initial
* IRQ flags when call request_irq()
@@ -19,7 +19,7 @@ extern int __devinit __pata_platform_probe(struct device *dev,
struct resource *io_res,
struct resource *ctl_res,
struct resource *irq_res,
- unsigned int ioport_shift,
+ unsigned int reg_shift,
int __pio_mask);
extern int __devexit __pata_platform_remove(struct device *dev);
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH v2 4/4] [libata] pata_platform: s/ioport_shift/reg_shift/g
From: Sergei Shtylyov @ 2007-12-04 17:08 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Jeff Garzik, Arnd Bergmann, linux-ide, linuxppc-dev, Paul Mundt,
Olof Johansson
In-Reply-To: <20071204170745.GD15599@localhost.localdomain>
Hello.
Anton Vorontsov wrote:
> This patch renames ioport_shift member of pata_platform_info
> structure to reg_shift. Users of pata_platform are followed
> appropriately.
> Rationale of that change is: shifting applies to the whole memory
> mapped region, not only to the command block of the ATA registers,
> despite the fact that shifting is meaningless for ctl register.
> This patch should make Sergei Shtylyov a bit more happy. ;-)
In fact, I don't care about how platform driver calls this stuff. ;-)
I only care about the property name.
MBR, Sergei
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Jon Smirl @ 2007-12-04 17:19 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <4755731D.4050106@anagramm.de>
On 12/4/07, Clemens Koller <clemens.koller@anagramm.de> wrote:
> That was discussed already in detail in several threads and there
> were already decisions made that the DT went into the kernel - no problem
> with that.
> I just don't see that it 'really does help' in it's current state if
> things are broken in a way they are hard to fix for non DT-familiar
> developers, almost impossible to fix for users which just need to
> compile their own kernel to achieve their project goal.
>
> Well... let's take it easy. I'll dig into the pcf8563 code now.
Most of this is addressed in the patch series starting with this message:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/047382.html
The pcf8563 driver is converted to the new format and is modified to
pick up it's address from the device tree.
This patch series is being held waiting for an ok on the low level
changes to the i2c subsystem. Hopefully it will go into 2.6.25
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Merge dtc
From: David Woodhouse @ 2007-12-04 17:22 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071204031027.GJ32577@localhost.localdomain>
On Tue, 2007-12-04 at 14:10 +1100, David Gibson wrote:
> We've been back and forth on this several times, Paul and I finally
> concluded this was the better option.
As long as I can just ignore it and use the separately-shipped dtc, I
suppose it doesn't have to bother me too much.
> It means we can feel free to use dtc for whatever new platforms we
> wish to without people whinging about having to install a new tool.
I think we're overestimating this 'problem'; really.
But anyway, if we have to go ahead with it, can we make sure we keep in
sync with the 'real' dtc? One way of doing that is as follows...
It's not hard to make a git repository which is a simple 'transform' of
another tree -- I have a couple, at
http://git.infradead.org/?p=users/dwmw2/jffs2-ecos-core.git and
http://git.kernel.org/?p=linux/kernel/git/dwmw2/kernel-headers.git
The scripts to generate those are at
http://david.woodhou.se/extract-jffs2-git.sh
http://david.woodhou.se/extract-khdrs-git.sh
http://david.woodhou.se/extract-khdrs-stage2.sh
(The kernel headers one is in two stages because it has to mangle the
files through unifdef too).
I'm sure there are better ways of doing it, but the scripts I have work,
and should hopefully serve as a vaguely useful example.
I'd recommend making such a 'transform' which tracks the upstream dtc
tree but with the files you want moved into the correct places. Then all
we have to do to update the kernel's copy is pull from that transformed
tree.
Of course, it's possible that git has matured to the point where it can
handle the 'renames' and you can just pull from the upstream dtc
repository directly. I don't think that's the case though.
--
dwmw2
^ permalink raw reply
* Re: Merge dtc
From: Scott Wood @ 2007-12-04 16:08 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Woodhouse, Paul Mackerras, David Gibson
In-Reply-To: <E1IzXmf-0005RJ-27@jdl.com>
On Tue, Dec 04, 2007 at 07:25:57AM -0600, Jon Loeliger wrote:
> So, like, the other day David Woodhouse mumbled:
> >
> > I think this is a bad idea -- it's hardly a difficult for those people
> > who _do_ need dts to obtain it separately.
> >
> > We shouldn't be merging _more_ stuff in.
>
> Thanks for chiming in here, David W. As far as I can tell
> so far, the only two people who have voiced an opinion on
> this issue are Dave G, submitting patches, and me disagreeing
> with the approach. :-)
>
> Anyone else?
I vote for keeping it separate.
-Scott
^ 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