* Re: [PATCH 3/3] ARM: mach-shmobile: sh7372 A4R support (v4)
From: Guennadi Liakhovetski @ 2011-11-02 22:00 UTC (permalink / raw)
To: Magnus Damm; +Cc: Rafael J. Wysocki, Linux-sh list, Linux PM list, Linux Kernel
In-Reply-To: <Pine.LNX.4.64.1111022131460.19054@axis700.grange>
On Wed, 2 Nov 2011, Guennadi Liakhovetski wrote:
> Hi Magnus
>
> On Wed, 2 Nov 2011, Magnus Damm wrote:
>
> > On Wed, Nov 2, 2011 at 11:38 AM, Guennadi Liakhovetski
> > <g.liakhovetski@gmx.de> wrote:
> > > On Thu, 20 Oct 2011, Rafael J. Wysocki wrote:
> > >
> > >> From: Magnus Damm <damm@opensource.se>
> > >>
> > >> This change adds support for the sh7372 A4R power domain.
> > >
> > > This version still breaks I2C (#0) on mackerel. Tested with your
> > > sh7372-test branch of Oct 18th plus these four patches:
> > >
> > > 6b29305a PM / Domains: Add default power off governor function (v2)
> > > 3d578ae PM / Domains: Add device stop governor function (v2)
> > > 6c2cd02 ARM: mach-shmobile: sh7372 A4R support (v4)
> > > 9da11f4 ARM: mach-shmobile: sh7372 A3SP support (v4)
> >
> > Exactly how does it break IIC0?
>
> We discussed it a couple of weeks ago, remember? Here's a quote:
>
> > > > 3. I2C #0 doesn't work (last worked with some 3.1-rc7 based kernel). It is
> > > > needed for the keypad, without which I don't know how the board can be
> > > > woken up
> > >
> > > That's odd. It worked fine when I tested with Morimoto-san earlier
> > > today. Are we using the same code?
> >
> > I hope so. I'm using what Rafael suggested in his mail:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git sh7372-test
> >
> > HEAD currently at commit
> >
> > commit 2b7a2158042fbed2dc0c677d24efc2d3c8680186
> > Author: Magnus Damm <damm@opensource.se>
> > Date: Sun Oct 16 23:35:59 2011 +0200
> >
> > ARM: mach-shmobile: sh7372 A4R support (v3)
> >
> > I2C works with HEAD^
>
> Of course, now testing with v4 of A3SP and A4R patches. As for "exactly
> how":
>
> i2c-sh_mobile i2c-sh_mobile.0: I2C adapter 0 with bus speed 100000 Hz
> i2c-sh_mobile i2c-sh_mobile.1: I2C adapter 1 with bus speed 100000 Hz
> Linux video capture interface: v2.00
> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0
> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0
> i2c-sh_mobile i2c-sh_mobile.0: Transfer request timed out
> i2c-sh_mobile i2c-sh_mobile.0: Polling timed out
> tca6416-keypad 0-0020: tca6416_read_reg failed, reg: 1, error: -5
> tca6416-keypad: probe of 0-0020 failed with error -5
>
> So, seems just not to be enabled.
>
> > Does the same happen with the code base for upcoming 3.2-rc1 from
> > latest linux git?
>
> Good question:
>
> linux-2.6/arch/arm/kernel/entry-armv.S: Assembler messages:
> linux-2.6/arch/arm/kernel/entry-armv.S:501: Error: backward ref to unknown label "2:"
> linux-2.6/arch/arm/kernel/entry-armv.S:502: Error: backward ref to unknown label "3:"
> make[2]: *** [arch/arm/kernel/entry-armv.o] Error 1
After an "obvious" fix:
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 9ad50c4..6f8fbfe 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -497,7 +497,7 @@ ENDPROC(__und_usr)
.popsection
.pushsection __ex_table,"a"
.long 1b, 4b
-#if __LINUX_ARM_ARCH__ >= 7
+#if CONFIG_ARM_THUMB && __LINUX_ARM_ARCH__ >= 7
.long 2b, 4b
.long 3b, 4b
#endif
(not sure, whether " && CONFIG_CPU_V7" is also needed), and a manual fix
for ASoC / I2C Kconfig failure, the kernel builds and boots, but I2C fails
in the same way. I.e., PM patches up to A3SP fix that problem, and A4R
brings it back.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply related
* Re: [PATCH 3/3] ARM: mach-shmobile: sh7372 A4R support (v4)
From: Guennadi Liakhovetski @ 2011-11-02 20:52 UTC (permalink / raw)
To: Magnus Damm; +Cc: Rafael J. Wysocki, Linux-sh list, Linux PM list, Linux Kernel
In-Reply-To: <CANqRtoS5KTws7rDoHkxrq8DP+js5xq=YF3zQG4MYmmjHEtv5NA@mail.gmail.com>
Hi Magnus
On Wed, 2 Nov 2011, Magnus Damm wrote:
> On Wed, Nov 2, 2011 at 11:38 AM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.de> wrote:
> > On Thu, 20 Oct 2011, Rafael J. Wysocki wrote:
> >
> >> From: Magnus Damm <damm@opensource.se>
> >>
> >> This change adds support for the sh7372 A4R power domain.
> >
> > This version still breaks I2C (#0) on mackerel. Tested with your
> > sh7372-test branch of Oct 18th plus these four patches:
> >
> > 6b29305a PM / Domains: Add default power off governor function (v2)
> > 3d578ae PM / Domains: Add device stop governor function (v2)
> > 6c2cd02 ARM: mach-shmobile: sh7372 A4R support (v4)
> > 9da11f4 ARM: mach-shmobile: sh7372 A3SP support (v4)
>
> Exactly how does it break IIC0?
We discussed it a couple of weeks ago, remember? Here's a quote:
> > > 3. I2C #0 doesn't work (last worked with some 3.1-rc7 based kernel). It is
> > > needed for the keypad, without which I don't know how the board can be
> > > woken up
> >
> > That's odd. It worked fine when I tested with Morimoto-san earlier
> > today. Are we using the same code?
>
> I hope so. I'm using what Rafael suggested in his mail:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git sh7372-test
>
> HEAD currently at commit
>
> commit 2b7a2158042fbed2dc0c677d24efc2d3c8680186
> Author: Magnus Damm <damm@opensource.se>
> Date: Sun Oct 16 23:35:59 2011 +0200
>
> ARM: mach-shmobile: sh7372 A4R support (v3)
>
> I2C works with HEAD^
Of course, now testing with v4 of A3SP and A4R patches. As for "exactly
how":
i2c-sh_mobile i2c-sh_mobile.0: I2C adapter 0 with bus speed 100000 Hz
i2c-sh_mobile i2c-sh_mobile.1: I2C adapter 1 with bus speed 100000 Hz
Linux video capture interface: v2.00
soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0
i2c-sh_mobile i2c-sh_mobile.0: Transfer request timed out
i2c-sh_mobile i2c-sh_mobile.0: Polling timed out
tca6416-keypad 0-0020: tca6416_read_reg failed, reg: 1, error: -5
tca6416-keypad: probe of 0-0020 failed with error -5
So, seems just not to be enabled.
> Does the same happen with the code base for upcoming 3.2-rc1 from
> latest linux git?
Good question:
linux-2.6/arch/arm/kernel/entry-armv.S: Assembler messages:
linux-2.6/arch/arm/kernel/entry-armv.S:501: Error: backward ref to unknown label "2:"
linux-2.6/arch/arm/kernel/entry-armv.S:502: Error: backward ref to unknown label "3:"
make[2]: *** [arch/arm/kernel/entry-armv.o] Error 1
So, no, it doesn't;-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [GIT PULL] sh updates for 3.2
From: Linus Torvalds @ 2011-11-02 16:52 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-sh, linux-kernel
In-Reply-To: <20111102142233.GC5972@linux-sh.org>
On Wed, Nov 2, 2011 at 7:22 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> Please pull from:
>
> git://github.com/pmundt/linux-sh.git sh-latest
Paul, please verify this for me somehow. You used to have a kernel.org
account, and this is a repo I haven't seen before. Admittedly all the
changes are to sh-specific files, so I don't think anybody *really*
cares, but still..
Linus
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Sascha Hauer @ 2011-11-02 14:29 UTC (permalink / raw)
To: Mark Brown
Cc: Mike Frysinger, linux-kernel, Liam Girdwood, Linus Walleij,
Paul Mundt, Tony Lindgren, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <20111102104126.GA2678@opensource.wolfsonmicro.com>
On Wed, Nov 02, 2011 at 10:41:27AM +0000, Mark Brown wrote:
> On Wed, Nov 02, 2011 at 11:03:56AM +0100, Sascha Hauer wrote:
> > On Tue, Nov 01, 2011 at 06:27:21PM +0000, Mark Brown wrote:
>
> > > As I think I said earlier I'd use the fixed regulator for this, all
> > > Sascha's actually doing here is adding a wrapper to simplify
> > > registration of that.
>
> > There's one difference between the fixed and the dummy regulator though:
> > The fixed regulator has a voltage. The same dummy regulator instance can
>
> No, the voltage is optional.
Ok, didn't know this.
>
> > be used for all devices which do not have a software controllable
> > regulator. I think the same can be done with the fixed regulator aswell,
> > but the bogus voltage showing up in the sysfs entry might be confusing
> > to users.
>
> I don't think that's a meaningful issue, any in any case it'd be better
> practice to fill it in so devices can use the information if they want
> to (which really shouldn't be hard
>
> > Another approach to this topic would be to allow a board to explicitely
> > bind to the existing dummy regulator, like the following (error path
> > should of course be implemented before applying this)
>
> If you know you've got a fixed voltage supply I don't understand why you
> wouldn't want to set one up. There clearly is an actual supply in the
> system...
It's just that it's simpler for a board to provide all dummy supplies in
a single array, no matter if the real voltage is 1.8V or 3.3V. Anyway,
as the voltage is optional in a fixed regulator this is no problem. I'll
update my patch to use the fixed regulator then.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [GIT PULL] sh updates for 3.2
From: Paul Mundt @ 2011-11-02 14:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-sh, linux-kernel
Please pull from:
git://github.com/pmundt/linux-sh.git sh-latest
Which contains:
Kuninori Morimoto (1):
sh: ecovec: add renesas_usbhs DMAEngine support
Magnus Damm (4):
sh: intc: Add IRQ trigger bit field check
sh: pfc: get_config_reg() shift clean up
sh: pfc: Remove unused gpio_in_use member
sh: pfc: Add GPIO IRQ support
Nobuhiro Iwamatsu (4):
sh: Fix implicit declaration of function numa_node_id
sh: userimask.c needs linux/stat.h
sh: modify the asm/sh_eth.h to linux/sh_eth.h in sh7757lcr
sh: Add default uImage rule for sh7757lcr
Paul Bolle (1):
sh: drop unused Kconfig symbol
Simon Horman (2):
sh: kexec: Register crashk_res
sh: kexec: Add PHYSICAL_START
Yong Zhang (1):
SH: irq: Remove IRQF_DISABLED
Yoshihiro Shimoda (2):
sh: add parameters for EHCI and RIIC in clock-sh7757.c
sh: modify the asm/sh_eth.h to linux/sh_eth.h in some boards
arch/sh/Kconfig | 17 ++++++++++++-----
arch/sh/Makefile | 1 +
arch/sh/boards/board-espt.c | 2 +-
arch/sh/boards/board-secureedge5410.c | 3 +--
arch/sh/boards/board-sh7757lcr.c | 2 +-
arch/sh/boards/mach-cayman/irq.c | 2 --
arch/sh/boards/mach-ecovec24/setup.c | 6 +++++-
arch/sh/boards/mach-hp6xx/hp6xx_apm.c | 2 +-
arch/sh/boards/mach-se/7724/setup.c | 2 +-
arch/sh/boards/mach-sh7763rdp/setup.c | 2 +-
arch/sh/boot/Makefile | 6 ++++--
arch/sh/drivers/dma/dma-g2.c | 2 +-
arch/sh/drivers/dma/dma-pvr2.c | 1 -
arch/sh/drivers/dma/dma-sh.c | 4 ++--
arch/sh/drivers/dma/dmabrg.c | 6 +++---
arch/sh/drivers/pci/pci-sh5.c | 4 ++--
arch/sh/drivers/pci/pci-sh7780.c | 2 +-
arch/sh/drivers/push-switch.c | 2 +-
arch/sh/include/asm/page.h | 10 ++++++++++
arch/sh/kernel/cpu/sh4a/clock-sh7757.c | 10 +++++++++-
arch/sh/kernel/cpu/sh4a/smp-shx3.c | 2 +-
arch/sh/kernel/setup.c | 9 ++++++---
arch/sh/kernel/topology.c | 1 +
arch/sh/kernel/vmlinux.lds.S | 2 +-
arch/sh/mm/init.c | 8 ++++----
drivers/sh/intc/chip.c | 9 +++++++--
drivers/sh/intc/userimask.c | 1 +
drivers/sh/pfc.c | 29 ++++++++++++++++++++++++++++-
include/linux/sh_pfc.h | 12 +++++++++++-
29 files changed, 117 insertions(+), 42 deletions(-)
^ permalink raw reply
* Re: [PATCH 3/3] ARM: mach-shmobile: sh7372 A4R support (v4)
From: Magnus Damm @ 2011-11-02 14:18 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Rafael J. Wysocki, Linux-sh list, Linux PM list, Linux Kernel
In-Reply-To: <Pine.LNX.4.64.1111021132240.19054@axis700.grange>
On Wed, Nov 2, 2011 at 11:38 AM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> On Thu, 20 Oct 2011, Rafael J. Wysocki wrote:
>
>> From: Magnus Damm <damm@opensource.se>
>>
>> This change adds support for the sh7372 A4R power domain.
>
> This version still breaks I2C (#0) on mackerel. Tested with your
> sh7372-test branch of Oct 18th plus these four patches:
>
> 6b29305a PM / Domains: Add default power off governor function (v2)
> 3d578ae PM / Domains: Add device stop governor function (v2)
> 6c2cd02 ARM: mach-shmobile: sh7372 A4R support (v4)
> 9da11f4 ARM: mach-shmobile: sh7372 A3SP support (v4)
Exactly how does it break IIC0?
Does the same happen with the code base for upcoming 3.2-rc1 from
latest linux git?
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Mark Brown @ 2011-11-02 10:41 UTC (permalink / raw)
To: Sascha Hauer
Cc: Mike Frysinger, linux-kernel, Liam Girdwood, Linus Walleij,
Paul Mundt, Tony Lindgren, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <20111102100355.GJ23421@pengutronix.de>
On Wed, Nov 02, 2011 at 11:03:56AM +0100, Sascha Hauer wrote:
> On Tue, Nov 01, 2011 at 06:27:21PM +0000, Mark Brown wrote:
> > As I think I said earlier I'd use the fixed regulator for this, all
> > Sascha's actually doing here is adding a wrapper to simplify
> > registration of that.
> There's one difference between the fixed and the dummy regulator though:
> The fixed regulator has a voltage. The same dummy regulator instance can
No, the voltage is optional.
> be used for all devices which do not have a software controllable
> regulator. I think the same can be done with the fixed regulator aswell,
> but the bogus voltage showing up in the sysfs entry might be confusing
> to users.
I don't think that's a meaningful issue, any in any case it'd be better
practice to fill it in so devices can use the information if they want
to (which really shouldn't be hard
> Another approach to this topic would be to allow a board to explicitely
> bind to the existing dummy regulator, like the following (error path
> should of course be implemented before applying this)
If you know you've got a fixed voltage supply I don't understand why you
wouldn't want to set one up. There clearly is an actual supply in the
system...
^ permalink raw reply
* Re: [PATCH 3/3] ARM: mach-shmobile: sh7372 A4R support (v4)
From: Guennadi Liakhovetski @ 2011-11-02 10:38 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux-sh list, Linux PM list, Linux Kernel, Magnus Damm
In-Reply-To: <201110200015.06277.rjw@sisk.pl>
On Thu, 20 Oct 2011, Rafael J. Wysocki wrote:
> From: Magnus Damm <damm@opensource.se>
>
> This change adds support for the sh7372 A4R power domain.
This version still breaks I2C (#0) on mackerel. Tested with your
sh7372-test branch of Oct 18th plus these four patches:
6b29305a PM / Domains: Add default power off governor function (v2)
3d578ae PM / Domains: Add device stop governor function (v2)
6c2cd02 ARM: mach-shmobile: sh7372 A4R support (v4)
9da11f4 ARM: mach-shmobile: sh7372 A3SP support (v4)
Thanks
Guennadi
>
> The sh7372 A4R hardware power domain contains the
> SH CPU Core and a set of I/O devices including
> multimedia accelerators and I2C controllers.
>
> One special case about A4R is the INTCS interrupt
> controller that needs to be saved and restored to
> keep working as expected. Also the LCDC hardware
> blocks are in a different hardware power domain
> but have their IRQs routed only through INTCS. So
> as long as LCDCs are active we cannot power down
> INTCS because that would risk losing interrupts.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
> arch/arm/mach-shmobile/board-ap4evb.c | 1
> arch/arm/mach-shmobile/board-mackerel.c | 1
> arch/arm/mach-shmobile/include/mach/sh7372.h | 7 +++
> arch/arm/mach-shmobile/intc-sh7372.c | 52 ++++++++++++++++++++++++++-
> arch/arm/mach-shmobile/pm-sh7372.c | 29 ++++++++++++++-
> arch/arm/mach-shmobile/setup-sh7372.c | 8 ++++
> 6 files changed, 96 insertions(+), 2 deletions(-)
>
> Index: linux/arch/arm/mach-shmobile/board-ap4evb.c
> =================================> --- linux.orig/arch/arm/mach-shmobile/board-ap4evb.c
> +++ linux/arch/arm/mach-shmobile/board-ap4evb.c
> @@ -1412,6 +1412,7 @@ static void __init ap4evb_init(void)
> sh7372_add_device_to_domain(&sh7372_a3sp, &sh_mmcif_device);
> sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi0_device);
> sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi1_device);
> + sh7372_add_device_to_domain(&sh7372_a4r, &ceu_device);
>
> hdmi_init_pm_clock();
> fsi_init_pm_clock();
> Index: linux/arch/arm/mach-shmobile/board-mackerel.c
> =================================> --- linux.orig/arch/arm/mach-shmobile/board-mackerel.c
> +++ linux/arch/arm/mach-shmobile/board-mackerel.c
> @@ -1596,6 +1596,7 @@ static void __init mackerel_init(void)
> sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi1_device);
> #endif
> sh7372_add_device_to_domain(&sh7372_a3sp, &sdhi2_device);
> + sh7372_add_device_to_domain(&sh7372_a4r, &ceu_device);
>
> hdmi_init_pm_clock();
> sh7372_pm_init();
> Index: linux/arch/arm/mach-shmobile/include/mach/sh7372.h
> =================================> --- linux.orig/arch/arm/mach-shmobile/include/mach/sh7372.h
> +++ linux/arch/arm/mach-shmobile/include/mach/sh7372.h
> @@ -480,8 +480,11 @@ struct platform_device;
> struct sh7372_pm_domain {
> struct generic_pm_domain genpd;
> struct dev_power_governor *gov;
> + void (*suspend)(void);
> + void (*resume)(void);
> unsigned int bit_shift;
> bool no_debug;
> + bool stay_on;
> };
>
> static inline struct sh7372_pm_domain *to_sh7372_pd(struct generic_pm_domain *d)
> @@ -493,6 +496,7 @@ static inline struct sh7372_pm_domain *t
> extern struct sh7372_pm_domain sh7372_a4lc;
> extern struct sh7372_pm_domain sh7372_a4mp;
> extern struct sh7372_pm_domain sh7372_d4;
> +extern struct sh7372_pm_domain sh7372_a4r;
> extern struct sh7372_pm_domain sh7372_a3rv;
> extern struct sh7372_pm_domain sh7372_a3ri;
> extern struct sh7372_pm_domain sh7372_a3sp;
> @@ -509,4 +513,7 @@ extern void sh7372_pm_add_subdomain(stru
> #define sh7372_pm_add_subdomain(pd, sd) do { } while(0)
> #endif /* CONFIG_PM */
>
> +extern void sh7372_intcs_suspend(void);
> +extern void sh7372_intcs_resume(void);
> +
> #endif /* __ASM_SH7372_H__ */
> Index: linux/arch/arm/mach-shmobile/intc-sh7372.c
> =================================> --- linux.orig/arch/arm/mach-shmobile/intc-sh7372.c
> +++ linux/arch/arm/mach-shmobile/intc-sh7372.c
> @@ -606,9 +606,16 @@ static void intcs_demux(unsigned int irq
> generic_handle_irq(intcs_evt2irq(evtcodeas));
> }
>
> +static void __iomem *intcs_ffd2;
> +static void __iomem *intcs_ffd5;
> +
> void __init sh7372_init_irq(void)
> {
> - void __iomem *intevtsa = ioremap_nocache(0xffd20100, PAGE_SIZE);
> + void __iomem *intevtsa;
> +
> + intcs_ffd2 = ioremap_nocache(0xffd20000, PAGE_SIZE);
> + intevtsa = intcs_ffd2 + 0x100;
> + intcs_ffd5 = ioremap_nocache(0xffd50000, PAGE_SIZE);
>
> register_intc_controller(&intca_desc);
> register_intc_controller(&intcs_desc);
> @@ -617,3 +624,46 @@ void __init sh7372_init_irq(void)
> irq_set_handler_data(evt2irq(0xf80), (void *)intevtsa);
> irq_set_chained_handler(evt2irq(0xf80), intcs_demux);
> }
> +
> +static unsigned short ffd2[0x200];
> +static unsigned short ffd5[0x100];
> +
> +void sh7372_intcs_suspend(void)
> +{
> + int k;
> +
> + for (k = 0x00; k <= 0x30; k += 4)
> + ffd2[k] = __raw_readw(intcs_ffd2 + k);
> +
> + for (k = 0x80; k <= 0xb0; k += 4)
> + ffd2[k] = __raw_readb(intcs_ffd2 + k);
> +
> + for (k = 0x180; k <= 0x188; k += 4)
> + ffd2[k] = __raw_readb(intcs_ffd2 + k);
> +
> + for (k = 0x00; k <= 0x3c; k += 4)
> + ffd5[k] = __raw_readw(intcs_ffd5 + k);
> +
> + for (k = 0x80; k <= 0x9c; k += 4)
> + ffd5[k] = __raw_readb(intcs_ffd5 + k);
> +}
> +
> +void sh7372_intcs_resume(void)
> +{
> + int k;
> +
> + for (k = 0x00; k <= 0x30; k += 4)
> + __raw_writew(ffd2[k], intcs_ffd2 + k);
> +
> + for (k = 0x80; k <= 0xb0; k += 4)
> + __raw_writeb(ffd2[k], intcs_ffd2 + k);
> +
> + for (k = 0x180; k <= 0x188; k += 4)
> + __raw_writeb(ffd2[k], intcs_ffd2 + k);
> +
> + for (k = 0x00; k <= 0x3c; k += 4)
> + __raw_writew(ffd5[k], intcs_ffd5 + k);
> +
> + for (k = 0x80; k <= 0x9c; k += 4)
> + __raw_writeb(ffd5[k], intcs_ffd5 + k);
> +}
> Index: linux/arch/arm/mach-shmobile/pm-sh7372.c
> =================================> --- linux.orig/arch/arm/mach-shmobile/pm-sh7372.c
> +++ linux/arch/arm/mach-shmobile/pm-sh7372.c
> @@ -44,6 +44,7 @@
> #define SPDCR 0xe6180008
> #define SWUCR 0xe6180014
> #define SBAR 0xe6180020
> +#define WUPRMSK 0xe6180028
> #define WUPSMSK 0xe618002c
> #define WUPSMSK2 0xe6180048
> #define PSTR 0xe6180080
> @@ -80,6 +81,12 @@ static int pd_power_down(struct generic_
> struct sh7372_pm_domain *sh7372_pd = to_sh7372_pd(genpd);
> unsigned int mask = 1 << sh7372_pd->bit_shift;
>
> + if (sh7372_pd->suspend)
> + sh7372_pd->suspend();
> +
> + if (sh7372_pd->stay_on)
> + return 0;
> +
> if (__raw_readl(PSTR) & mask) {
> unsigned int retry_count;
>
> @@ -106,6 +113,9 @@ static int pd_power_up(struct generic_pm
> unsigned int retry_count;
> int ret = 0;
>
> + if (sh7372_pd->stay_on)
> + goto out;
> +
> if (__raw_readl(PSTR) & mask)
> goto out;
>
> @@ -122,14 +132,23 @@ static int pd_power_up(struct generic_pm
> if (__raw_readl(SWUCR) & mask)
> ret = -EIO;
>
> - out:
> if (!sh7372_pd->no_debug)
> pr_debug("sh7372 power domain up 0x%08x -> PSTR = 0x%08x\n",
> mask, __raw_readl(PSTR));
>
> + out:
> + if (ret = 0 && sh7372_pd->resume)
> + sh7372_pd->resume();
> +
> return ret;
> }
>
> +static void sh7372_a4r_suspend(void)
> +{
> + sh7372_intcs_suspend();
> + __raw_writel(0x300fffff, WUPRMSK); /* avoid wakeup */
> +}
> +
> static bool pd_active_wakeup(struct device *dev)
> {
> return true;
> @@ -186,6 +205,14 @@ struct sh7372_pm_domain sh7372_d4 = {
> .bit_shift = 3,
> };
>
> +struct sh7372_pm_domain sh7372_a4r = {
> + .bit_shift = 5,
> + .gov = &sh7372_always_on_gov,
> + .suspend = sh7372_a4r_suspend,
> + .resume = sh7372_intcs_resume,
> + .stay_on = true,
> +};
> +
> struct sh7372_pm_domain sh7372_a3rv = {
> .bit_shift = 6,
> };
> Index: linux/arch/arm/mach-shmobile/setup-sh7372.c
> =================================> --- linux.orig/arch/arm/mach-shmobile/setup-sh7372.c
> +++ linux/arch/arm/mach-shmobile/setup-sh7372.c
> @@ -991,12 +991,14 @@ void __init sh7372_add_standard_devices(
> sh7372_init_pm_domain(&sh7372_a4lc);
> sh7372_init_pm_domain(&sh7372_a4mp);
> sh7372_init_pm_domain(&sh7372_d4);
> + sh7372_init_pm_domain(&sh7372_a4r);
> sh7372_init_pm_domain(&sh7372_a3rv);
> sh7372_init_pm_domain(&sh7372_a3ri);
> sh7372_init_pm_domain(&sh7372_a3sg);
> sh7372_init_pm_domain(&sh7372_a3sp);
>
> sh7372_pm_add_subdomain(&sh7372_a4lc, &sh7372_a3rv);
> + sh7372_pm_add_subdomain(&sh7372_a4r, &sh7372_a4lc);
>
> platform_add_devices(sh7372_early_devices,
> ARRAY_SIZE(sh7372_early_devices));
> @@ -1020,6 +1022,12 @@ void __init sh7372_add_standard_devices(
> sh7372_add_device_to_domain(&sh7372_a3sp, &dma2_device);
> sh7372_add_device_to_domain(&sh7372_a3sp, &usb_dma0_device);
> sh7372_add_device_to_domain(&sh7372_a3sp, &usb_dma1_device);
> + sh7372_add_device_to_domain(&sh7372_a4r, &iic0_device);
> + sh7372_add_device_to_domain(&sh7372_a4r, &veu0_device);
> + sh7372_add_device_to_domain(&sh7372_a4r, &veu1_device);
> + sh7372_add_device_to_domain(&sh7372_a4r, &veu2_device);
> + sh7372_add_device_to_domain(&sh7372_a4r, &veu3_device);
> + sh7372_add_device_to_domain(&sh7372_a4r, &jpu_device);
> }
>
> void __init sh7372_add_early_devices(void)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Sascha Hauer @ 2011-11-02 10:03 UTC (permalink / raw)
To: Mark Brown
Cc: Mike Frysinger, linux-kernel, Liam Girdwood, Linus Walleij,
Paul Mundt, Tony Lindgren, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <20111101182720.GH10029@opensource.wolfsonmicro.com>
On Tue, Nov 01, 2011 at 06:27:21PM +0000, Mark Brown wrote:
> On Tue, Nov 01, 2011 at 01:50:14PM -0400, Mike Frysinger wrote:
> > On Friday 28 October 2011 18:47:57 Sascha Hauer wrote:
>
> > > > We already have a dummy regulator driver and a fixed voltage regulator
> > > > driver, we shouldn't be adding a third implementation of the same thing.
> > > > Just use the fixed voltage regulator for this.
>
> > > I explained in my mail why I think that the current implementation of
> > > the dummy regulator is not suitable for things apart from debugging.
>
> > your complaints seem to be specific to how the dummy regulator gets hooked in
> > and not in the specific regulator implementation. so it seems like the right
> > thing would be to split the kconfig knobs:
>
> Quite. Sascha, your mail doesn't refer to the implementation of the
> regulator itself at all. Nothing in your changelog even mentions that
> you're introducing a new regulator driver.
>
> I think there's a big abstraction understanding failure here, reading
> your changelog I'm not sure you understand the existing mechainsms that
> are in place. You say:
>
> | This patch allows a board to register dummy supplies for devices
> | which need a regulator but which is not software controllable
> | on this board.
>
> but this is exactly the use case the fixed voltage regulator is there
> for.
>
> > config REGULATOR_DUMMY
> > - bool "Provide a dummy regulator if regulator lookups fail"
> > + bool "Provide a dummy regulator"
> > +config REGULATOR_DUMMY_FALLBACK
> > + bool "Fallback to dummy regulator if lookup fails"
> > + depends on REGULATOR_DUMMY
>
> As I think I said earlier I'd use the fixed regulator for this, all
> Sascha's actually doing here is adding a wrapper to simplify
> registration of that.
There's one difference between the fixed and the dummy regulator though:
The fixed regulator has a voltage. The same dummy regulator instance can
be used for all devices which do not have a software controllable
regulator. I think the same can be done with the fixed regulator aswell,
but the bogus voltage showing up in the sysfs entry might be confusing
to users.
That's the reason I implemented a (second) dummy regulator driver.
Indeed it's not nice to have two of them.
Another approach to this topic would be to allow a board to explicitely
bind to the existing dummy regulator, like the following (error path
should of course be implemented before applying this)
Sascha
8<------------------------------------
[PATCH] regulator: allow boards to bind to the dummy regulator
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/regulator/core.c | 19 +++++++++++++++++++
include/linux/regulator/machine.h | 8 ++++++++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e6a42..a7a38ba 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1046,6 +1046,25 @@ static void unset_regulator_supplies(struct regulator_dev *rdev)
}
}
+int regulator_add_dummy_supply(struct regulator_consumer_supply *supply,
+ int num_supplies)
+{
+ int i, ret;
+
+ for (i = 0; i < num_supplies; i++) {
+ ret = set_consumer_device_supply(dummy_regulator_rdev, NULL,
+ supply[i].dev_name, supply[i].supply);
+ if (ret)
+ goto err_out;
+ }
+
+ return 0;
+err_out:
+ /* FIXME: unset device supply */
+ return ret;
+}
+EXPORT_SYMBOL_GPL(regulator_add_dummy_supply);
+
#define REG_STR_SIZE 64
static struct regulator *create_regulator(struct regulator_dev *rdev,
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index ce3127a..89089cd 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -192,6 +192,8 @@ int regulator_suspend_finish(void);
#ifdef CONFIG_REGULATOR
void regulator_has_full_constraints(void);
void regulator_use_dummy_regulator(void);
+int regulator_add_dummy_supply(struct regulator_consumer_supply *supply,
+ int num_supplies);
#else
static inline void regulator_has_full_constraints(void)
{
@@ -200,6 +202,12 @@ static inline void regulator_has_full_constraints(void)
static inline void regulator_use_dummy_regulator(void)
{
}
+
+static inline int regulator_add_dummy_supply(struct regulator_consumer_supply *supply,
+ int num_supplies)
+{
+ return 0;
+}
#endif
#endif
--
1.7.7
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply related
* Re: [PATCH 1/3] PM / Sleep: Mark devices involved in wakeup signaling
From: Guennadi Liakhovetski @ 2011-11-02 9:29 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux-sh list, Linux PM list, Linux Kernel, Magnus Damm
In-Reply-To: <201110200013.56428.rjw@sisk.pl>
Hi Rafael
Just something, that made me wonder:
On Thu, 20 Oct 2011, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> The generic PM domains code in drivers/base/power/domain.c has
> to avoid powering off domains that provide power to wakeup devices
> during system suspend. Currently, however, this only works for
> wakeup devices directly belonging to the given domain and not for
> their children (or the children of their children and so on).
> Thus, if there's a wakeup device whose parent belongs to a power
> domain handled by the generic PM domains code, the domain will be
> powered off during system suspend preventing the device from
> signaling wakeup.
>
> To address this problem introduce a device flag, power.wakeup_path,
> that will be set during system suspend for all wakeup devices,
> their parents, the parents of their parents and so on. This way,
> all wakeup paths in the device hierarchy will be marked and the
> generic PM domains code will only need to avoid powering off
> domains containing devices whose power.wakeup_path is set.
>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
> drivers/base/power/domain.c | 4 ++--
> drivers/base/power/main.c | 8 +++++++-
> include/linux/pm.h | 1 +
> 3 files changed, 10 insertions(+), 3 deletions(-)
[snip]
> Index: linux/include/linux/pm.h
> =================================> --- linux.orig/include/linux/pm.h
> +++ linux/include/linux/pm.h
> @@ -452,6 +452,7 @@ struct dev_pm_info {
> struct list_head entry;
> struct completion completion;
> struct wakeup_source *wakeup;
> + bool wakeup_path:1;
This is an interesting idea... I'd presume, the compiler is aware, that
one bit is enough for "bool," so, it should choose an optimal
implementation by itself? I checked gcc 4.4.1 on ARM - without the
bitfield notation the compiler just uses one byte in my example. Anyway,
not a request-for-change, just wondering whether you really were trying to
(potentially) save a couple of bits here or what was the motivation.
> #else
> unsigned int should_wakeup:1;
> #endif
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Mark Brown @ 2011-11-01 18:27 UTC (permalink / raw)
To: Mike Frysinger
Cc: Sascha Hauer, linux-kernel, Liam Girdwood, Linus Walleij,
Paul Mundt, Tony Lindgren, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <201111011350.17425.vapier@gentoo.org>
On Tue, Nov 01, 2011 at 01:50:14PM -0400, Mike Frysinger wrote:
> On Friday 28 October 2011 18:47:57 Sascha Hauer wrote:
> > > We already have a dummy regulator driver and a fixed voltage regulator
> > > driver, we shouldn't be adding a third implementation of the same thing.
> > > Just use the fixed voltage regulator for this.
> > I explained in my mail why I think that the current implementation of
> > the dummy regulator is not suitable for things apart from debugging.
> your complaints seem to be specific to how the dummy regulator gets hooked in
> and not in the specific regulator implementation. so it seems like the right
> thing would be to split the kconfig knobs:
Quite. Sascha, your mail doesn't refer to the implementation of the
regulator itself at all. Nothing in your changelog even mentions that
you're introducing a new regulator driver.
I think there's a big abstraction understanding failure here, reading
your changelog I'm not sure you understand the existing mechainsms that
are in place. You say:
| This patch allows a board to register dummy supplies for devices
| which need a regulator but which is not software controllable
| on this board.
but this is exactly the use case the fixed voltage regulator is there
for.
> config REGULATOR_DUMMY
> - bool "Provide a dummy regulator if regulator lookups fail"
> + bool "Provide a dummy regulator"
> +config REGULATOR_DUMMY_FALLBACK
> + bool "Fallback to dummy regulator if lookup fails"
> + depends on REGULATOR_DUMMY
As I think I said earlier I'd use the fixed regulator for this, all
Sascha's actually doing here is adding a wrapper to simplify
registration of that.
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Mike Frysinger @ 2011-11-01 17:50 UTC (permalink / raw)
To: Sascha Hauer
Cc: Mark Brown, linux-kernel, Liam Girdwood, Linus Walleij,
Paul Mundt, Tony Lindgren, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <20111028224757.GG23421@pengutronix.de>
[-- Attachment #1: Type: Text/Plain, Size: 1206 bytes --]
On Friday 28 October 2011 18:47:57 Sascha Hauer wrote:
> On Fri, Oct 28, 2011 at 11:59:31PM +0200, Mark Brown wrote:
> > On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote:
> > > drivers/regulator/Makefile | 2 +-
> > > drivers/regulator/dummy-supply.c | 88
> > > +++++++++++++++++++++++++++++++++++++
> >
> > We already have a dummy regulator driver and a fixed voltage regulator
> > driver, we shouldn't be adding a third implementation of the same thing.
> > Just use the fixed voltage regulator for this.
>
> I explained in my mail why I think that the current implementation of
> the dummy regulator is not suitable for things apart from debugging.
your complaints seem to be specific to how the dummy regulator gets hooked in
and not in the specific regulator implementation. so it seems like the right
thing would be to split the kconfig knobs:
config REGULATOR_DUMMY
- bool "Provide a dummy regulator if regulator lookups fail"
+ bool "Provide a dummy regulator"
+config REGULATOR_DUMMY_FALLBACK
+ bool "Fallback to dummy regulator if lookup fails"
+ depends on REGULATOR_DUMMY
(and then obviously update the .c files accordingly)
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] sh: modify the asm/sh_eth.h to linux/sh_eth.h in sh7757lcr
From: Paul Mundt @ 2011-11-01 7:00 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4E82D17A.7050108@renesas.com>
On Tue, Nov 01, 2011 at 02:54:38PM +0900, Nobuhiro Iwamatsu wrote:
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> ---
> arch/sh/boards/board-sh7757lcr.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
On Tue, Nov 01, 2011 at 02:57:01PM +0900, Nobuhiro Iwamatsu wrote:
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> ---
> arch/sh/Makefile | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Both applied, thanks.
^ permalink raw reply
* [PATCH] sh: Add default uImage rule for sh7757lcr
From: Nobuhiro Iwamatsu @ 2011-11-01 5:57 UTC (permalink / raw)
To: linux-sh
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
arch/sh/Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index 99385d0..3fc0f41 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -80,6 +80,7 @@ defaultimage-$(CONFIG_SH_RSK) := uImage
defaultimage-$(CONFIG_SH_URQUELL) := uImage
defaultimage-$(CONFIG_SH_MIGOR) := uImage
defaultimage-$(CONFIG_SH_AP325RXA) := uImage
+defaultimage-$(CONFIG_SH_SH7757LCR) := uImage
defaultimage-$(CONFIG_SH_7724_SOLUTION_ENGINE) := uImage
defaultimage-$(CONFIG_SH_7206_SOLUTION_ENGINE) := vmlinux
defaultimage-$(CONFIG_SH_7619_SOLUTION_ENGINE) := vmlinux
--
1.7.7
^ permalink raw reply related
* [PATCH] sh: modify the asm/sh_eth.h to linux/sh_eth.h in sh7757lcr
From: Nobuhiro Iwamatsu @ 2011-11-01 5:54 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4E82D17A.7050108@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
arch/sh/boards/board-sh7757lcr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/sh/boards/board-sh7757lcr.c b/arch/sh/boards/board-sh7757lcr.c
index fa2a208..ec8c84c 100644
--- a/arch/sh/boards/board-sh7757lcr.c
+++ b/arch/sh/boards/board-sh7757lcr.c
@@ -18,8 +18,8 @@
#include <linux/mmc/host.h>
#include <linux/mmc/sh_mmcif.h>
#include <linux/mmc/sh_mobile_sdhi.h>
+#include <linux/sh_eth.h>
#include <cpu/sh7757.h>
-#include <asm/sh_eth.h>
#include <asm/heartbeat.h>
static struct resource heartbeat_resource = {
--
1.7.7
^ permalink raw reply related
* Re: [PATCH 2/2 v4] net/smsc911x: Add regulator support
From: Mike Frysinger @ 2011-10-31 18:21 UTC (permalink / raw)
To: Robert Marklund
Cc: netdev, Steve Glendinning, Mathieu Poirier, Paul Mundt, linux-sh,
Sascha Hauer, Tony Lindgren, linux-omap, uclinux-dist-devel,
Linus Walleij
In-Reply-To: <1320064719-14449-1-git-send-email-robert.marklund@stericsson.com>
[-- Attachment #1: Type: Text/Plain, Size: 437 bytes --]
On Monday 31 October 2011 08:38:39 Robert Marklund wrote:
> ChangeLog v3->v4:
> - Remove dual prints and old comment on Mike's request.
> - Split the request_free fucntion on Mike and Sascha request.
would be nice if the enable/disable were split as well ...
> iounmap(pdata->ioaddr);
>
> + (void)smsc911x_enable_disable_resources(pdev, false);
i don't think the (void) cast is necessary
otherwise looks fine
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 2/2 v4] net/smsc911x: Add regulator support
From: Robert Marklund @ 2011-10-31 12:38 UTC (permalink / raw)
To: netdev, Steve Glendinning
Cc: Mathieu Poirier, Robert Marklund, Paul Mundt, linux-sh,
Sascha Hauer, Tony Lindgren, linux-omap, Mike Frysinger,
uclinux-dist-devel, Linus Walleij
Add some basic regulator support for the power pins, as needed
by the ST-Ericsson Snowball platform that powers up the SMSC911
chip using an external regulator.
Platforms that use regulators and the smsc911x and have no defined
regulator for the smsc911x and claim complete regulator
constraints with no dummy regulators will need to provide it, for
example using a fixed voltage regulator. It appears that this may
affect (apart from Ux500 Snowball) possibly these archs/machines
that from some grep:s appear to define both CONFIG_SMSC911X and
CONFIG_REGULATOR:
- ARM Freescale mx3 and OMAP 2 plus, Raumfeld machines
- Blackfin
- Super-H
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-sh@vger.kernel.org
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: uclinux-dist-devel@blackfin.uclinux.org
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v3->v4:
- Remove dual prints and old comment on Mike's request.
- Split the request_free fucntion on Mike and Sascha request.
ChangeLog v2->v3:
- Use bulk regulators on Mark's request.
- Add Cc-fileds to some possibly affected platforms.
ChangeLog v1->v2:
- Don't check for NULL regulators and error out properly if the
regulators can't be found. All platforms using the smsc911x
and the regulator framework simultaneously need to provide some
kind of regulator for it.
---
drivers/net/ethernet/smsc/smsc911x.c | 103 ++++++++++++++++++++++++++++++----
1 files changed, 92 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 8843071..9a2e792 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -44,6 +44,7 @@
#include <linux/module.h>
#include <linux/netdevice.h>
#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
#include <linux/sched.h>
#include <linux/timer.h>
#include <linux/bug.h>
@@ -88,6 +89,8 @@ struct smsc911x_ops {
unsigned int *buf, unsigned int wordcount);
};
+#define SMSC911X_NUM_SUPPLIES 2
+
struct smsc911x_data {
void __iomem *ioaddr;
@@ -138,6 +141,9 @@ struct smsc911x_data {
/* register access functions */
const struct smsc911x_ops *ops;
+
+ /* regulators */
+ struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
};
/* Easy access to information */
@@ -362,6 +368,68 @@ out:
spin_unlock_irqrestore(&pdata->dev_lock, flags);
}
+/*
+ * Enable or disable resources, currently just regulators.
+ */
+static int smsc911x_enable_disable_resources(struct platform_device *pdev,
+ bool enable)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ /* enable/disable regulators */
+ if (enable) {
+ ret = regulator_bulk_enable(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ if (ret)
+ netdev_err(ndev, "failed to enable regulators %d\n",
+ ret);
+ } else
+ ret = regulator_bulk_disable(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ return ret;
+}
+
+/*
+ * Request resources, currently just regulators.
+ *
+ * The SMSC911x has two power pins: vddvario and vdd33a, in designs where
+ * these are not always-on we need to request regulators to be turned on
+ * before we can try to access the device registers.
+ */
+static int smsc911x_request_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ /* Request regulators */
+ pdata->supplies[0].supply = "vdd33a";
+ pdata->supplies[1].supply = "vddvario";
+ ret = regulator_bulk_get(&pdev->dev,
+ ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ if (ret)
+ netdev_err(ndev, "couldn't get regulators %d\n",
+ ret);
+ return ret;
+}
+
+/*
+ * Free resources, currently just regulators.
+ *
+ */
+static void smsc911x_free_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+
+ /* Free regulators */
+ regulator_bulk_free(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+}
+
/* waits for MAC not busy, with timeout. Only called by smsc911x_mac_read
* and smsc911x_mac_write, so assumes mac_lock is held */
static int smsc911x_mac_complete(struct smsc911x_data *pdata)
@@ -2092,6 +2160,9 @@ static int __devexit smsc911x_drv_remove(struct platform_device *pdev)
iounmap(pdata->ioaddr);
+ (void)smsc911x_enable_disable_resources(pdev, false);
+ smsc911x_free_resources(pdev);
+
free_netdev(dev);
return 0;
@@ -2218,10 +2289,20 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
pdata->dev = dev;
pdata->msg_enable = ((1 << debug) - 1);
+ platform_set_drvdata(pdev, dev);
+
+ retval = smsc911x_request_resources(pdev);
+ if (retval)
+ goto out_return_resources;
+
+ retval = smsc911x_enable_disable_resources(pdev, true);
+ if (retval)
+ goto out_disable_resources;
+
if (pdata->ioaddr = NULL) {
SMSC_WARN(pdata, probe, "Error smsc911x base address invalid");
retval = -ENOMEM;
- goto out_free_netdev_2;
+ goto out_disable_resources;
}
retval = smsc911x_probe_config_dt(&pdata->config, np);
@@ -2233,7 +2314,7 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
if (retval) {
SMSC_WARN(pdata, probe, "Error smsc911x config not found");
- goto out_unmap_io_3;
+ goto out_disable_resources;
}
/* assume standard, non-shifted, access to HW registers */
@@ -2244,7 +2325,7 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
retval = smsc911x_init(dev);
if (retval < 0)
- goto out_unmap_io_3;
+ goto out_disable_resources;
/* configure irq polarity and type before connecting isr */
if (pdata->config.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH)
@@ -2264,15 +2345,13 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
if (retval) {
SMSC_WARN(pdata, probe,
"Unable to claim requested irq: %d", dev->irq);
- goto out_unmap_io_3;
+ goto out_free_irq;
}
- platform_set_drvdata(pdev, dev);
-
retval = register_netdev(dev);
if (retval) {
SMSC_WARN(pdata, probe, "Error %i registering device", retval);
- goto out_unset_drvdata_4;
+ goto out_free_irq;
} else {
SMSC_TRACE(pdata, probe,
"Network interface: \"%s\"", dev->name);
@@ -2321,12 +2400,14 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
out_unregister_netdev_5:
unregister_netdev(dev);
-out_unset_drvdata_4:
- platform_set_drvdata(pdev, NULL);
+out_free_irq:
free_irq(dev->irq, dev);
-out_unmap_io_3:
+out_disable_resources:
+ (void)smsc911x_enable_disable_resources(pdev, false);
+out_return_resources:
+ smsc911x_free_resources(pdev);
+ platform_set_drvdata(pdev, NULL);
iounmap(pdata->ioaddr);
-out_free_netdev_2:
free_netdev(dev);
out_release_io_1:
release_mem_region(res->start, resource_size(res));
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()
From: Deepthi Dharwar @ 2011-10-31 7:44 UTC (permalink / raw)
To: Arjan van de Ven
Cc: khilman, venki, ak, len.brown, peterz, rjw, santosh.shilimkar,
lenb, linux-pm, linux-sh, linux-kernel, linux-acpi, linux-pm,
linux-omap, linux-arm-kernel
In-Reply-To: <4EAABB07.3000305@linux.intel.com>
On Friday 28 October 2011 07:54 PM, Arjan van de Ven wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/28/2011 3:50 AM, Deepthi Dharwar wrote:
>> The cpuidle_device->prepare() mechanism causes updates to the
>> cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
>> to tell the governor not to chose a state on a per-cpu basis at
>> run-time. State demotion is now handled by the driver and it returns
>> the actual state entered. Hence, this mechanism is not required.
>> Also this removes per-cpu flags from cpuidle_state enabling
>> it to be made global.
>>
>
> having worked on some newer platforms....
> this one is really still needed. doing this inside the actual states
> does not work,
> because if the deepest 3 states are invalid, the same (somewhat
> expensive) test would have to be done 3 times,
> and each of the states would have to fail before the 4th one gets chosen.
> that's just not going to work
>
> (in the state handler you can't know what other state to fall back to,
> and especially not how to enter such a fallback state)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iQEcBAEBAgAGBQJOqrsGAAoJEEHdSxh4DVnEu7EH/i5lEJctBAIubJOcZz/tvBFp
> XYmAe/HqNtSXeHOVsJkTf8y4ppE8487exF7xxMik4GRN0CZNCtkyMezqDVu+eDim
> O/UUbScsAc5cSY6mkjOFXLFup+mi1nkRUnAbxXEyTMhWwcbfr2OvcuO7l7TmATML
> hu87P3PVEafEop3q2+uWMc57fFxnNFfEDqRx6N9V+OJKV5dHrRYL4G4E01fYGFLo
> xTR0IW7nB15L0C29zk9uk/Dqow8SoJZA83c7p7AieP5zdntb6p7noIf03qmdp19f
> fulwMwembCHivo+pLO+jAMhKD1T6VYoCyiYW0LHrQ2E07fayBhFJCxlazgKFcl0> =FL6o
> -----END PGP SIGNATURE-----
>
Hi Arjan,
Thanks for the review.
We retain the dev->prepare() routine and CPUIDLE_FLAG_IGNORE
but still allow the dev->enter() to return index ?
So by retaining it, transition to the idle states
would be much quicker in case one more states are invalid.
Also to note is that in the newer design, we have split the
cpuidle_state structure. One global struct, cpuidle_states[] that
contains all the state related information including flags, and
the other cpuidle_device that contain statistics and other data
that are per-cpu basis.
So the flags are not per cpu per state basis but
maintained globally as per state basis.
So if we have to enable CPUIDLE_FLAG_IGNORE flag in this
current new design, then I am thinking if we needed to have this
on a per-cpu basis. If so, then flags have to be moved into cpuidle_device
struct rather than cpuidle_state struct.
Is it a good idea to retain these flags as global (part of cpuidle_states)
or make it per-cpu basis ?
-Thanks
Deepthi
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Mark Brown @ 2011-10-29 17:42 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-kernel, Liam Girdwood, Linus Walleij, Paul Mundt,
Tony Lindgren, Mike Frysinger, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <20111028224757.GG23421@pengutronix.de>
On Sat, Oct 29, 2011 at 12:47:57AM +0200, Sascha Hauer wrote:
> My main concern with the fixed regulator is that it needs quite much
> boilerplate code just to say that we have no regulator at all for a
> given device. That could also be handled with a helper function which
> registers a fixed regulator and only takes the regulator_consumer_supply
> as an argument. Would that be ok for you?
All you're actually doing in this code is adding a function to register
a new type of regulator which is exactly equivalent to what the existing
regulators provide - there's nothing particularly wrong with the helper
function but defining an entirely new regulator type for it doesn't seem
useful.
^ permalink raw reply
* Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
From: Mike Frysinger @ 2011-10-28 23:33 UTC (permalink / raw)
To: Sascha Hauer
Cc: Linus Walleij, netdev, Steve Glendinning, Mathieu Poirer,
Robert Marklund, Paul Mundt, linux-sh, Tony Lindgren, linux-omap,
uclinux-dist-devel, Linus Walleij
In-Reply-To: <20111028203353.GE23421@pengutronix.de>
On Fri, Oct 28, 2011 at 22:33, Sascha Hauer wrote:
> On Thu, Oct 27, 2011 at 02:48:11PM +0200, Linus Walleij wrote:
>> +/*
>> + * Request or free resources, currently just regulators.
>> + *
>> + * The SMSC911x has two power pins: vddvario and vdd33a, in designs where
>> + * these are not always-on we need to request regulators to be turned on
>> + * before we can try to access the device registers.
>> + */
>> +static int smsc911x_request_free_resources(struct platform_device *pdev,
>> + bool request)
>
> I had to look twice at this function name. First I thought "request the
> free resources?", which other resources would you request if not the
> free ones? I think it would be nicer to have two functions instead.
> Just my 2 cents.
i'll add my 2 cents and we'll almost have a nickle. maybe i'm dense,
but i had to look (more than) twice at both funcs before i could get
my head around what was happening. no, it's not complicated, but it
is unusual in the kernel world. either that or i haven't read enough
kernel code to consider this a common paradigm. hopefully it's the
former ;).
-mike
^ permalink raw reply
* Re: [PATCH] regulator: provide dummy supply support
From: Mike Frysinger @ 2011-10-28 23:22 UTC (permalink / raw)
To: Mark Brown
Cc: Sascha Hauer, linux-kernel, Liam Girdwood, Linus Walleij,
Paul Mundt, Tony Lindgren, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <20111028215703.GB30339@opensource.wolfsonmicro.com>
On Fri, Oct 28, 2011 at 23:57, Mark Brown wrote:
> On Fri, Oct 28, 2011 at 10:26:57PM +0200, Sascha Hauer wrote:
>> The following patch allows it for boards to register a dummy supply for
>> devices for which no software controllable regulator is available. The
>> current CONFIG_REGULATOR_DUMMY and (unused) regulator_use_dummy_regulator()
>
> Please don't send cover letters for single patch serieses, if there's
> content it should probably be in the changelog...
sorry for the additional noise, but +1
-mike
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Mike Frysinger @ 2011-10-28 23:16 UTC (permalink / raw)
To: Sascha Hauer
Cc: Mark Brown, linux-kernel, Liam Girdwood, Linus Walleij,
Paul Mundt, Tony Lindgren, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <20111028224757.GG23421@pengutronix.de>
On Sat, Oct 29, 2011 at 00:47, Sascha Hauer wrote:
> On Fri, Oct 28, 2011 at 11:59:31PM +0200, Mark Brown wrote:
>> On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote:
>>
>> > drivers/regulator/Makefile | 2 +-
>> > drivers/regulator/dummy-supply.c | 88 +++++++++++++++++++++++++++++++++++++
>>
>> We already have a dummy regulator driver and a fixed voltage regulator
>> driver, we shouldn't be adding a third implementation of the same thing.
>> Just use the fixed voltage regulator for this.
>
> I explained in my mail why I think that the current implementation of
> the dummy regulator is not suitable for things apart from debugging.
>
> My main concern with the fixed regulator is that it needs quite much
> boilerplate code just to say that we have no regulator at all for a
> given device. That could also be handled with a helper function which
> registers a fixed regulator and only takes the regulator_consumer_supply
> as an argument. Would that be ok for you?
i think Mark's point is that we have code in dummy.c already to
provide a dummy regulator. so your needs sounds like it could be
satisfied with some Kconfig/ifdef massaging and the existing
drivers/regulator/dummy.c rather than introducing a completely
parallel file that is always enabled ?
-mike
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Sascha Hauer @ 2011-10-28 22:47 UTC (permalink / raw)
To: Mark Brown
Cc: linux-kernel, Liam Girdwood, Linus Walleij, Paul Mundt,
Tony Lindgren, Mike Frysinger, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <20111028215931.GA30366@opensource.wolfsonmicro.com>
On Fri, Oct 28, 2011 at 11:59:31PM +0200, Mark Brown wrote:
> On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote:
>
> > drivers/regulator/Makefile | 2 +-
> > drivers/regulator/dummy-supply.c | 88 +++++++++++++++++++++++++++++++++++++
>
> We already have a dummy regulator driver and a fixed voltage regulator
> driver, we shouldn't be adding a third implementation of the same thing.
> Just use the fixed voltage regulator for this.
I explained in my mail why I think that the current implementation of
the dummy regulator is not suitable for things apart from debugging.
My main concern with the fixed regulator is that it needs quite much
boilerplate code just to say that we have no regulator at all for a
given device. That could also be handled with a helper function which
registers a fixed regulator and only takes the regulator_consumer_supply
as an argument. Would that be ok for you?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH] regulator: Provide dummy supply support
From: Mark Brown @ 2011-10-28 21:59 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-kernel, Liam Girdwood, Linus Walleij, Paul Mundt,
Tony Lindgren, Mike Frysinger, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <1319833618-25190-2-git-send-email-s.hauer@pengutronix.de>
On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote:
> drivers/regulator/Makefile | 2 +-
> drivers/regulator/dummy-supply.c | 88 +++++++++++++++++++++++++++++++++++++
We already have a dummy regulator driver and a fixed voltage regulator
driver, we shouldn't be adding a third implementation of the same thing.
Just use the fixed voltage regulator for this.
^ permalink raw reply
* Re: [PATCH] regulator: provide dummy supply support
From: Mark Brown @ 2011-10-28 21:57 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-kernel, Liam Girdwood, Linus Walleij, Paul Mundt,
Tony Lindgren, Mike Frysinger, linux-sh, linux-omap,
uclinux-dist-devel
In-Reply-To: <1319833618-25190-1-git-send-email-s.hauer@pengutronix.de>
On Fri, Oct 28, 2011 at 10:26:57PM +0200, Sascha Hauer wrote:
> The following patch allows it for boards to register a dummy supply for
> devices for which no software controllable regulator is available. The
> current CONFIG_REGULATOR_DUMMY and (unused) regulator_use_dummy_regulator()
Please don't send cover letters for single patch serieses, if there's
content it should probably be in the changelog...
^ 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