* how to use head_fsl_booke.S:abort to restart
From: Philippe De Muyter @ 2008-03-25 16:15 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I have a mpc8540 board that could reboot when driven by a ARCH=ppc linux,
but that hangs now in arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart when
asked to reboot with a ARCH=powerpc linux.
I have found that if I call arch/powerpc/kernel/head_fsl_booke.S:abort from
there, my board reboots correctly, but I feel that's not the right place
to put that call. Where/how should I do that ?
Philippe
PS : Does arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart actually work
for mpc8540_ads boards ?
^ permalink raw reply
* Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
From: Laurent Pinchart @ 2008-03-25 16:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080325160331.GB15093@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]
On Tuesday 25 March 2008 17:03, Scott Wood wrote:
> On Tue, Mar 25, 2008 at 04:34:46PM +0100, Laurent Pinchart wrote:
> > On Tuesday 25 March 2008 15:58, Scott Wood wrote:
> > > Please maintain backward compatibility with older device trees (by
> > > checking the length of the second reg resource). At the very least,
> > > update the device trees that are affected.
> >
> > I haven't seen any CPM2-based board using SMC ports in the device trees
> > available in arch/powerpc/boot/dts.
>
> ep8248e
I should have checked git head. My bad. I'll include the ep8248e device tree
in the next patch.
> > Should I still maintain compatibility with older device trees ? Is there
any
> > out-of-tree PQ2 boards using udbg and SMC ?
>
> Yes, I've answered questions on the lists from at least one person using
> a custom board with cpm2 smc.
Are you sure it wasn't me ? ;-)
> > What about printing a warning if the second reg resource has the wrong
> > size ?
>
> The only way you'll see the warning is if udbg is enabled. :-P
>
> Will a CPM reset blow away the portion of muram that holds the SMC pram
> pointer? If not (and I don't think it will), just return the device tree
> reg resource as is currently done if the resource is the wrong size.
Ok I'll do that. Should I add a warning message to tell people to update the
device tree ?
> > > After this point, even if you don't reset the CPM, udbg printk is broken
> > > because you moved pram. The udbg disabling will have to be moved before
> > > this.
> >
> > Moving the SMC pram doesn't break udbg printk in itself. What will break
it is
> > moving the TX BDs, but the end result is the same, moving pram will result
in
> > udbg being broken.
> >
> > The cpm_uart driver disable udbg before allocating the new BDs. What about
> > moving that right before moving the parameter RAM ?
cpm_uart_request_port(),
> > which is called in between, already disables RX and TX on the port, so we
> > won't loose any debug message.
>
> cpm_uart_request_port() returns without doing that if it's a console
> port. I think the current placement of the udbg disable will be fine.
Ok. I'll prepare a new patch that maintains compatibility with old device
trees.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Sergei Shtylyov @ 2008-03-25 16:23 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803251651.42608.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>>>We're talking about a very specific type of RAM, used for permanent storage
>>>with a battery backup. The RAM is really meant to be used as an MTD device
>>>and as such I think it makes sense to describe it as an mtd-compatible device
>>>on the local bus.
>>>What about the following definition for the RAM node ?
>>> nvram@2,0000 {
>> Note that there's a OF "device_type" of "nvram", so your (generic) device
>>name seems to add some mess. (IIRC, that OF device type didn't actually
>>represent a "real" device, and only served to provide access to NVRAM for OF).
> Ok.
Well, I might have gone too far here -- it should be a real device
(spec'ed in Device Support Extensions recommended practice). It's just that
the spec didn't mention "reg" property, only "#bytes" (the device capacity).
So, it may be worth considering...
>>> compatible = "mtd,ram";
>> The part before comma should be a company name or a stock ticker. What did
>>you mean here?
> I didn't know that. Let's say I meant "mtd-ram" :-)
>>> reg = <2 0x0000 0x00100000>;
>>> bank-width = <2>;
>>> };
>>>Or should the node have a device-type property of either 'ram' or 'rom' with
>>>the compatible property just referencing MTD ?
>> The "device_type" properties are not required and their further creation
>>has been discouraged on liunxppc-dev.
> What about
> mtdram@2,0000 {
> compatible = "mtd-ram";
> reg = <2 0x0000 0x00100000>;
> bank-width = <2>;
> };
> ROMs could use "mtd-rom" for their compatible property.
Heh, there was a whole company against mentioning "mtd" when we started
working on this (of course, the first idea was to call the flash device type
"mtd"). I don't think "mtd" looks good here -- I'd suggest "flash-ram" (if
this is just a linearly mapped NVRAM).
> Best regards,
WBR, Sergei
^ permalink raw reply
* RE: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports onCPM2-based platforms.
From: Rune Torgersen @ 2008-03-25 16:27 UTC (permalink / raw)
To: Laurent Pinchart, Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <200803251720.24667.laurentp@cse-semaphore.com>
>Laurent Pinchart wrote:
> On Tuesday 25 March 2008 17:03, Scott Wood wrote:
>> Yes, I've answered questions on the lists from at least one person
>> using a custom board with cpm2 smc.
>=20
> Are you sure it wasn't me ? ;-)
>=20
Probably me, actually. We have a 8280 with SMC's in use (SMC1 and 2)
^ permalink raw reply
* Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports onCPM2-based platforms.
From: Laurent Pinchart @ 2008-03-25 16:32 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04276FB4@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Tuesday 25 March 2008 17:27, Rune Torgersen wrote:
> >Laurent Pinchart wrote:
> > On Tuesday 25 March 2008 17:03, Scott Wood wrote:
> >> Yes, I've answered questions on the lists from at least one person
> >> using a custom board with cpm2 smc.
> >
> > Are you sure it wasn't me ? ;-)
> >
>
> Probably me, actually. We have a 8280 with SMC's in use (SMC1 and 2)
Ok.
Do you have any opinion about the proposed patch ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: how to use head_fsl_booke.S:abort to restart
From: Haiying Wang @ 2008-03-25 16:34 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080325161513.GB15991@frolo.macqel>
8540 doesn't have RSTCR register. You should not use fsl_rstcr_restart
for reboot your 8540 board.
Haiying
On Tue, 2008-03-25 at 17:15 +0100, Philippe De Muyter wrote:
> Hi all,
>
> I have a mpc8540 board that could reboot when driven by a ARCH=ppc linux,
> but that hangs now in arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart when
> asked to reboot with a ARCH=powerpc linux.
>
> I have found that if I call arch/powerpc/kernel/head_fsl_booke.S:abort from
> there, my board reboots correctly, but I feel that's not the right place
> to put that call. Where/how should I do that ?
>
> Philippe
>
> PS : Does arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart actually work
> for mpc8540_ads boards ?
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports onCPM2-based platforms.
From: Rune Torgersen @ 2008-03-25 16:41 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <200803251732.32569.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> On Tuesday 25 March 2008 17:27, Rune Torgersen wrote:
>>> Laurent Pinchart wrote:
>>> On Tuesday 25 March 2008 17:03, Scott Wood wrote:
>>>> Yes, I've answered questions on the lists from at least one person
>>>> using a custom board with cpm2 smc.
>>>=20
>>> Are you sure it wasn't me ? ;-)
>>=20
>> Probably me, actually. We have a 8280 with SMC's in use (SMC1 and 2)
> Do you have any opinion about the proposed patch ?
That is about time... :)
I've never really liked that the smc driver in the kernel relies on
parts of the SMC port to be set up by the boot-loader.
It really bit us when we were porting to 2.6.24, and was trying to
enable SMC2, since it was not used by u-boot as a console port, the pram
was uninitialized, and the linux driver then completely borked both
smc's.
This should take care of that, it looks like.
No driver should rely on the boot loader to initialize the device...
(With the exception of pin mappinmgs, PCI and memory...)
^ permalink raw reply
* Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
From: Scott Wood @ 2008-03-25 16:44 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803251720.24667.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> On Tuesday 25 March 2008 17:03, Scott Wood wrote:
>> Yes, I've answered questions on the lists from at least one person using
>> a custom board with cpm2 smc.
>
> Are you sure it wasn't me ? ;-)
Yes. :-)
>> Will a CPM reset blow away the portion of muram that holds the SMC pram
>> pointer? If not (and I don't think it will), just return the device tree
>> reg resource as is currently done if the resource is the wrong size.
>
> Ok I'll do that. Should I add a warning message to tell people to update the
> device tree ?
Sure.
-Scott
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-25 16:44 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <47E926FB.3030900@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]
On Tuesday 25 March 2008 17:23, Sergei Shtylyov wrote:
> Laurent Pinchart wrote:
>
> >>>We're talking about a very specific type of RAM, used for permanent
storage
> >>>with a battery backup. The RAM is really meant to be used as an MTD
device
> >>>and as such I think it makes sense to describe it as an mtd-compatible
device
> >>>on the local bus.
>
> >>>What about the following definition for the RAM node ?
>
> >>> nvram@2,0000 {
>
> >> Note that there's a OF "device_type" of "nvram", so your (generic)
device
> >>name seems to add some mess. (IIRC, that OF device type didn't actually
> >>represent a "real" device, and only served to provide access to NVRAM for
OF).
>
> > Ok.
>
> Well, I might have gone too far here -- it should be a real device
> (spec'ed in Device Support Extensions recommended practice). It's just that
> the spec didn't mention "reg" property, only "#bytes" (the device capacity).
> So, it may be worth considering...
The nvram device descrived in the Device Support Extensions is probably meant
to describe the kind of nvram found in RTC chips. That memory isn't directly
accessible. As the spec doesn't mention this explicitely we could still reuse
the nvram device type for direct-mapped battery-backed ram. I have no strong
opinion for or against that.
> >>> compatible = "mtd,ram";
>
> >> The part before comma should be a company name or a stock ticker. What
did
> >>you mean here?
>
> > I didn't know that. Let's say I meant "mtd-ram" :-)
>
> >>> reg = <2 0x0000 0x00100000>;
> >>> bank-width = <2>;
> >>> };
>
> >>>Or should the node have a device-type property of either 'ram' or 'rom'
with
> >>>the compatible property just referencing MTD ?
>
> >> The "device_type" properties are not required and their further
creation
> >>has been discouraged on liunxppc-dev.
>
> > What about
>
> > mtdram@2,0000 {
> > compatible = "mtd-ram";
> > reg = <2 0x0000 0x00100000>;
> > bank-width = <2>;
> > };
>
> > ROMs could use "mtd-rom" for their compatible property.
>
> Heh, there was a whole company against mentioning "mtd" when we started
> working on this (of course, the first idea was to call the flash device type
> "mtd"). I don't think "mtd" looks good here -- I'd suggest "flash-ram" (if
> this is just a linearly mapped NVRAM).
I'm fine with "flash-ram" (even thought it looks a bit weird). I'll prepare a
patch.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Bartlomiej Sieka @ 2008-03-25 16:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Richard Purdie
In-Reply-To: <fa686aa40803180953v7b704cf4g484324ef6fc8f523@mail.gmail.com>
Grant Likely wrote:
> On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
>> On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
>> I don't mind having a specific driver but I don't know anything about
>> the hardware its creating the interface for so I need the community's
>> help with that part. There is drivers/leds/leds-gpio.c if that would
>> work better.
>
> Yes, I think that would be the right approach. We would need to add
> the binding code to translate from the OF device tree to the leds-gpio
> driver.
I think that leds-gpio.c is a good solution for long-term. Note however,
that having the LED-to-GPIO pin mapping defined in the OF device
tree is problematic for targets that don't use a device tree, and for a
generic driver like leds-gpio.c some other mechanisms should probably be
used.
Going back to LEDs on Motion-PRO, using leds-gpio.c for this target
won't be achieved quickly. leds-gpio.c uses generic GPIO access
routines, which are not implemented for powerpc in general, and MPC5200
in particular. One would have to add support for MPC5200 to GPIO LIB
API, and implement the above mentioned LED-to-GPIO pin mapping in
leds-gpio.c, and then convert Motion-PRO.
Since both you and Richard don't have objections against a specific
driver, and switching Motion-PRO to a generic approach requires quite a
bit of work -- then how about we provide a patch that addresses
Richard's comments, and have the Motion-PRO LED support merged upstream
as a specific driver?
Regards,
Bartlomiej
^ permalink raw reply
* [PATCH] [POWERPC] CPM1: implement GPIO LIB API
From: Jochen Friedrich @ 2008-03-25 16:56 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Scott Wood, linux-kernel
Implement GPIO LIB API on CPM1 Freescale SoC.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
This is based on the series starting at http://patchwork.ozlabs.org/linuxppc/patch?id=17299
arch/powerpc/platforms/8xx/Kconfig | 2 +
arch/powerpc/sysdev/cpm1.c | 240 +++++++++++++++++++++++++++++++++++-
2 files changed, 241 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
index 7fd224c..e12cbf0 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -4,6 +4,8 @@ config FADS
config CPM1
bool
select CPM
+ select GENERIC_GPIO
+ select GPIO_LIB
choice
prompt "8xx Machine Type"
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index df8bd2b..c3d5df8 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -30,11 +30,14 @@
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/of_gpio.h>
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/8xx_immap.h>
#include <asm/cpm1.h>
#include <asm/io.h>
+#include <asm/gpio.h>
#include <asm/tlbflush.h>
#include <asm/rheap.h>
#include <asm/prom.h>
@@ -403,7 +406,7 @@ struct cpm_ioport16 {
};
struct cpm_ioport32 {
- __be32 dir, par, sor;
+ __be32 dir, par, sor, dat;
};
static void cpm1_set_pin32(int port, int pin, int flags)
@@ -610,3 +613,238 @@ int cpm1_clk_setup(enum cpm_clk_target target, int clock, int mode)
return 0;
}
+
+/*
+ * GPIO LIB API implementation
+ */
+
+struct cpm1_gpio16_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u16 cpdata;
+};
+
+static inline struct cpm1_gpio16_chip *
+to_cpm1_gpio16_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm1_gpio16_chip, mm_gc);
+}
+
+static void cpm1_gpio16_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+
+ cpm1_gc->cpdata = in_be16(&iop->dat);
+}
+
+static int cpm1_gpio16_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+ u16 pin_mask;
+
+ pin_mask = 1 << (15 - gpio);
+
+ return !!(in_be16(&iop->dat) & pin_mask);
+}
+
+static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+ unsigned long flags;
+ u16 pin_mask = 1 << (15 - gpio);
+
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
+
+ if (value)
+ cpm1_gc->cpdata |= pin_mask;
+ else
+ cpm1_gc->cpdata &= ~pin_mask;
+
+ out_be16(&iop->dat, cpm1_gc->cpdata);
+
+ spin_unlock_irqrestore(&cpm1_gc->lock, flags);
+}
+
+static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+ u16 pin_mask;
+
+ pin_mask = 1 << (15 - gpio);
+
+ setbits16(&iop->dir, pin_mask);
+
+ cpm1_gpio16_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm1_gpio16_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+ u16 pin_mask;
+
+ pin_mask = 1 << (15 - gpio);
+
+ clrbits16(&iop->dir, pin_mask);
+
+ return 0;
+}
+
+int cpm1_gpiochip_add16(struct device_node *np)
+{
+ struct cpm1_gpio16_chip *cpm1_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ cpm1_gc = kzalloc(sizeof(*cpm1_gc), GFP_KERNEL);
+ if (!cpm1_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&cpm1_gc->lock);
+
+ mm_gc = &cpm1_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ mm_gc->save_regs = cpm1_gpio16_save_regs;
+ of_gc->gpio_cells = 1;
+ gc->ngpio = 16;
+ gc->direction_input = cpm1_gpio16_dir_in;
+ gc->direction_output = cpm1_gpio16_dir_out;
+ gc->get = cpm1_gpio16_get;
+ gc->set = cpm1_gpio16_set;
+
+ return of_mm_gpiochip_add(np, mm_gc);
+}
+
+struct cpm1_gpio32_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u32 cpdata;
+};
+
+static inline struct cpm1_gpio32_chip *
+to_cpm1_gpio32_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm1_gpio32_chip, mm_gc);
+}
+
+static void cpm1_gpio32_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm1_gpio32_chip *cpm1_gc = to_cpm1_gpio32_chip(mm_gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+
+ cpm1_gc->cpdata = in_be32(&iop->dat);
+}
+
+static int cpm1_gpio32_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ return !!(in_be32(&iop->dat) & pin_mask);
+}
+
+static void cpm1_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio32_chip *cpm1_gc = to_cpm1_gpio32_chip(mm_gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
+
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
+
+ if (value)
+ cpm1_gc->cpdata |= pin_mask;
+ else
+ cpm1_gc->cpdata &= ~pin_mask;
+
+ out_be32(&iop->dat, cpm1_gc->cpdata);
+
+ spin_unlock_irqrestore(&cpm1_gc->lock, flags);
+}
+
+static int cpm1_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ setbits32(&iop->dir, pin_mask);
+
+ cpm1_gpio32_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm1_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ clrbits32(&iop->dir, pin_mask);
+
+ return 0;
+}
+
+int cpm1_gpiochip_add32(struct device_node *np)
+{
+ struct cpm1_gpio32_chip *cpm1_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ cpm1_gc = kzalloc(sizeof(*cpm1_gc), GFP_KERNEL);
+ if (!cpm1_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&cpm1_gc->lock);
+
+ mm_gc = &cpm1_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ mm_gc->save_regs = cpm1_gpio32_save_regs;
+ of_gc->gpio_cells = 1;
+ gc->ngpio = 32;
+ gc->direction_input = cpm1_gpio32_dir_in;
+ gc->direction_output = cpm1_gpio32_dir_out;
+ gc->get = cpm1_gpio32_get;
+ gc->set = cpm1_gpio32_set;
+
+ return of_mm_gpiochip_add(np, mm_gc);
+}
+
+static int cpm_init_par_io(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank16")
+ cpm1_gpiochip_add16(np);
+
+ for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank32")
+ cpm1_gpiochip_add32(np);
+ return 0;
+}
+arch_initcall(cpm_init_par_io);
--
1.5.4.4
^ permalink raw reply related
* Re: OF compatible MTD platform RAM driver ?
From: Sergei Shtylyov @ 2008-03-25 17:02 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803251744.46001.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>>>>>We're talking about a very specific type of RAM, used for permanent storage
>>>>>with a battery backup. The RAM is really meant to be used as an MTD device
>>>>>and as such I think it makes sense to describe it as an mtd-compatible device
>>>>>on the local bus.
>>>>>What about the following definition for the RAM node ?
>>>>> nvram@2,0000 {
>>>> Note that there's a OF "device_type" of "nvram", so your (generic) device
>>>>name seems to add some mess. (IIRC, that OF device type didn't actually
>>>>represent a "real" device, and only served to provide access to NVRAM for OF).
>>>Ok.
>> Well, I might have gone too far here -- it should be a real device
>>(spec'ed in Device Support Extensions recommended practice). It's just that
>>the spec didn't mention "reg" property, only "#bytes" (the device capacity).
>>So, it may be worth considering...
> The nvram device descrived in the Device Support Extensions is probably meant
> to describe the kind of nvram found in RTC chips.
Well, that is only an assumption -- actually, the sentense in the
description of the "#bytes" prop about the typical size being from 4 to 32K
speaks against it. The details of NVRAM implementation are hidden behind
read/write/seek methods.
> That memory isn't directly accessible.
That's what we have a "compatible" prop for. ;-)
> As the spec doesn't mention this explicitely we could still reuse
> the nvram device type for direct-mapped battery-backed ram. I have no strong
> opinion for or against that.
>>>>> reg = <2 0x0000 0x00100000>;
>>>>> bank-width = <2>;
>>>>> };
>>>>>Or should the node have a device-type property of either 'ram' or 'rom' with
>>>>>the compatible property just referencing MTD ?
>>>> The "device_type" properties are not required and their further creation
>>>>has been discouraged on liunxppc-dev.
>>>What about
>>> mtdram@2,0000 {
>>> compatible = "mtd-ram";
>>> reg = <2 0x0000 0x00100000>;
>>> bank-width = <2>;
>>> };
>>>ROMs could use "mtd-rom" for their compatible property.
>> Heh, there was a whole company against mentioning "mtd" when we started
>>working on this (of course, the first idea was to call the flash device type
>>"mtd"). I don't think "mtd" looks good here -- I'd suggest "flash-ram" (if
>>this is just a linearly mapped NVRAM).
> I'm fine with "flash-ram" (even thought it looks a bit weird). I'll prepare a
> patch.
Yeah. I forgeot that "flash" means EEPROM. Actually, the main facts about
the NVRAM that I'd want to be stated in the "compatible" property is that it's
non-volatile and directly/lineraly mapped... Just "nvram" doesn't seem
enopugh, maybe "linear-nvram" is. And we can specify "device_type" of "nvram"
indeed (and #size).
> Best regards,
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
From: Scott Wood @ 2008-03-25 17:16 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev list, linux-kernel
In-Reply-To: <47E92EC8.7010700@scram.de>
Jochen Friedrich wrote:
> diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
> index 7fd224c..e12cbf0 100644
> --- a/arch/powerpc/platforms/8xx/Kconfig
> +++ b/arch/powerpc/platforms/8xx/Kconfig
> @@ -4,6 +4,8 @@ config FADS
> config CPM1
> bool
> select CPM
> + select GENERIC_GPIO
> + select GPIO_LIB
Shouldn't this depend on the user enabling GPIO support? Some 8xx
boards are very memory-constrained, so we don't want to be making the
kernel even bigger than it already is unless it's actually needed.
-Scott
^ permalink raw reply
* kexec-tools patches for 32-bit arch/powerpc kernels
From: Dale Farnsworth @ 2008-03-25 17:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matt Wagantall
A while back, I posted some kernel patches adding kexec support for
32-bit platforms in arch/powerpc. We had hoped to clean up the
corresponding kexec-tools patches, but that hasn't happened yet.
Someone (hi Matt) recently asked about those kexec-tools patches,
so I've made them available via anon ftp. Please note that this
is a work in progress. The code for 32- and 64-bit arch/powerpc
support needs to be merged together. Nevertheless, it may prove
useful even in its current state.
The patches are available at:
ftp://source.mvista.com/pub/dfarnsworth/kexec-tools-32-bit-arch-powerpc-patches.tgz
-Dale
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-25 17:23 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <47E93010.5090904@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]
On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:
> Laurent Pinchart wrote:
>
> > > Heh, there was a whole company against mentioning "mtd" when we started
> > > working on this (of course, the first idea was to call the flash device
> > > type "mtd"). I don't think "mtd" looks good here -- I'd suggest
> > > "flash-ram" (if this is just a linearly mapped NVRAM).
>
> > I'm fine with "flash-ram" (even thought it looks a bit weird). I'll
> > prepare a patch.
>
> Yeah. I forgeot that "flash" means EEPROM. Actually, the main facts about
> the NVRAM that I'd want to be stated in the "compatible" property is that
> it's non-volatile and directly/lineraly mapped... Just "nvram" doesn't seem
> enopugh, maybe "linear-nvram" is.
Direct mapping is a hard requirement for the nvram if we want to use it with
the MTD subsystem. Regarding non-volatility nothing prevents a user from
using a volatile RAM as an MTD device, but there's little point in doing so.
Would it be acceptable for the "linear-nvram" specification not to include
volatile RAM ? ROM chips would be excluded too. Is that an issue ?
> And we can specify "device_type" of "nvram" indeed (and #size).
I suppose you meant #bytes.
What about sub-partitions support ? Nothing prevents RAM-based MTD devices
from being partioned. Would it be acceptable to reference the CFI/JEDEC flash
section in Documentation/powerpc/booting-without-of.txt in the description of
the nvram node ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Sergei Shtylyov @ 2008-03-25 17:37 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803251823.32039.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>>>>Heh, there was a whole company against mentioning "mtd" when we started
>>>>working on this (of course, the first idea was to call the flash device
>>>>type "mtd"). I don't think "mtd" looks good here -- I'd suggest
>>>>"flash-ram" (if this is just a linearly mapped NVRAM).
>>>I'm fine with "flash-ram" (even thought it looks a bit weird). I'll
>>>prepare a patch.
>>Yeah. I forgeot that "flash" means EEPROM. Actually, the main facts about
>>the NVRAM that I'd want to be stated in the "compatible" property is that
>>it's non-volatile and directly/lineraly mapped... Just "nvram" doesn't seem
>>enopugh, maybe "linear-nvram" is.
> Direct mapping is a hard requirement for the nvram if we want to use it with
> the MTD subsystem.
I thought we're currently talking about a driver controlling the directly
mapped NVRAM. The "compatible" property wouldn't allow us to specify the
compatibility to *any* NVRAM since there could be no "least common
denominator" driver anyway.
> Regarding non-volatility nothing prevents a user from
> using a volatile RAM as an MTD device, but there's little point in doing so.
Indeed, if just for testing... we could specify non-volatility as the
device's prop, though...
> Would it be acceptable for the "linear-nvram" specification not to include
> volatile RAM ? ROM chips would be excluded too. Is that an issue ?
Well, I think we need a separate "compatible" prop for ROMs. Or we'll end
up with the "compatible" being just "memory" with the memory "attributes"
(R/O, N/V) being described by other "properties"... :-)
>>And we can specify "device_type" of "nvram" indeed (and #size).
> I suppose you meant #bytes.
Of course. :-)
> What about sub-partitions support ? Nothing prevents RAM-based MTD devices
Hm... I remember that the knowledge of MTD partitions turned me away from
"nvram" device type when I started spec'ing the flash binding -- it's not
uncommon to have a flash partition devoted to and labelled as "nvram".
Therefore, that sole partition would have been a "nvram" device for OF...
> from being partioned. Would it be acceptable to reference the CFI/JEDEC flash
> section in Documentation/powerpc/booting-without-of.txt in the description of
> the nvram node ?
I don't see why not.
> Best regards,
WBR, Sergei
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Bartlomiej Sieka @ 2008-03-25 17:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com>
Grant Likely wrote:
[...]
> (copied from my comments in an off-list conversation)
>
> However, I have declined (for now) to pick up the defconfigs for those
> boards and instead merged in the config features they require into the
> mpc5200 defconfig. My primary reason for doing so is to increase the
> likelyhood that full featured kernels are built and tested so that
> situations where board ports conflict with each other are caught and
> fixed.
>
> ojn has also been complaining about the number of defconfigs he needs
> to build to test all the powerpc configurations without any
> indications about which ones are important and which ones are not.
> There has been some discussion about having a subdirectory for
> optimized board configs, but nobody has done anything about it yet.
>
> The one part that I have a really strong opinion on is that there
> should be a full featured mpc5200 defconfig for build testing. Beyond
> that (and if ojn can also be appeased) I can probably be convinced. :-)
Hi Grant,
How to deal with a situation where I need a particular PHY driver from
libphy compiled in the kernel for one of the MPC5200 boards? Adding it
to mpc5200_defconfig doesn't seem like a right thing to do. How to
convince you (and appease ojn) to accept a patch that adds a
board-specific defconfig that only slightly differs from
mpc5200_defconfig? :)
Regards,
Bartlomiej
^ permalink raw reply
* [PATCH] powerpc: add kernel parameter to set l3cr for G4 cpu
From: Robert Brose @ 2008-03-25 17:45 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
Old-world powermacs don't set L2CR or L3CR on processor upgrade cards.
This simple patch allows the setting of L3CR via a kernel parameter
(like the existing kernel parameter to set L2CR).
This is the first time I've posted a patch, please excuse me if I've
broken protocol in any way.
Signed-off-by: Robert Brose <bob@qbjnet.com>
[-- Attachment #2: Type: text/plain, Size: 1046 bytes --]
--- linux-2.6.24/arch/powerpc/kernel/setup_32.c.orig 2008-03-10 11:24:16.566354597 -0500
+++ linux-2.6.24/arch/powerpc/kernel/setup_32.c 2008-03-10 11:22:22.711626305 -0500
@@ -172,6 +172,18 @@ int __init ppc_setup_l2cr(char *str)
}
__setup("l2cr=", ppc_setup_l2cr);
+/* Checks "l3cr=xxxx" command-line option REB */
+int __init ppc_setup_l3cr(char *str)
+{
+ if (cpu_has_feature(CPU_FTR_L3CR)) {
+ unsigned long val = simple_strtoul(str, NULL, 0);
+ printk(KERN_INFO "l3cr set to %lx\n", val);
+ _set_L3CR(val); /* and enable it */
+ }
+ return 1;
+}
+__setup("l3cr=", ppc_setup_l3cr);
+
#ifdef CONFIG_GENERIC_NVRAM
/* Generic nvram hooks used by drivers/char/gen_nvram.c */
--- linux-2.6.24/Documentation/kernel-parameters.txt.orig 2008-03-25 12:30:09.688082305 -0500
+++ linux-2.6.24/Documentation/kernel-parameters.txt 2008-03-25 12:30:29.816083202 -0500
@@ -877,6 +877,8 @@ and is between 256 and 4096 characters.
l2cr= [PPC]
+ l3cr= [PPC]
+
lapic [X86-32,APIC] Enable the local APIC even if BIOS
disabled it.
^ permalink raw reply
* RE: OF compatible MTD platform RAM driver ?
From: Rune Torgersen @ 2008-03-25 17:56 UTC (permalink / raw)
To: Laurent Pinchart, Sergei Shtylyov
Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803251823.32039.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:
>> Laurent Pinchart wrote:
>>=20
> Regarding non-volatility nothing prevents a user from using a=20
> volatile RAM as an MTD device, but there's little point in doing so.
> Would it be acceptable for the "linear-nvram" specification
> not to include > volatile RAM ? ROM chips would be excluded too. Is
that an issue ?
We actually use a volatile ram (SRAM) as an MTD device. We use it to
store info from bootloader and system specific values between resets.
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-25 18:14 UTC (permalink / raw)
To: Rune Torgersen; +Cc: ben, David Gibson, linux-mtd, linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0427706A@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
On Tuesday 25 March 2008 18:56, Rune Torgersen wrote:
> Laurent Pinchart wrote:
> > On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:
> >> Laurent Pinchart wrote:
> >>
> > Regarding non-volatility nothing prevents a user from using a
> > volatile RAM as an MTD device, but there's little point in doing so.
> > Would it be acceptable for the "linear-nvram" specification
> > not to include > volatile RAM ? ROM chips would be excluded too. Is
> that an issue ?
>
> We actually use a volatile ram (SRAM) as an MTD device. We use it to
> store info from bootloader and system specific values between resets.
So we're left with two main options.
- Reusing the nvram device type from the Device Support Extensions. Volatile
devices wouldn't be supported, and we'd need a separate device specification
for linear-mapped volatile RAMs. I'm not very happy with that.
- Using another device node with a compatible value set to "linear-ram" (or
something similar). This would support both volatile and non-volatile
devices, and a property could be added to specify if the device is volatile
or not.
I'd go for the second option, and I'd specify a "linear-rom" compatible value
as well while we're at it.
Both volatile and non-volatile RAMs can be handled by the physmap_of MTD
driver. They both use the same map probe type ("map_ram"). Volatility isn't
handled there.
ROMs should be handled by the same driver and should use the "mtd_rom" map
probe type.
As all those devices use the physmap_of MTD driver, what about
using "physmap-ram" and "physmap-rom" as compatibility names ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-03-25 18:46 UTC (permalink / raw)
To: Jean Delvare; +Cc: linux-kernel, linuxppc-dev list, i2c, Scott Wood
In-Reply-To: <20080223134335.0f5c7d79@hyperion.delvare>
Hi Jean,
>> What is the preferred way to do this?
>
> I still have to think about it. I didn't have much time to work on this
> during the last 2 weeks, hopefully I will fine some time to experiment
> again soon. As I underlined before, my patch set affects no less than 5
> subsystems with different needs and expectations, it's no trivial
> change.
Sorry for the late response, but I was pretty busy the last couple of weeks.
I'm thinking about something like this (based on http://patchwork.ozlabs.org/linuxppc/patch?id=16282 to 16284):
This patch implements various helpers to support OF bindings for
the i2c API.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
drivers/of/Kconfig | 6 +++
drivers/of/Makefile | 1 +
drivers/of/i2c.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_i2c.h | 24 ++++++++++
4 files changed, 144 insertions(+), 0 deletions(-)
create mode 100644 drivers/of/i2c.c
create mode 100644 include/linux/of_i2c.h
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index c03072b..3cff449 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -1,3 +1,9 @@
config OF_DEVICE
def_bool y
depends on OF && (SPARC || PPC_OF)
+
+config OF_I2C
+ def_bool y
+ depends on OF && PPC_OF && I2C
+ help
+ OpenFirmware I2C accessors
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ab9be5d..655b982 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,2 +1,3 @@
obj-y = base.o
obj-$(CONFIG_OF_DEVICE) += device.o platform.o
+obj-$(CONFIG_OF_I2C) += i2c.o
diff --git a/drivers/of/i2c.c b/drivers/of/i2c.c
new file mode 100644
index 0000000..d3d1e9e
--- /dev/null
+++ b/drivers/of/i2c.c
@@ -0,0 +1,113 @@
+/*
+ * OF helpers for the I2C API
+ *
+ * Copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
+ *
+ * Based on a previous patch from Jon Smirl <jonsmirl@gmail.com>
+ *
+ * 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 Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/i2c.h>
+#include <asm/prom.h>
+
+struct i2c_driver_device {
+ char *of_device;
+ char *i2c_type;
+};
+
+static struct i2c_driver_device i2c_devices[] = {
+ {"dallas,ds1374", "rtc-ds1374",},
+};
+
+static int of_find_i2c_driver(struct device_node *node,
+ struct i2c_board_info *info)
+{
+ int i, cplen;
+ const char *compatible;
+ const char *p;
+
+ /* 1. search for exception list entry */
+ for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
+ if (!of_device_is_compatible(node, i2c_devices[i].of_device))
+ continue;
+ if (strlcpy(info->type, i2c_devices[i].i2c_type,
+ I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
+
+ return 0;
+ }
+
+ compatible = of_get_property(node, "compatible", &cplen);
+ if (!compatible)
+ return -ENODEV;
+
+ /* 2. search for linux,<i2c-type> entry */
+ p = compatible;
+ while (cplen > 0) {
+ if (!strncmp(p, "linux,", 6)) {
+ p += 6;
+ if (strlcpy(info->type, p,
+ I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
+ return 0;
+ }
+
+ i = strlen(p) + 1;
+ p += i;
+ cplen -= i;
+ }
+
+ /* 3. take fist compatible entry and strip manufacturer */
+ p = strchr(compatible, ',');
+ if (!p)
+ return -ENODEV;
+ p++;
+ if (strlcpy(info->type, p, I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
+ return 0;
+}
+
+void of_register_i2c_devices(struct i2c_adapter *adap,
+ struct device_node *adap_node)
+{
+ void *result;
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info = {};
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
+ printk(KERN_ERR
+ "of-i2c: invalid i2c device entry\n");
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ if (of_find_i2c_driver(node, &info) < 0)
+ continue;
+
+ info.addr = *addr;
+
+ request_module(info.type);
+
+ result = i2c_new_device(adap, &info);
+ if (result == NULL) {
+ printk(KERN_ERR
+ "of-i2c: Failed to load driver for %s\n",
+ info.type);
+ irq_dispose_mapping(info.irq);
+ continue;
+ }
+ }
+}
+EXPORT_SYMBOL(of_register_i2c_devices);
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
new file mode 100644
index 0000000..2e5a967
--- /dev/null
+++ b/include/linux/of_i2c.h
@@ -0,0 +1,24 @@
+/*
+ * Generic I2C API implementation for PowerPC.
+ *
+ * Copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
+ *
+ * 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 Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_OF_I2C_H
+#define __LINUX_OF_I2C_H
+
+#include <linux/i2c.h>
+
+#ifdef CONFIG_OF_I2C
+
+void of_register_i2c_devices(struct i2c_adapter *adap,
+ struct device_node *adap_node);
+
+#endif /* CONFIG_OF_I2C */
+
+#endif /* __LINUX_OF_I2C_H */
--
1.5.4.4
^ permalink raw reply related
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-25 18:49 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, Richard Purdie
In-Reply-To: <47E92D60.6090008@semihalf.com>
On Tue, Mar 25, 2008 at 10:50 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant Likely wrote:
> > On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> >> On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> >> I don't mind having a specific driver but I don't know anything about
> >> the hardware its creating the interface for so I need the community's
> >> help with that part. There is drivers/leds/leds-gpio.c if that would
> >> work better.
> >
> > Yes, I think that would be the right approach. We would need to add
> > the binding code to translate from the OF device tree to the leds-gpio
> > driver.
>
> I think that leds-gpio.c is a good solution for long-term. Note however,
> that having the LED-to-GPIO pin mapping defined in the OF device
> tree is problematic for targets that don't use a device tree, and for a
> generic driver like leds-gpio.c some other mechanisms should probably be
> used.
Something to consider: The device tree is all about describing
hardware and binding it to the driver. Nothing more. So; there will
always be glue code to extract the config from the tree and tell the
leds-gpio driver about it (the binding); but once that is done the
driver isn't any different. I've got several drivers with both
platform bus and of_platform bus bindings where most of the driver is
shared. Only the bit of code that extracts the configuration from
either pdata or the device tree is bus specific.
>
> Going back to LEDs on Motion-PRO, using leds-gpio.c for this target
> won't be achieved quickly. leds-gpio.c uses generic GPIO access
> routines, which are not implemented for powerpc in general, and MPC5200
> in particular. One would have to add support for MPC5200 to GPIO LIB
> API, and implement the above mentioned LED-to-GPIO pin mapping in
> leds-gpio.c, and then convert Motion-PRO.
>
> Since both you and Richard don't have objections against a specific
> driver, and switching Motion-PRO to a generic approach requires quite a
> bit of work -- then how about we provide a patch that addresses
> Richard's comments, and have the Motion-PRO LED support merged upstream
> as a specific driver?
Yes, I'm totally cool with that.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-25 18:51 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev
In-Reply-To: <47E938A8.9000103@semihalf.com>
On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant Likely wrote:
> > The one part that I have a really strong opinion on is that there
> > should be a full featured mpc5200 defconfig for build testing. Beyond
> > that (and if ojn can also be appeased) I can probably be convinced. :-)
>
> Hi Grant,
>
> How to deal with a situation where I need a particular PHY driver from
> libphy compiled in the kernel for one of the MPC5200 boards? Adding it
> to mpc5200_defconfig doesn't seem like a right thing to do.
Why not? mpc5200_defconfig is all about compile and runtime testing
on many platforms to make sure drivers play well together. I have no
problem adding more drivers to the mpc5200 defconfig. (In fact, I
encourage it).
> How to
> convince you (and appease ojn) to accept a patch that adds a
> board-specific defconfig that only slightly differs from
> mpc5200_defconfig? :)
I'm thinking 'optimized' defconfigs should go into a subdirectory.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2 v2] Add DIU platform code for MPC8610HPCD
From: Andrew Morton @ 2008-03-25 19:18 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: linuxppc-dev, linux-fbdev-devel, yorksun, linux-kernel
In-Reply-To: <20080325124322.GH12798@shadowen.org>
On Tue, 25 Mar 2008 12:43:22 +0000
Andy Whitcroft <apw@shadowen.org> wrote:
> > > ...
> > >
> > > +unsigned int mpc8610hpcd_get_pixel_format
> > > + (unsigned int bits_per_pixel, int monitor_port)
>
> This seems like it might be detectable, does this seem like something we
> should try an report?
I guess so. It's quite unusual.
^ permalink raw reply
* Re: how to use head_fsl_booke.S:abort to restart
From: Philippe De Muyter @ 2008-03-25 20:20 UTC (permalink / raw)
To: Haiying Wang; +Cc: linuxppc-dev
In-Reply-To: <1206462895.2960.10.camel@r54964-12.am.freescale.net>
Hi Haiying,
On Tue, Mar 25, 2008 at 12:34:55PM -0400, Haiying Wang wrote:
> 8540 doesn't have RSTCR register. You should not use fsl_rstcr_restart
> for reboot your 8540 board.
>
That's what I was thinking also (see my Post-Scriptum below), but current
linux/powerpc sources use fsl_rstcr_restart for the mpc8540_ads board :(
Philippe
> On Tue, 2008-03-25 at 17:15 +0100, Philippe De Muyter wrote:
> > Hi all,
> >
> > I have a mpc8540 board that could reboot when driven by a ARCH=ppc linux,
> > but that hangs now in arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart when
> > asked to reboot with a ARCH=powerpc linux.
> >
> > I have found that if I call arch/powerpc/kernel/head_fsl_booke.S:abort from
> > there, my board reboots correctly, but I feel that's not the right place
> > to put that call. Where/how should I do that ?
> >
> > Philippe
> >
> > PS : Does arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart actually work
> > for mpc8540_ads boards ?
^ 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