* Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
From: Bartlomiej Zolnierkiewicz @ 2007-07-26 19:28 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070725165318.5331.23795.stgit@localhost.localdomain>
Hi,
On Wednesday 25 July 2007, Vitaly Bordug wrote:
>
> This is now very similar to pata_platform.c, they both use
> same platform data structure and same resources.
>
> To achieve that, byte_lanes_swapping platform data variable
> and platform specified iops removed from that driver. It's fine,
> since those were never used anyway.
>
> pata_platform and ide_platform are carrying same driver names,
> to easily switch between these drivers, without need to touch
> platform code.
Looks really good, thanks for working on this.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
applied but it would be also nice to fix minor issues found by Sergei
(please just send a new version of the patch and I will replace this
version with the newer one in my tree)
patch #2/2 also looks fine and when issues raised by Sergei gets
addressed it will be merged
Thanks,
Bart
^ permalink raw reply
* Re: Circular queue
From: David Hawkins @ 2007-07-26 19:55 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <46A5B5BA.2080707@dlasys.net>
David H. Lynch Jr. wrote:
> Is there a standard linux datastructure and routines to manage
> circular queues ?
>
> I have a device that is not fundimentally different from a serial
> character device
> except it is faster and the fundimental data type is 36 bits large.
>
> I have coded my own routines to setup and maintain a simple circular
> queue,
> but I was hoping that there might be something more standard that
> already exists.
>
> Anyone know of anything ?
Hi David,
Have you looked at the linked-list support? You can use it
for a circular queue.
I just copied the following comments from some driver examples
I wrote a while back:
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf
simple_page_buffer.c
*-----------------------------------------------------------------
* References:
* [1] "Linux device drivers", 3rd Ed, J. Corbet, A. Rubini,
* G. Kroah-Hartman, 2005
* [2] "Linux kernel development", 2nd Ed., R. Love.
*-----------------------------------------------------------------
*/
* For details on linked-lists, see p295 [1] and p345 [2].
I didn't look at the code again, but I'm pretty sure I used the
linked list for a circular buffer.
Cheers
Dave
^ permalink raw reply
* Re: help with ppc sections?
From: Grant Likely @ 2007-07-26 19:55 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <46A8F22E.6010701@nortel.com>
On 7/26/07, Chris Friesen <cfriesen@nortel.com> wrote:
>
> Hi all,
>
> I'm porting kprobes to 2.6.14, and I think I've got it mostly done. The
> last thing that I want to do is to mark flush_icache_range() as part of
> the .kprobes.text section so that we don't accidently try to probe it.
Hey Chris,
Mild question; What the *@*#^$! are you doing trying to backport to a
2 year old kernel?!? :-)
>
> On ppc64 this was done by duplicating the _GLOBAL macro and just
> modifying the ".section" line.
>
> Unfortunately for me, ppc doesn't have a ".section" line in that macro,
> so I'm at a bit of a loss.
Just add the section. Should be trivial to do. You might have to add
it to the linker script as well.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Reboot Command Makes kernel to hang (MPC8560)
From: Kumar Gala @ 2007-07-26 19:51 UTC (permalink / raw)
To: Ansari; +Cc: linuxppc-embedded
In-Reply-To: <000801c7cf51$f98ebb90$9503a8c0@Ansari>
On Jul 26, 2007, at 1:55 AM, Ansari wrote:
> Hi all,
>
> Processor (MPC8560)
>
> Whenever reboot command is given in the linux console. The
> processor gets reset and it loads bootloader , kernel and when
> uncompressing the ramdisk it gets hang. The sample log is given
> below. Any u please tell me what are the factors that can makes
> this to happen.
This is very board dependant. The MPC8560 doesn't have a clean way
to request reset, and odds are you're only getting the core reset and
not the full chip.
- k
^ permalink raw reply
* Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
From: Sergei Shtylyov @ 2007-07-26 19:52 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-kernel, Alan Cox, linux-ide
In-Reply-To: <Pine.LNX.4.60.0707262136530.6614@poirot.grange>
Hello.
Guennadi Liakhovetski wrote:
>>>driver to using platform-device. I got a reply, that it's not worth it now
>>>that IDE is slowly becoming obsolete, and the pata_platform serves the
>>>perpose perfectly well. I found this argument reasonable, I had the same
>>>doubt, just wanted to double-check. So, why do we now need a new legacy
>>>(a/drivers/ide/legacy/ide_platform.c) driver when a "modern" driver
>>>exists?
>>We don't *need* it but some people still want to use old IDE and the
>>author was willing to make it neatly compatible so that anything that
>>works with the pata_platform should be able to use the ide_platform
>>driver and vice versa. For the shorter term that can only be a good thing
>>- arch code doesn't need to care about which driver is used, end users
>>can pick and it doesn't end up adding new ties between code and old IDE.
> Ok, thanks for the explanation Alan. So, there's no technical argument,
> just "being nice to the users", and add a new driver, which we know we'll
> have to remove soon, thus having to persuade its users, who by that time
Define "soon". :-)
> will get used to it and will not want to invest money into switching to
> another one...
Invest into what if the drivers are functionally identical?
> Thanks
> Guennadi
MBR, Sergei
^ permalink raw reply
* dlopen source
From: Siva Prasad @ 2007-07-26 19:47 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 122 bytes --]
Hi,
Can some one point to where I can find the source code for dlopen()
function.
Thanks
Siva
[-- Attachment #2: Type: text/html, Size: 1961 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
From: Guennadi Liakhovetski @ 2007-07-26 19:41 UTC (permalink / raw)
To: Alan Cox; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <20070725213925.2f25906c@the-village.bc.nu>
On Wed, 25 Jul 2007, Alan Cox wrote:
> > driver to using platform-device. I got a reply, that it's not worth it now
> > that IDE is slowly becoming obsolete, and the pata_platform serves the
> > perpose perfectly well. I found this argument reasonable, I had the same
> > doubt, just wanted to double-check. So, why do we now need a new legacy
> > (a/drivers/ide/legacy/ide_platform.c) driver when a "modern" driver
> > exists?
>
> We don't *need* it but some people still want to use old IDE and the
> author was willing to make it neatly compatible so that anything that
> works with the pata_platform should be able to use the ide_platform
> driver and vice versa. For the shorter term that can only be a good thing
> - arch code doesn't need to care about which driver is used, end users
> can pick and it doesn't end up adding new ties between code and old IDE.
Ok, thanks for the explanation Alan. So, there's no technical argument,
just "being nice to the users", and add a new driver, which we know we'll
have to remove soon, thus having to persuade its users, who by that time
will get used to it and will not want to invest money into switching to
another one...
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* RE: [RFC][PATCH] MPC832x_RDB: update dts to use spi, registermmc_spi stub
From: Joakim Tjernlund @ 2007-07-26 19:40 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726154747.GA6930@localhost.localdomain>
> -----Original Message-----
> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]
> Sent: den 26 juli 2007 17:48
> To: Joakim Tjernlund
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi,
> registermmc_spi stub
>
> On Thu, Jul 26, 2007 at 05:36:06PM +0200, Joakim Tjernlund wrote:
> [...]
> > > spi@4c0 {
> > > device_type = "spi";
> > > + device-id = <1>;
> > > compatible = "fsl_spi";
> > > reg = <4c0 40>;
> > > interrupts = <2>;
> > > interrupt-parent = <&qeic>;
> > > - mode = "cpu";
> > > + mode = "qe";
> >
> > The driver is still using "cpu" mode. It just happens that
> the cpu mode for QE
> > enabled CPUs isn't 100% compatible with the defacto cpu
> mode used by other CPU:s.
>
> Yup, indeed.
>
> > So mode should probably be "cpu_qe" or, even better, if the
> drver could
>
> That's easy to change, thanks.
>
> > autodetect that it is running on a QE enabled CPU and
> adjust accordinly.
> > Maybe the Freescale guys have some ideas how to do that.
>
> Ok. Well, for now could we use machine_is() for kind of autodetect?
> Or it's better leave it as is, and just rename mode to cpu_qe?
Unless the DTS guys thinks otherwise, just rename to "cpu_qe".
"qe" would then be reserved for true QE mode.
Jocke
^ permalink raw reply
* Re: [PATCH] [POWERPC] iSeries: fix section mismatch warnings
From: Will Schmidt @ 2007-07-26 19:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20070726115601.7733fb96.sfr@canb.auug.org.au>
On Thu, 2007-07-26 at 11:56 +1000, Stephen Rothwell wrote:
> Hi Will,
>
> On Wed, 25 Jul 2007 11:55:31 -0500 Will Schmidt <will_schmidt@vnet.ibm.com> wrote:
> >
> > > cmpwi 0,r24,0 /* Are we processor 0? */
> > > - beq .__start_initialization_iSeries /* Start up the first processor */
> > > - mfspr r4,SPRN_CTRLF
> > > + bne 1f
> > > + b .__start_initialization_iSeries /* Start up the first processor */
> > > +1: mfspr r4,SPRN_CTRLF
> > > li r5,CTRL_RUNLATCH /* Turn off the run light */
> >
> > This part isnt clicking for me..
> > How does changing a "beq" to a "bne" over a "b" fit into changing
> > __start_initialization_iSeries static?
>
> Because I moved __start_initialization_iSeries into another section, it
> ends up too far away for a conditional branch so something adds a jump
> table to the .text section and changes this branch to be via that table.
> Unfortunately, the jump table ends up at the start of the .text and ruins
> our carefully laid out kernel image. By inverting the test I can turn
> the branch into an unconditional one which has a larger possible offse
> (effectively building the jump table manually).
Gotcha, thanks for the clarification. :-)
-Will
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* help with ppc sections?
From: Chris Friesen @ 2007-07-26 19:12 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm porting kprobes to 2.6.14, and I think I've got it mostly done. The
last thing that I want to do is to mark flush_icache_range() as part of
the .kprobes.text section so that we don't accidently try to probe it.
On ppc64 this was done by duplicating the _GLOBAL macro and just
modifying the ".section" line.
Unfortunately for me, ppc doesn't have a ".section" line in that macro,
so I'm at a bit of a loss.
Anyone got any suggestions, or pointers on where I could read up on it?
Chris
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Sergei Shtylyov @ 2007-07-26 17:45 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070726212118.7fe7abd3@localhost.localdomain>
Hello.
Vitaly Bordug wrote:
>>> I acn undertand your complaint in the context of an OF driver
>>>(which we don't have yet) but "mmio-ide" just means nothing to the
>>>current driver, and it doesn't convery enough info on the
>>>programming interface for the conceivable OF driver, it also does
>>>need to know at least "reg-stride" (and maybe "reg-size" in case
>>>only 16/32-bit accesses can be used). Well, if such driver will be
>>>written, I/O mapping support will probably be dropped from it, so
>>>indeed, calling it mmio-ide.c would make sense. But that can be
>>>added when this driver is done, and for now
>>I don't think the details of what Linux code currently exists should
>>drive the device tree binding. That the current patches use
>>platform_device glue code is an implementation detail (and one I'd
>>rather see go away, in favor of a driver that supports both
>>platform_device and of_device).
>>>I'd really prefer the board name to appear in the "compatible" prop
>>>(to which "mmio-ide" can be appended)...
>>Sure, that's always good... it was the "instead" that I objected to.
> Hmmm. So what is finally suggested devicetree node for this beast - can somebody refine?
> I am a little bit confused about decided device_type
My understanding is that "ata" has been already used, so there's no sense
in introducing "ide". Anyway, Segher will just say that "device_type" shoudn't
matter and even be present. ;-)
> and compatible fields...
In my understanding, as "mmio-ide" currectly makes no sense, it shouldn't
even appear there. And since "mpc8349emitx-cf" (or whatever would be most
generic name for those boards with the same type of CF IDE mapping) should be
imply the shift value, this property should also be optional, i.e. passing
hard coded value with platform_device would do.
MBR, Sergei
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Scott Wood @ 2007-07-26 17:37 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070726210507.18829b9a@vitb.ru.mvista.com>
Vitaly Bordug wrote:
> On Thu, 26 Jul 2007 11:45:08 -0500
> Scott Wood <scottwood@freescale.com> wrote:
>>Why not make the fsl spi driver an of_platform device?
>
> Because this particular thing is not ppc-only from what I recall.
spi_mpc83xx.c isn't ppc-only?
Even if it weren't, the OF stuff has been moved out of arch, so a
non-arch-specific driver can support both platform and of_platform
devices directly.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Vitaly Bordug @ 2007-07-26 17:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <46A79AA1.3030608@freescale.com>
On Wed, 25 Jul 2007 13:46:57 -0500
Scott Wood wrote:
> Sergei Shtylyov wrote:
> > I acn undertand your complaint in the context of an OF driver
> > (which we don't have yet) but "mmio-ide" just means nothing to the
> > current driver, and it doesn't convery enough info on the
> > programming interface for the conceivable OF driver, it also does
> > need to know at least "reg-stride" (and maybe "reg-size" in case
> > only 16/32-bit accesses can be used). Well, if such driver will be
> > written, I/O mapping support will probably be dropped from it, so
> > indeed, calling it mmio-ide.c would make sense. But that can be
> > added when this driver is done, and for now
>
> I don't think the details of what Linux code currently exists should
> drive the device tree binding. That the current patches use
> platform_device glue code is an implementation detail (and one I'd
> rather see go away, in favor of a driver that supports both
> platform_device and of_device).
>
> > I'd really prefer the board name to appear in the "compatible" prop
> > (to which "mmio-ide" can be appended)...
>
> Sure, that's always good... it was the "instead" that I objected to.
>
Hmmm. So what is finally suggested devicetree node for this beast - can somebody refine?
I am a little bit confused about decided device_type and compatible fields...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Vitaly Bordug @ 2007-07-26 17:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070726164508.GB28491@ld0162-tx32.am.freescale.net>
On Thu, 26 Jul 2007 11:45:08 -0500
Scott Wood <scottwood@freescale.com> wrote:
> On Thu, Jul 26, 2007 at 05:56:55PM +0400, Anton Vorontsov wrote:
> > +void (*fsl_spi_activate_cs)(u8 cs, u8 polarity) = NULL;
> > +EXPORT_SYMBOL(fsl_spi_activate_cs);
> > +void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity) = NULL;
> > +EXPORT_SYMBOL(fsl_spi_deactivate_cs);
>
> What are these for? It looks like you're using them to set pins,
> but that should be done in the firmware (and if the firmware sucks, then
> do it in the platform code at bootup).
>
That is not exactly the point.
I won't respond for Anton, but we already had such hooks justified in SPI case iirc.
> > +static int __init fsl_spi_of_init(void)
> > +{
> > + struct device_node *np;
> > + unsigned int i;
> > +
> > + for (np = NULL, i = 1;
> > + (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
> > + i++) {
>
> s/fsl_spi/fsl,mpc8323-spi/, please.
>
> Why not make the fsl spi driver an of_platform device?
>
Because this particular thing is not ppc-only from what I recall.
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Vitaly Bordug @ 2007-07-26 17:12 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <46A78322.3080607@ru.mvista.com>
On Wed, 25 Jul 2007 21:06:42 +0400
Sergei Shtylyov wrote:
> Hello.
>
> Vitaly Bordug wrote:
>
> > This updates relevant platform code (freescale mpc8349itx target)
> > to make the CompactFlash work in TrueIDE mode.
>
> Erm, I'm not sure it's worth submitting the platform device driver
> for PowerPC at this point, but well...
>
As Ben already confirmed, it is OK to have "constructor" insert platform device if such is
required by design.
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
>
> > arch/powerpc/boot/dts/mpc8349emitx.dts | 9 ++++
> > arch/powerpc/platforms/83xx/mpc834x_itx.c | 70
> > +++++++++++++++++++++++++++++ 2 files changed, 79 insertions(+), 0
> > deletions(-)
>
> > diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
> > b/arch/powerpc/boot/dts/mpc8349emitx.dts index db0d003..f8f0e8a
> > 100644 --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> > +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> > @@ -37,6 +37,15 @@
> > reg = <00000000 10000000>;
> > };
> >
> > + ide@f0000000 {
> > + compatible = "mmio-ide";
> > + device_type = "ide";
>
> Why not "ata"?
>
we already argued around this iirc. I have no preferences and will put whatever agreed appropriate finally in here.
> > + reg = <f0000000 10 f000020c 4>;
> > + ioport_shift = <1>;
>
> Please use hyphen, not underscore in the property names
> ("device_type" seems an only exception from this rule).
> And since using shift instead of size buys you nothing is this
> case, I'd prefer this property to be called reg-size or reg-stride.
>
> [...]
> > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > b/arch/powerpc/platforms/83xx/mpc834x_itx.c index 40a0194..d63a104
> > 100644 --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> [...]
> > @@ -43,6 +44,75 @@ unsigned long isa_io_base = 0;
> > unsigned long isa_mem_base = 0;
> > #endif
> >
> > +static int __init mmio_ide_of_init(void)
> > +{
> > + struct device_node *np;
> > + unsigned int i;
> > +
> > + for (np = NULL, i = 0;
> > + (np = of_find_compatible_node(np, "ide",
> > "mmio-ide")) != NULL;
> > + i++) {
> > + int ret = 0;
>
> Unneeded initialization.
>
> > + struct resource res[3];
> > + struct platform_device *pdev = NULL;
>
> Another one.
>
ok
> > + static struct pata_platform_info pdata;
> > +
> > + memset(res, 0, sizeof(res));
> > +
> > + ret = of_address_to_resource(np, 0, &res[0]);
> > + if (ret) {
> > + printk(KERN_ERR "mmio-ide.%d: unable to
> > get "
> > + "resource from OF\n", i);
> > + goto err0;
> > + }
> > +
> > + ret = of_address_to_resource(np, 1, &res[1]);
> > + if (ret) {
> > + printk(KERN_ERR "mmio-ide.%d: unable to
> > get "
> > + "resource from OF\n", i);
> > + goto err0;
>
> Erm, these printk's are repetitive, isn't it better to put them
> under err0 label?
>
> > + }
> > +
> > + res[2].start = res[2].end =
> > irq_of_parse_and_map(np, 0);
> > + if (res[2].start == NO_IRQ) {
> > + printk(KERN_ERR "mmio-ide.%d: no IRQ\n",
> > i);
> > + goto err0;
> > + }
> > + res[2].name = "pata_platform";
> > + res[2].flags = IORESOURCE_IRQ;
> > +
> > + pdata.ioport_shift = *((u32 *)of_get_property(np,
> > + "ioport_shift", NULL));
> > +
> > + pdev = platform_device_alloc("pata_platform", i);
> > + if (!pdev)
> > + goto err1;
>
> Hm, not err0?
>
agreed.
> > +
> > + ret = platform_device_add_data(pdev, &pdata,
> > sizeof(pdata));
> > + if (ret)
> > + goto err1;
> > +
> > + ret = platform_device_add_resources(pdev, res,
> > ARRAY_SIZE(res));
> > + if (ret)
> > + goto err1;
> > +
> > + ret = platform_device_register(pdev);
> > + if (ret)
> > + goto err1;
> > +
> > + continue;
> > +err1:
> > + printk(KERN_ERR "mmio-ide.%d: registration
> > failed\n", i);
> > + platform_device_del(pdev); /* it will free
> > everything */ +err0:
> > + /* Even if some device failed, try others */
> > + continue;
> > + }
> > +
> > + return 0;
> > +}
> > +device_initcall(mmio_ide_of_init);
> > +
> > /*
> > ************************************************************************
> > *
> > * Setup the architecture
>
> MBR, Sergei
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] mpc832x_rdb.c: prevent using uninitialized variable
From: Scott Wood @ 2007-07-26 16:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726140139.GA5709@localhost.localdomain>
On Thu, Jul 26, 2007 at 06:01:39PM +0400, Anton Vorontsov wrote:
> If CONFIG_PCI undefined, np will be used uninitialized, thereby
> find_node_by_name(np, "par_io") will fail.
This is the wrong fix -- you should be passing NULL to the par_io call
rather than np. Otherwise, if the par_io is earlier in the tree than the
pci, you won't find it.
-Scott
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Scott Wood @ 2007-07-26 16:45 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726135655.GA5643@localhost.localdomain>
On Thu, Jul 26, 2007 at 05:56:55PM +0400, Anton Vorontsov wrote:
> +void (*fsl_spi_activate_cs)(u8 cs, u8 polarity) = NULL;
> +EXPORT_SYMBOL(fsl_spi_activate_cs);
> +void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity) = NULL;
> +EXPORT_SYMBOL(fsl_spi_deactivate_cs);
What are these for? It looks like you're using them to set pins,
but that should be done in the firmware (and if the firmware sucks, then
do it in the platform code at bootup).
> +static int __init fsl_spi_of_init(void)
> +{
> + struct device_node *np;
> + unsigned int i;
> +
> + for (np = NULL, i = 1;
> + (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
> + i++) {
s/fsl_spi/fsl,mpc8323-spi/, please.
Why not make the fsl spi driver an of_platform device?
-Scott
^ permalink raw reply
* [PATCH] make powerpc BUG_ON() OK with pointers and bitwise
From: Al Viro @ 2007-07-26 16:35 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
Since powerpc insists on printing the _value_ of condition
and on casting it to long... At least let's make it a force-cast.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
include/asm-powerpc/bug.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/bug.h b/include/asm-powerpc/bug.h
index f6fa394..a248b8b 100644
--- a/include/asm-powerpc/bug.h
+++ b/include/asm-powerpc/bug.h
@@ -79,7 +79,7 @@
_EMIT_BUG_ENTRY \
: : "i" (__FILE__), "i" (__LINE__), "i" (0), \
"i" (sizeof(struct bug_entry)), \
- "r" ((long)(x))); \
+ "r" ((__force long)(x))); \
} \
} while (0)
--
1.5.3.GIT
^ permalink raw reply related
* Re: Gdbserver syscall clobber
From: Bill Gatliff @ 2007-07-26 16:28 UTC (permalink / raw)
To: Bill Gatliff, gdb, linuxppc-embedded
In-Reply-To: <20070723161512.GA3235@caradoc.them.org>
Daniel Jacobowitz wrote:
> Look around do_signal:
>
> regs->nip -= 4; /* Back up & retry system call */
>
> If your kernel has corrupted the register containing the syscall
> number at this point, that would explain your problem. It will then
> do the wrong syscall. I guess PPC only backs up one instruction.
>
>
Found the code in do_signal, right where you said it would be. I threw
in a printk or two to see what's up when an ERESTARTSYS is detected, and
started getting OOPSes all over the place. Apparently that's not a good
place for printk. :)
Before I go on, can anyone confirm that gdbserver and/or strace _ever_
worked with circa 2.4.16 PPC kernels?
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Sergei Shtylyov @ 2007-07-26 16:24 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <46A7A4EC.2020503@ru.mvista.com>
Hello, I wrote:
>>>>> Also, what mmio-ide in the compat properly means in the context
>>>>>of ide_platform which is able to handle both port and memory mapped
>>>>>IDE.
>>>>I/O-space is only valid in the context of PCI, ISA, or similar buses,
>>>>and
>>>>the bus-specific reg format indicates whether it's mmio-space or
>>>>io-space.
>>> You could save time on lecturing me (and use it to look on the
>>>driver ;-).
>>Sorry, I misread the question as being a mismatch between the
>>capabilities of the device binding and the driver, not about the
>>specific compatible name.
> That too. :-)
>>Something like "generic-ide" would probably be better.
> I strongly disagree with "generic" part. The generic IDE could only be
> said of 1:1 I/O mapped IDE ports, not about this fancy mapping.
BTW, there's already something called drivers/ide/ide-generic.c... :-)
MBR, Sergei
^ permalink raw reply
* Re: Fwd: [PATCH] bootwrapper: adds cuboot for MPC7448HPC2 platform
From: Scott Wood @ 2007-07-26 16:04 UTC (permalink / raw)
To: Kumar Gala, Zang Roy-r61911, linuxppc-dev
In-Reply-To: <20070726065902.GD1149@localhost.localdomain>
On Thu, Jul 26, 2007 at 04:59:02PM +1000, David Gibson wrote:
> > >+#define TARGET_HAS_ENET1
> > >+#include "ppcboot.h"
>
> Including ppcboot.h without first defining TARGET_* defines which give
> the type of system seems... fragile at best, broken at worst. Surely
> this can only work by accident.
What target do you suggest he define? There happen to be none in
ppcboot.h that are appropriate, because there are no special fields for
this target (other than eth1).
And yes, it's fragile -- the entire bd_t mechanism is fragile. In the
absence of a time machine, there's not much we can do about it other than
encourage people to upgrade their u-boot.
-Scott
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Anton Vorontsov @ 2007-07-26 15:47 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <02aa01c7cf9a$aebf3bf0$02ac10ac@Jocke>
On Thu, Jul 26, 2007 at 05:36:06PM +0200, Joakim Tjernlund wrote:
[...]
> > spi@4c0 {
> > device_type = "spi";
> > + device-id = <1>;
> > compatible = "fsl_spi";
> > reg = <4c0 40>;
> > interrupts = <2>;
> > interrupt-parent = <&qeic>;
> > - mode = "cpu";
> > + mode = "qe";
>
> The driver is still using "cpu" mode. It just happens that the cpu mode for QE
> enabled CPUs isn't 100% compatible with the defacto cpu mode used by other CPU:s.
Yup, indeed.
> So mode should probably be "cpu_qe" or, even better, if the drver could
That's easy to change, thanks.
> autodetect that it is running on a QE enabled CPU and adjust accordinly.
> Maybe the Freescale guys have some ideas how to do that.
Ok. Well, for now could we use machine_is() for kind of autodetect?
Or it's better leave it as is, and just rename mode to cpu_qe?
> Jocke
>
> PS.
> Will be on vacation for a week as of tmw, won't have access
> during this time.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Joakim Tjernlund @ 2007-07-26 15:36 UTC (permalink / raw)
To: 'Anton Vorontsov', linuxppc-dev
In-Reply-To: <20070726135738.GB5643@localhost.localdomain>
> -----Original Message-----
> From:
> linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozlabs.org
> [mailto:linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozl
> abs.org] On Behalf Of Anton Vorontsov
> Sent: den 26 juli 2007 15:58
> To: linuxppc-dev@ozlabs.org
> Subject: [RFC][PATCH] MPC832x_RDB: update dts to use spi,
> register mmc_spi stub
>
> mmc_spi already tested to work. When it will hit mainline
> the only change that would be needed is replacing "spidev"
> by "mmc_spi", and adding trivial platform data to mmc_spi
> driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 33
> ++++++++++++++++++++-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 46
> +++++++++++++++++++++++++++++
> 2 files changed, 78 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> index 7c4beff..5dcbdd3 100644
> --- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> @@ -183,6 +183,21 @@
> 1 c 1 0 1 0
> /* TX_EN */
> 1 d 2 0 1 0>;
> /* CRS */
> };
> + spi1pio:spi_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain
> assignment has_irq */
> + 3 0 3 0 1 0
> /* SPI1 MOSI, I/O */
> + 3 1 3 0 1 0
> /* SPI1 MISO, I/O */
> + 3 2 3 0 1 0
> /* SPI1 CLK, I/O */
> + 3 3 2 0 1 0>;
> /* SPI1 SEL, I */
> + };
> + mmc1pio:mmc_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain
> assignment has_irq */
> + 3 d 1 0 0 0
> /* !SD_CS */
> + 3 e 2 0 0 0
> /* SD_INSERT */
> + 3 f 2 0 0 0>;
> /* SD_PROTECT */
> + };
> };
> };
>
> @@ -207,20 +222,36 @@
>
> spi@4c0 {
> device_type = "spi";
> + device-id = <1>;
> compatible = "fsl_spi";
> reg = <4c0 40>;
> interrupts = <2>;
> interrupt-parent = <&qeic>;
> - mode = "cpu";
> + mode = "qe";
The driver is still using "cpu" mode. It just happens that the cpu mode for QE
enabled CPUs isn't 100% compatible with the defacto cpu mode used by other CPU:s.
So mode should probably be "cpu_qe" or, even better, if the drver could
autodetect that it is running on a QE enabled CPU and adjust accordinly.
Maybe the Freescale guys have some ideas how to do that.
Jocke
PS.
Will be on vacation for a week as of tmw, won't have access
during this time.
^ permalink raw reply
* need help with 8247 config; bus errors, fcc underruns, etc...
From: Brad Parker @ 2007-07-26 15:34 UTC (permalink / raw)
To: linuxppc-dev
Anyone have direct experience setting up an 8247?
I need some help and am willing to pay for consulting. Please contact
me directly if interested.
Basically I have u-boot running and it will load a kernel via ethernet
(fcc). But once the kernel starts the FCC won't transmit packets bigger
than the fifo (192 bytes) - it gets underuns. It seems to receive fine.
And once and a while it will crash with a machine check. Or a TEA#
error.
I've done all the obvious things but no joy. For some reason this one
doesn't act like the 8260 or 8248.
-brad
Brad Parker
Heeltoe Consulting
+1-781-483-3101
http://www.heeltoe.com
^ permalink raw reply
* Re: About mdio_bus for 82xx based board
From: Scott Wood @ 2007-07-26 15:29 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.tv2nbmkonhx3hy@phoenix>
Alexandros Kostopoulos wrote:
> Well, I've downloaded the latest git from Paul's tree, and some patches
> still fail (and the mpc8272_ads config doesn't compile). Must I get
> some other revision of the tree (if yes, how's that done in git - my
> first time with it )
They don't apply on top of Paul's current tree -- they apply to his tree
as of the time the patchset was posted. I should have a revised
patchset in a week or two (the delay mainly being to add and test a
couple new boards).
-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