* confusion regarding the CMD19 and CMD21 in eMMC/SD card spec
From: Girish K S @ 2011-09-16 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110916044706.GA4030@lovegaga>
Hello Aaron Lu,
please check the mmc 4.5 specification CMD21 is
tuning command.
regards
Girish K S
On 16 September 2011 10:17, Aaron Lu <aaron.lu@amd.com> wrote:
> On Fri, Sep 16, 2011 at 09:41:04AM +0530, Girish K S wrote:
>> but there is only one host controller to handle these commands.
>> the generic sdhci driver has cmd19 hard coded, thats the reason I
>> asked the question.
>> you can also check it in the function sdhci_execute_tuning it is hard coded as
>> cmd.opcode = MMC_SEND_TUNING_BLOCK; where the macro value is 19.
>> So in case of SD card insertion it will send a SEND_TUNING_BLOCK
>> command to the device. but if
>> MMC card is inserted then it will send a BUS_TEST_W command to the device.
>
> sdhci_execute_tuning will only be called if the inserted card is a sd card
> and it is operating at SDR104 or SDR50 mode(UHS-I).
>
> The host's tuning function is called from the mmc_sd_init_uhs_card,
> and for a mmc card, there is no chance of that function being called.
>
> -Aaron
>
>
^ permalink raw reply
* [PATCH v2 0/5] CPU PM notifiers
From: Santosh @ 2011-09-16 4:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315060755-4613-1-git-send-email-santosh.shilimkar@ti.com>
On Saturday 03 September 2011 08:09 PM, Santosh Shilimkar wrote:
> Updates V2:
> - The CPU PM notifiers are moved to generic level instead of keeping
> it ARM specific as per Rafael's comment.
> - To avoid every driver duplicating the sys-core ops and cpu pm notfiers,
> the CPU PM common notifier is registering it in one place so that
> suspend is taken care.
> - CPU COMPLEX events are renamed to more appropriate CPU CLUSTER.
> - GIC distributor is not disabled to avoid the live locks. This is
> observed with CPUIDLE cases where at time CPU cluster fails to
> transition to low power states. As such there was no need to
> disable distributor in first place since on cluster reset, it
> will get disabled anyways.
> - In VFP code, syscore ops are dropped in favour of CPU PM
> notifiers since S2R is already handled in core CPU PM notifiers.
> - The last patch is an independent patch but can be pushed along with
> the other GIC changes done here.
>
> V1: [http://lwn.net/Articles/447259/]
>
> This patch set tries to address concerns with platform pm code
> calling into the driver for every block in the Cortex A9s
> during idle, hotplug, and suspend. The first patch adds cpu pm
> notifiers that can be called by platform code, the second uses
> the notifier to save and restore the GIC state, and the third
> saves the VFP state.
>
> The notifiers are used for two types of events, CPU PM events and
> CPU cluster PM events. CPU PM events are used to save and restore
> per-cpu context when a single CPU is preparing to enter or has
> just exited a low power state. For example, the VFP saves the
> last thread context, and the GIC saves banked CPU registers.
>
> CPU cluster events are used after all the CPUs in a power domain
> have been prepared for the low power state. The GIC uses these
> events to save global register state.
>
> L2 cache is not covered by this patch set, as the determination
> of when the L2 is reset and when it is retained is
> platform-specific, and most of the APIs necessary are already
>
>
> The series is tested with OMAP4 with S2R and CPUIDLE.
>
> The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132:
>
> Linux 3.1-rc4 (2011-08-28 21:16:01 -0700)
>
> Colin Cross (5):
> cpu_pm: Add cpu power management notifiers
> cpu_pm: call notifiers during suspend
> ARM: gic: Use cpu pm notifiers to save gic state
> ARM: vfp: Use cpu pm notifiers to save vfp state
> ARM: gic: Allow gic arch extensions to provide irqchip flags
>
Thanks all for the reviews and testing of this series.
I am going to add these patches as part of my pull request
to Russell for the 3.2.
Regards
Santosh
^ permalink raw reply
* [PATCH 6/6] ARM: zImage: prevent constant copy+rebuild of lib1funcs.S
From: Nicolas Pitre @ 2011-09-16 4:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E72C96F.5000203@codeaurora.org>
On Thu, 15 Sep 2011, Stephen Boyd wrote:
> On 09/13/11 22:41, Nicolas Pitre wrote:
> > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> >
> > The rule to copy this file doesn't have to be forced. However
> > lib1funcs.[So] have to be listed amongst the targets.
> >
> > This prevents zImage from being recreated needlessly.
> >
> > Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> > ---
> > arch/arm/boot/compressed/Makefile | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> > index ce2bef536e..db1fd260ed 100644
> > --- a/arch/arm/boot/compressed/Makefile
> > +++ b/arch/arm/boot/compressed/Makefile
> > @@ -112,7 +112,7 @@ endif
> >
> > targets := vmlinux vmlinux.lds \
> > piggy.$(suffix_y) piggy.$(suffix_y).o \
> > - font.o font.c head.o misc.o $(OBJS)
> > + lib1funcs.o lib1funcs.S font.o font.c head.o misc.o $(OBJS)
> >
> > # Make sure files are removed during clean
> > extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs)
> > @@ -147,7 +147,7 @@ LDFLAGS_vmlinux += -T
> > # For __aeabi_uidivmod
> > lib1funcs = $(obj)/lib1funcs.o
> >
> > -$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S FORCE
> > +$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S
> > $(call cmd,shipped)
> >
> > # We need to prevent any GOTOFF relocs being used with references
>
> I already posted a very similar patch and put it into Russell's patch
> tracker. Can't you just use that instead?
I remember this was discussed, but I forgot that you actually did send a
patch. Either version is fine with me.
Hmmm. My version has been merged in RMK's devel-stable branch already
though.
Nicolas
^ permalink raw reply
* confusion regarding the CMD19 and CMD21 in eMMC/SD card spec
From: Aaron Lu @ 2011-09-16 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGxe1ZG4QjwB5OfrxupG_C+DtQ7sTQ4_EURaF-QrqPPSA3A0jw@mail.gmail.com>
On Fri, Sep 16, 2011 at 09:41:04AM +0530, Girish K S wrote:
> but there is only one host controller to handle these commands.
> the generic sdhci driver has cmd19 hard coded, thats the reason I
> asked the question.
> you can also check it in the function sdhci_execute_tuning it is hard coded as
> cmd.opcode = MMC_SEND_TUNING_BLOCK; where the macro value is 19.
> So in case of SD card insertion it will send a SEND_TUNING_BLOCK
> command to the device. but if
> MMC card is inserted then it will send a BUS_TEST_W command to the device.
sdhci_execute_tuning will only be called if the inserted card is a sd card
and it is operating at SDR104 or SDR50 mode(UHS-I).
The host's tuning function is called from the mmc_sd_init_uhs_card,
and for a mmc card, there is no chance of that function being called.
-Aaron
^ permalink raw reply
* confusion regarding the CMD19 and CMD21 in eMMC/SD card spec
From: Girish K S @ 2011-09-16 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0356427A-B949-4DA6-9F5D-FE0DD54AEDFF@marvell.com>
but there is only one host controller to handle these commands.
the generic sdhci driver has cmd19 hard coded, thats the reason I
asked the question.
you can also check it in the function sdhci_execute_tuning it is hard coded as
cmd.opcode = MMC_SEND_TUNING_BLOCK; where the macro value is 19.
So in case of SD card insertion it will send a SEND_TUNING_BLOCK
command to the device. but if
MMC card is inserted then it will send a BUS_TEST_W command to the device.
correct me if i am wrong
regards
Girish
On 15 September 2011 21:53, Philip Rakity <prakity@marvell.com> wrote:
>
> Different committee's --- Different standards.
>
> There is no issue with overlap.
>
>
> On Sep 15, 2011, at 4:58 AM, Girish K S wrote:
>
>> Dear all,
>> ? ? ? ? ? ? The eMMC 4.5 specification mentions that the CMD21 in
>> class 2 is a SEND_TUNING BLOCK command. where as the SD card
>> specification
>> in the given link says CMD19 in class 2 is the SEND_TUNING_BLOCK
>> http://www.scribd.com/doc/50685191/53/Figure-4-8-Send-Tuning-Block-Command.
>> Also the implementation in the drivers/mmc/host/sdhci.c uses the CMD19
>> as the SEND_TUNING_BLOCK.
>> Can anybody clarify why there is overlapping in this command number.
>> May be my understand is wrong.
>>
>> In the MMC spec the CMD19 is BUS_TEST_W in class 0 and CMD21 is
>> reserved till eMMC 4.41 version.
>> But in the SD specification (given link) CMD19 is SEND_TUNING_BLOCK
>> and CMD21 is reserved.
>>
>> Thanks and regards
>> Girish K S
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH 6/6] ARM: zImage: prevent constant copy+rebuild of lib1funcs.S
From: Stephen Boyd @ 2011-09-16 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315978906-15829-7-git-send-email-nico@fluxnic.net>
On 09/13/11 22:41, Nicolas Pitre wrote:
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> The rule to copy this file doesn't have to be forced. However
> lib1funcs.[So] have to be listed amongst the targets.
>
> This prevents zImage from being recreated needlessly.
>
> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> ---
> arch/arm/boot/compressed/Makefile | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index ce2bef536e..db1fd260ed 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -112,7 +112,7 @@ endif
>
> targets := vmlinux vmlinux.lds \
> piggy.$(suffix_y) piggy.$(suffix_y).o \
> - font.o font.c head.o misc.o $(OBJS)
> + lib1funcs.o lib1funcs.S font.o font.c head.o misc.o $(OBJS)
>
> # Make sure files are removed during clean
> extra-y += piggy.gzip piggy.lzo piggy.lzma lib1funcs.S $(libfdt) $(libfdt_hdrs)
> @@ -147,7 +147,7 @@ LDFLAGS_vmlinux += -T
> # For __aeabi_uidivmod
> lib1funcs = $(obj)/lib1funcs.o
>
> -$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S FORCE
> +$(obj)/lib1funcs.S: $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.S
> $(call cmd,shipped)
>
> # We need to prevent any GOTOFF relocs being used with references
I already posted a very similar patch and put it into Russell's patch
tracker. Can't you just use that instead?
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7016/1
http://lists.arm.linux.org.uk/lurker/message/20110812.190002.18f88875.en.html
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver
From: DebBarma, Tarun Kanti @ 2011-09-16 3:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915170548.GB2284@atomide.com>
On Thu, Sep 15, 2011 at 10:35 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [110915 09:24]:
>> * Mohammed, Afzal <afzal@ti.com> [110915 01:13]:
>> >
>> > We need clocksource & clockevent to be able to work with
>> > timers requiring addition of offsets. Without this AM335X,
>> > TI816X and TI814X SoC's will not boot.
>>
>> OK. Then how about let's do the following things:
>>
>> 1. Modify the inline access functions to take the PEND and others
>> ? ?if needed registers as a parameter
>>
>> 2. Modify mach-omap2/timer.c to initialize the PEND and others
>> ? ?in the SoC specific timer_init function
>
> Also, let's do these changes first then rebase the dmtimer
> series on those changes as it simplifies the dmtimer series
> a bit.
Alright.... I will start with this.
--
Tarun
>
> Regards,
>
> Tony
>
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Barry Song @ 2011-09-16 3:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915083248.GG6267@n2100.arm.linux.org.uk>
2011/9/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Thu, Sep 15, 2011 at 09:39:39AM +0800, Shawn Guo wrote:
>> On Wed, Sep 14, 2011 at 09:42:38AM +0100, Russell King - ARM Linux wrote:
>> > I'm unconvinced about the wise-ness of this. ?We read-modify-write the
>> > auxillary control register, which means some bits are preserved from
>> > the initial boot. ?If the boot loader sets the L2 cache up for normal
>> > boot and not for resume, we'll end up with different L2 cache settings.
>> >
>> > We've historically seen this kind of thing with boot loaders over the
>> > years, to the point where systems boot at one CPU clock rate but resume
>> > at some other CPU clock rate.
>> >
>> I would think this is a problem in the kernel. ?Kernel initialization
>> code should put all these stuff into a known state to ensure boot and
>> resume of the kernel do not result in a different state, shouldn't it?
>
> grep the kernel for l2x0_init() and look at the mask and value registers.
> Note that any bit set in the mask is preserved from boot time.
if we have a save/restore interface, it looks it will be very
complicated. different l2 need to save different registers.
pl310:
tag-latency(not all pl310 has TAG_LATENCY_CTRL ctrl setting)
arm,data-latency(not all pl310 has L2X0_DATA_LATENCY_CTRL ctrl setting)
arm,filter-ranges(not all pl310 has filter range setting)
L2X0_AUX_CTRL
L2X0_CTRL
So the save interface needs to know what should be saved. but who can
tell them those if the save interface is not in SoC-specific file but
in arch/arm/mm/cache-l2x0.c?
when we resume, we must disable l2 if bootloader has enabled it and
restore all registers.
so it looks like making l2 resume specific to chip is also the right
choice even for chips which will lose l2 in suspend cycles.
-barry
^ permalink raw reply
* [alsa-devel] [RFC v2 PATCH 1/1] ASoC: soc-core: symmetry checking for each DAIs separately
From: Dong Aisheng @ 2011-09-16 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E5E1285.8020508@ti.com>
Hi Mark,
2011/8/31 Liam Girdwood <lrg@ti.com>:
> On 30/08/11 03:54, Dong Aisheng-B29396 wrote:
>>> -----Original Message-----
>>> From: Tabi Timur-B04825
>>> Sent: Tuesday, August 30, 2011 4:35 AM
>>> To: Dong Aisheng-B29396
>>> Cc: alsa-devel at alsa-project.org; lars at metafoo.de; s.hauer at pengutronix.de;
>>> broonie at opensource.wolfsonmicro.com; w.sang at pengutronix.de; lrg at ti.com;
>>> linux-arm-kernel at lists.infradead.org
>>> Subject: Re: [alsa-devel] [RFC v2 PATCH 1/1] ASoC: soc-core: symmetry
>>> checking for each DAIs separately
>>>
>>> On Mon, Aug 29, 2011 at 4:15 AM, Dong Aisheng <b29396@freescale.com>
>>> wrote:
>>>> The orginal code does not cover the case that one DAI such as codec
>>>> may be shared between other two DAIs(CPU).
>>>
>>> Can you give me an example of how this can occur?
>>>
>>
>> Pls check the following case used in mx28evk.
>> static struct snd_soc_dai_link mxs_sgtl5000_dai[] = {
>> ? ? ? ? {
>> ? ? ? ? ? ? ? ? .name ? ? ? ? ? = "HiFi Tx",
>> ? ? ? ? ? ? ? ? .stream_name ? ?= "HiFi Playback",
>> ? ? ? ? ? ? ? ? .codec_dai_name = "sgtl5000",
>> ? ? ? ? ? ? ? ? .codec_name ? ? = "sgtl5000.0-000a",
>> ? ? ? ? ? ? ? ? .cpu_dai_name ? = "mxs-saif.0",
>> ? ? ? ? ? ? ? ? .platform_name ?= "mxs-pcm-audio.0",
>> ? ? ? ? ? ? ? ? .ops ? ? ? ? ? ?= &mxs_sgtl5000_hifi_ops,
>> ? ? ? ? }, {
>> ? ? ? ? ? ? ? ? .name ? ? ? ? ? = "HiFi Rx",
>> ? ? ? ? ? ? ? ? .stream_name ? ?= "HiFi Capture",
>> ? ? ? ? ? ? ? ? .codec_dai_name = "sgtl5000",
>> ? ? ? ? ? ? ? ? .codec_name ? ? = "sgtl5000.0-000a",
>> ? ? ? ? ? ? ? ? .cpu_dai_name ? = "mxs-saif.1",
>> ? ? ? ? ? ? ? ? .platform_name ?= "mxs-pcm-audio.1",
>> ? ? ? ? ? ? ? ? .ops ? ? ? ? ? ?= &mxs_sgtl5000_hifi_ops,
>> ? ? ? ? },
>> };
>> You can also refer to:
>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/129789/focus=129839
>>
>
> Timur, iirc your driver has some special symmetry requirement (maybe something todo with having 2 DAIs) ?
>
> I assume this is OK for you too ?
>
> Acked-by: Liam Girdwood <lrg@ti.com>
>
Can you apply this?
Regards
Dong Aisheng
^ permalink raw reply
* [alsa-devel] [PATCH v3 1/1] ASoC: mxs-saif: add record function
From: Dong Aisheng @ 2011-09-16 2:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABS+qY12ChK=aA-eOERH5ATWKcQdp3wE48SsBNcpe0nDzXWOMw@mail.gmail.com>
Hi Mark,
2011/9/9 Girdwood, Liam <lrg@ti.com>:
> On 7 September 2011 13:51, Dong Aisheng <b29396@freescale.com> wrote:
>
>> 1. add different clkmux mode handling
>> SAIF can use two instances to implement full duplex (playback &
>> recording) and record saif may work on EXTMASTER mode which is
>> using other saif's BITCLK&LRCLK.
>>
>> The clkmux mode could be set in pdata->init() in mach-specific code.
>> For generic saif driver, it only needs to know who is his master
>> and the master id is also provided in mach-specific code.
>>
>> 2. support playback and capture simutaneously however the sample
>> rates can not be different due to hw limitation.
>>
>> Signed-off-by: Dong Aisheng <b29396@freescale.com>
>> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
>> Cc: Liam Girdwood <lrg@ti.com>
>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Wolfram Sang <w.sang@pengutronix.de>
>>
>> ---
>> Changes since v2:
>> ?* remove mach-specific code(clkmux in DIGCTL) out of saif driver
>> ?For supporting EXTMASTER mode, SAIF only nees to know who's
>> ?its master and the master id is provided by mach layer according
>> ?to different clkmux setting.
>> ?So we need to add a pdata->get_master_id();
>>
>> Changes since v1:
>> ?* calc the delay based on the rate
>> ?* change the saif.h #ifndef micro to match the directory
>> ---
>> ?include/sound/saif.h ? ? | ? 16 +++++
>> ?sound/soc/mxs/mxs-saif.c | ?145
>> +++++++++++++++++++++++++++++++++++++++++-----
>> ?sound/soc/mxs/mxs-saif.h | ? ?4 +
>> ?3 files changed, 151 insertions(+), 14 deletions(-)
>>
>>
> Acked-by Liam Girdwood <lrg@ti.com>
>
Can you apply this?
Also with the tag:
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH v8 0/4] add the GPMI-NAND support for imx23/imx28
From: Huang Shijie @ 2011-09-16 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314169643-23425-1-git-send-email-b32955@freescale.com>
Hi Sascha:
Is this patch set ok now?
thanks
Huang Shijie
> The patch set is based on tag v3.1-rc2 of linus's tree.
> and it can be git-am to Artem's tree:
> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>
> The general-purpose media interface(GPMI) controller is a flexible interface
> to up to several NAND flashs.
>
> The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
>
> With the help of BCH, the GPMI controller can choose to do the hardware ECC or
> not.
>
> v7 --> v8:
> [0] add header file to fix compiling error.
>
> v6 --> v7:
> [0] rename RES_SIZE to GPMI_NAND_RES_SIZE.
> [1] move gpmi-nand.h to `include/linux/mtd/` directory.
> [2] remove comment for new pad control.
> [3] others
>
> v5 --> v6:
> [0] rename `gpmi-nfc` to `gpmi-nand`.
> [1] remove ->exit() in structure gpmi_nand_platform_data{}.
> [2] drop the macros for the resource's definition of gpmi-nand.
> [3] add a new pad control `MXS_PAD_CTRL_12MA`.
> [4] others.
>
> v4 --> v5:
> [0] split out the mach code and the machine code.
>
> v3 --> v4:
> merge the GPMI-NFC device code to the new branch.
>
> Huang Shijie (4):
> ARM: mxs: add GPMI-NAND support for imx23/imx28
> ARM: mxs: add new a pad control
> ARM: mxs/mx23evk: add GPMI-NAND device
> ARM: mxs/mx28evk: add GPMI-NAND device
>
> arch/arm/mach-mxs/Kconfig | 2 +
> arch/arm/mach-mxs/clock-mx23.c | 1 +
> arch/arm/mach-mxs/clock-mx28.c | 1 +
> arch/arm/mach-mxs/devices-mx23.h | 4 +
> arch/arm/mach-mxs/devices-mx28.h | 4 +
> arch/arm/mach-mxs/devices/Kconfig | 3 +
> arch/arm/mach-mxs/devices/Makefile | 1 +
> arch/arm/mach-mxs/devices/platform-gpmi-nand.c | 109 +++++++++++++++++++++++
> arch/arm/mach-mxs/include/mach/devices-common.h | 10 ++
> arch/arm/mach-mxs/include/mach/iomux.h | 1 +
> arch/arm/mach-mxs/mach-mx23evk.c | 36 ++++++++
> arch/arm/mach-mxs/mach-mx28evk.c | 36 ++++++++
> include/linux/mtd/gpmi-nand.h | 68 ++++++++++++++
> 13 files changed, 276 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-mxs/devices/platform-gpmi-nand.c
> create mode 100644 include/linux/mtd/gpmi-nand.h
>
^ permalink raw reply
* [PATCH v2] ARM: CSR: call l2x0_of_init to init L2 cache of SiRFprimaII
From: Barry Song @ 2011-09-16 2:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring <robherring2@gmail.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
-v2:
add specific "compatible" string of the l2x0 device node, and making sure
that we have something specific to prima2 in it.
Note: This patch depends on[1][2]
[1]Rob Herring
ARM: 7009/1: l2x0: Add OF based initialization
http://www.spinics.net/lists/arm-kernel/msg131123.html
it has been in rmk/for-next
[2]Barry Song
ARM: 7009/1: CACHE-L2X0: filter start address can be 0 and is often 0
http://www.spinics.net/lists/arm-kernel/msg140126.html
it has been in rmk/for-next
arch/arm/boot/dts/prima2-cb.dts | 5 +++-
arch/arm/mach-prima2/l2x0.c | 46 +++++++-------------------------------
2 files changed, 13 insertions(+), 38 deletions(-)
diff --git a/arch/arm/boot/dts/prima2-cb.dts b/arch/arm/boot/dts/prima2-cb.dts
index 6fecc88..9d6167c 100644
--- a/arch/arm/boot/dts/prima2-cb.dts
+++ b/arch/arm/boot/dts/prima2-cb.dts
@@ -39,9 +39,12 @@
ranges = <0x40000000 0x40000000 0x80000000>;
l2-cache-controller at 80040000 {
- compatible = "arm,pl310-cache";
+ compatible = "arm,pl310-cache", "sirf,prima2-pl310-cache";
reg = <0x80040000 0x1000>;
interrupts = <59>;
+ arm,tag-latency = <1 1 1>;
+ arm,data-latency = <1 1 1>;
+ arm,filter-ranges = <0 0x40000000>;
};
intc: interrupt-controller at 80020000 {
diff --git a/arch/arm/mach-prima2/l2x0.c b/arch/arm/mach-prima2/l2x0.c
index 9cda205..c998377 100644
--- a/arch/arm/mach-prima2/l2x0.c
+++ b/arch/arm/mach-prima2/l2x0.c
@@ -8,52 +8,24 @@
#include <linux/init.h>
#include <linux/kernel.h>
-#include <linux/io.h>
-#include <linux/errno.h>
#include <linux/of.h>
-#include <linux/of_address.h>
#include <asm/hardware/cache-l2x0.h>
-#include <mach/memory.h>
-#define L2X0_ADDR_FILTERING_START 0xC00
-#define L2X0_ADDR_FILTERING_END 0xC04
-
-static struct of_device_id l2x_ids[] = {
- { .compatible = "arm,pl310-cache" },
+static struct of_device_id prima2_l2x0_ids[] = {
+ { .compatible = "sirf,prima2-pl310-cache" },
+ {},
};
-static int __init sirfsoc_of_l2x_init(void)
+static int __init sirfsoc_l2x0_init(void)
{
struct device_node *np;
- void __iomem *sirfsoc_l2x_base;
-
- np = of_find_matching_node(NULL, l2x_ids);
- if (!np)
- panic("unable to find compatible l2x node in dtb\n");
-
- sirfsoc_l2x_base = of_iomap(np, 0);
- if (!sirfsoc_l2x_base)
- panic("unable to map l2x cpu registers\n");
-
- of_node_put(np);
-
- if (!(readl_relaxed(sirfsoc_l2x_base + L2X0_CTRL) & 1)) {
- /*
- * set the physical memory windows L2 cache will cover
- */
- writel_relaxed(PLAT_PHYS_OFFSET + 1024 * 1024 * 1024,
- sirfsoc_l2x_base + L2X0_ADDR_FILTERING_END);
- writel_relaxed(PLAT_PHYS_OFFSET | 0x1,
- sirfsoc_l2x_base + L2X0_ADDR_FILTERING_START);
- writel_relaxed(0,
- sirfsoc_l2x_base + L2X0_TAG_LATENCY_CTRL);
- writel_relaxed(0,
- sirfsoc_l2x_base + L2X0_DATA_LATENCY_CTRL);
+ np = of_find_matching_node(NULL, prima2_l2x0_ids);
+ if (np) {
+ pr_info("Initializing prima2 L2 cache\n");
+ return l2x0_of_init(0x40000, 0);
}
- l2x0_init((void __iomem *)sirfsoc_l2x_base, 0x00040000,
- 0x00000000);
return 0;
}
-early_initcall(sirfsoc_of_l2x_init);
+early_initcall(sirfsoc_l2x0_init);
--
1.7.1
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply related
* [PATCH 2/2] ARM: mmp: add audio sram allocator
From: Leo Yan @ 2011-09-16 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915143857.GL28104@game.jcrosoft.org>
On 09/15/2011 10:38 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:59 Mon 01 Aug , Leo Yan wrote:
>> Implement the audio sram allocator with genalloc,
>> so that can dynamically allocate the buffer
>> to pcm devices as need.
>>
>> Signed-off-by: Leo Yan<leoy@marvell.com>
> this can be more generic nad move to lib/genalloc.c
This is an older version, i have updated the patch same as you said.
pls see below link for the latest patch:
http://lists.arm.linux.org.uk/lurker/message/20110815.030920.2ad4227b.en.html
Thx,
Leo Yan
^ permalink raw reply
* [RFC PATCH] ARM: mxc: Select ARCH_HAS_HOLES_MEMORYMODEL
From: Fabio Estevam @ 2011-09-16 0:29 UTC (permalink / raw)
To: linux-arm-kernel
Select ARCH_HAS_HOLES_MEMORYMODELfor ARCH_MXC so that the non-contiguous memory block
can be handled correctly.
An example of such system is MX35PDK that has a total of 256MB dividedin
two RAM banks:128MB at CS0 and another 128MB at CS1. On MX35 each chip select
can address up to 256MB, so this configuration leaves a 128MB 'hole' in the
memory map that needs to be handled properly.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d9..29bbd1d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -397,6 +397,7 @@ config ARCH_MXC
select CLKSRC_MMIO
select GENERIC_IRQ_CHIP
select HAVE_SCHED_CLOCK
+ select ARCH_HAS_HOLES_MEMORYMODEL
help
Support for Freescale MXC/iMX-based family of processors
--
1.6.0.4
^ permalink raw reply related
* [GIT PULL] OMAP: omap_device cleanup for v3.2
From: Kevin Hilman @ 2011-09-15 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mxe5tlzv.fsf@ti.com>
Kevin Hilman <khilman@ti.com> writes:
> Please pull this omap_device cleanup series for v3.2. This sets the
> groundwork for Benoit's DT infrastructure work.
Turns out this series has a dependency on a patch[1] in Russell's
for-next branch.
Russell, any chance of picking this patch into your devel-stable so we
have a fixed point to merge with?
Thanks,
Kevin
[1]
commit 456f69c544d4298e921dc0c606492cdbaa60b34b
Author: Kevin Hilman <khilman@deeprootsystems.com>
Date: Tue Sep 6 21:04:10 2011 +0100
ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointer
Add omap_device pointer to the ARM-specific arch data in the
platform_device. This will be used to attach OMAP-specific
device-data to the platform device with device lifetime.
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
^ permalink raw reply
* [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
From: Thomas Gleixner @ 2011-09-15 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915232903.GA22533@n2100.arm.linux.org.uk>
On Fri, 16 Sep 2011, Russell King - ARM Linux wrote:
> On Fri, Sep 16, 2011 at 12:49:10AM +0200, Thomas Gleixner wrote:
> > Marc,
> >
> > On Thu, 15 Sep 2011, Marc Zyngier wrote:
> > > +
> > > + raw_spin_unlock_irqrestore(&desc->lock, flags);
> > > +
> > > + unregister_handler_proc(irq, action);
> > > +
> > > + /* Make sure it's not being used on another CPU: */
> > > + synchronize_irq(irq);
> >
> > That's not helping w/o making synchronize_irq() aware of the percpu
> > stuff. Also there is the question whether we need the ability to
> > remove such interrupts in the first place. The target users are low
> > level arch interrupts not some random device drivers.
>
> You do - think local timers which go away on hotunplug and come back
> on hotplug. The alternative is requiring every local timer code to
> remember whether it registered its per-cpu handler on each CPU or not,
> and that just gets more messy than having them unregister on hotunplug.
> Not only would that be more prone to bugs but it will also mean extra
> complexity in arch code.
Yikes! That code is removing the GLOBAL action, so all users are going
to hell.
The point of the percpu_irq stuff is to have a single action with a
percpu dev_id and a per cpu enable/disable. So when you unplug your
cpu that very cpu calls the disable function and therefor removes
itself w/o causing the other cpus to die on action = NULL
Thanks,
tglx
^ permalink raw reply
* [GIT PULL] OMAP: omap_device cleanup for v3.2
From: Kevin Hilman @ 2011-09-15 23:38 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Please pull this omap_device cleanup series for v3.2. This sets the
groundwork for Benoit's DT infrastructure work.
Kevin
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://gitorious.org/khilman/linux-omap-pm.git for_3.2/omap_device
Grazvydas Ignotas (1):
OMAP: omap_device: make latency autoadjust messages debug
Jarkko Nikula (1):
omap: mcbsp: Remove omap device API
Kevin Hilman (6):
OMAP: omap_device: replace debug/warning/error prints with dev_* macros
OMAP: omap_device: remove internal functions from omap_device.h
OMAP: omap_device: when building return platform_device instead of omap_device
OMAP: omap_device: device register functions now take platform_device pointer
OMAP: omap_device: _disable_idle_on_suspend() takes platform_device pointer
OMAP: omap_device: decouple platform_device from omap_device
arch/arm/mach-omap2/devices.c | 44 +++---
arch/arm/mach-omap2/display.c | 6 +-
arch/arm/mach-omap2/dma.c | 16 +-
arch/arm/mach-omap2/gpio.c | 10 +-
arch/arm/mach-omap2/hsmmc.c | 8 +-
arch/arm/mach-omap2/hwspinlock.c | 8 +-
arch/arm/mach-omap2/mcbsp.c | 8 +-
arch/arm/mach-omap2/opp.c | 2 +-
arch/arm/mach-omap2/pm.c | 8 +-
arch/arm/mach-omap2/serial.c | 14 +-
arch/arm/mach-omap2/sr_device.c | 6 +-
arch/arm/plat-omap/i2c.c | 8 +-
arch/arm/plat-omap/include/plat/omap_device.h | 30 ++--
arch/arm/plat-omap/mcbsp.c | 27 ----
arch/arm/plat-omap/omap_device.c | 185 +++++++++++++------------
15 files changed, 180 insertions(+), 200 deletions(-)
^ permalink raw reply
* [GIT PULL] OMAP voltage layer cleanup for v3.2
From: Tony Lindgren @ 2011-09-15 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d3f14n4k.fsf@ti.com>
* Kevin Hilman <khilman@ti.com> [110915 11:59]:
> Tony,
>
> Please pull the OMAP voltage layer cleanup for v3.2.
>
> This is a combination of the series A..E that have been posted, with
> a handful of updates throughout the comments and kerneldoc.
>
> It is based on the powerdomain/clockdomain OMAP_CHIP cleanup from Paul
> (his pwrdm_clkdm_remove_omap_chip_cleanup_3.2 branch.)
Thanks, I've pulled Paul's omap_chip_remove_cleanup_3.2 into cleanup
branch and your voltage changes into voltage branch and rebuilt linux-omap
master branch. Then assuming no issues, I'll ask Arnd to pull these
on Friday.
Regards,
Tony
^ permalink raw reply
* [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
From: Russell King - ARM Linux @ 2011-09-15 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1109152207010.2723@ionos>
On Fri, Sep 16, 2011 at 12:49:10AM +0200, Thomas Gleixner wrote:
> Marc,
>
> On Thu, 15 Sep 2011, Marc Zyngier wrote:
> > +
> > + raw_spin_unlock_irqrestore(&desc->lock, flags);
> > +
> > + unregister_handler_proc(irq, action);
> > +
> > + /* Make sure it's not being used on another CPU: */
> > + synchronize_irq(irq);
>
> That's not helping w/o making synchronize_irq() aware of the percpu
> stuff. Also there is the question whether we need the ability to
> remove such interrupts in the first place. The target users are low
> level arch interrupts not some random device drivers.
You do - think local timers which go away on hotunplug and come back
on hotplug. The alternative is requiring every local timer code to
remember whether it registered its per-cpu handler on each CPU or not,
and that just gets more messy than having them unregister on hotunplug.
Not only would that be more prone to bugs but it will also mean extra
complexity in arch code.
^ permalink raw reply
* [RFC PATCH 09/11] DT: regulator: Helper to extract regulator node based on supply name
From: Mark Brown @ 2011-09-15 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915225035.GP3523@ponder.secretlab.ca>
On Thu, Sep 15, 2011 at 04:50:35PM -0600, Grant Likely wrote:
> We've got two competing approaches here. For reg and interrupts, the
> proposal on the table that we talked about at LPC is to do reg-names
> and interrupts-names so as to preserve the existing semantics of the
> reg and interrupts properties. For gpios we're using the binding
> "<name>-gpios" for named gpio references. There isn't the same
> pressure to preserve existing bindings in that case. I'm okay with
> either approach, providing that "-regulator" is encoded into the name.
I think I prefer the latter but I'm probably not too fussed.
I'd rather use something like -supply for these just on the basis that
you don't always connect things to regulators (for example, speaker
supplies are generally attached direct to the battery).
^ permalink raw reply
* [RFC PATCH 09/11] DT: regulator: Helper to extract regulator node based on supply name
From: Grant Likely @ 2011-09-15 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915135416.GN7988@opensource.wolfsonmicro.com>
On Thu, Sep 15, 2011 at 02:54:16PM +0100, Mark Brown wrote:
> On Thu, Sep 15, 2011 at 04:52:05PM +0530, Rajendra Nayak wrote:
>
> > regulator = <®ulator1>,<®ulator2>;
> > regulator-names = "supply1","supply2";
> > };
>
> This syntax is really painful - we're relying on keeping two arrays in
> sync which isn't good for legibility or robustness. I'd expect
> something like having a property with the supply name referencing the
> regulator node concerned like:
>
> dbvdd = <®ulator1>;
> dcvdd = <®ulator2>;
>
> or something. Keeping the two arrays separate doesn't seem great.
We've got two competing approaches here. For reg and interrupts, the
proposal on the table that we talked about at LPC is to do reg-names
and interrupts-names so as to preserve the existing semantics of the
reg and interrupts properties. For gpios we're using the binding
"<name>-gpios" for named gpio references. There isn't the same
pressure to preserve existing bindings in that case. I'm okay with
either approach, providing that "-regulator" is encoded into the name.
g.
^ permalink raw reply
* [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
From: Thomas Gleixner @ 2011-09-15 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316105551-17505-2-git-send-email-marc.zyngier@arm.com>
Marc,
On Thu, 15 Sep 2011, Marc Zyngier wrote:
>
> Based on an initial patch by Thomas Gleixner.
Was more an idea than a patch :)
> + void *dev_id;
> +#ifdef CONFIG_IRQ_PERCPU_DEVID
> + void __percpu *percpu_dev_id;
> +#endif
Can we please avoid that ifdef and use an anon union ?
> +#ifdef CONFIG_IRQ_PERCPU_DEVID
> +static inline int irq_set_percpu_devid(unsigned int irq)
Real function in kernel/irq/ please
> +{
> + struct irq_desc *desc = irq_to_desc(irq);
> +
> + if (!desc)
> + return -EINVAL;
> +
> + if (!zalloc_cpumask_var(&desc->percpu_enabled, GFP_KERNEL))
> + return -ENOMEM;
What prevents that allocation happening more than once ?
> + irq_set_status_flags(irq,
> + IRQ_NOAUTOEN | IRQ_PER_CPU | IRQ_NOTHREAD |
> + IRQ_NOPROBE | IRQ_PER_CPU_DEVID);
> + return 0;
> +}
> +#endif
> +
> /* Handle dynamic irq creation and destruction */
> extern unsigned int create_irq_nr(unsigned int irq_want, int node);
> extern int create_irq(void);
> diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
> index 150134a..0b4419a 100644
> --- a/include/linux/irqdesc.h
> +++ b/include/linux/irqdesc.h
> @@ -53,6 +53,9 @@ struct irq_desc {
> unsigned long last_unhandled; /* Aging timer for unhandled count */
> unsigned int irqs_unhandled;
> raw_spinlock_t lock;
> +#ifdef CONFIG_IRQ_PERCPU_DEVID
Can we just make that a pointer and get rid of the config option ?
> +#ifdef CONFIG_IRQ_PERCPU_DEVID
> +void irq_percpu_enable(struct irq_desc *desc)
> +{
> + unsigned int cpu = get_cpu();
get_cpu() is overkill here. That's called with desc->lock held and
interrupts disabled. No way that the cpu can go away :)
I'd rather have a check in the calling function, which makes sure that
enable_percpu_irq() is called from proper per cpu context. See comment
below.
> void remove_irq(unsigned int irq, struct irqaction *act)
> {
> - __free_irq(irq, act->dev_id);
> + struct irq_desc *desc = irq_to_desc(irq);
> +
> + if (desc && !irq_settings_is_per_cpu_devid(desc))
That probably should be
if (!WARN_ON(....))
> + __free_irq(irq, act->dev_id);
> }
> EXPORT_SYMBOL_GPL(remove_irq);
>
> @@ -1246,7 +1251,7 @@ void free_irq(unsigned int irq, void *dev_id)
> {
> struct irq_desc *desc = irq_to_desc(irq);
>
> - if (!desc)
> + if (!desc || irq_settings_is_per_cpu_devid(desc))
> return;
Please make these percpu_devid checks WARN_ON so we can avoid stupid
questions on the mailing lists.
> #ifdef CONFIG_SMP
> @@ -1324,7 +1329,8 @@ int request_threaded_irq(unsigned int irq, irq_handler_t handler,
> if (!desc)
> return -EINVAL;
>
> - if (!irq_settings_can_request(desc))
> + if (!irq_settings_can_request(desc) ||
> + irq_settings_is_per_cpu_devid(desc))
> return -EINVAL;
That's fine.
> if (!handler) {
> @@ -1409,3 +1415,198 @@ int request_any_context_irq(unsigned int irq, irq_handler_t handler,
> return !ret ? IRQC_IS_HARDIRQ : ret;
> }
> EXPORT_SYMBOL_GPL(request_any_context_irq);
> +
> +#ifdef CONFIG_IRQ_PERCPU_DEVID
> +void enable_percpu_irq(unsigned int irq)
> +{
> + unsigned long flags;
> + struct irq_desc *desc = irq_get_desc_buslock(irq, &flags);
> +
> + if (!desc)
> + return;
> +
> + irq_percpu_enable(desc);
> + irq_put_desc_busunlock(desc, flags);
To make this luser proof and better debuggable I'd like to have that as:
int cpu = smp_processsor_id();
unsigned long flags;
....
irq_percpu_enable(desc, cpu);
That way we catch at least lusers who call that from random thread
context - assuming that they enabled some debug options .....
> +}
> +EXPORT_SYMBOL(enable_percpu_irq);
_GPL please if at all. Not sure whether this needs to be available for
modules.
> +/*
> + * Internal function to unregister a percpu irqaction.
> + */
> +static struct irqaction *__free_percpu_irq(unsigned int irq, void __percpu *dev_id)
> +{
> + struct irq_desc *desc = irq_to_desc(irq);
> + struct irqaction *action;
> + unsigned long flags;
> +
> + WARN(in_interrupt(), "Trying to free IRQ %d from IRQ context!\n", irq);
> +
> + if (!desc)
> + return NULL;
> +
> + raw_spin_lock_irqsave(&desc->lock, flags);
> +
> + action = desc->action;
> + if (!action || action->percpu_dev_id != dev_id) {
> + WARN(1, "Trying to free already-free IRQ %d\n", irq);
> + raw_spin_unlock_irqrestore(&desc->lock, flags);
> + return NULL;
> + }
> +
> + /* Found it - now remove it from the list of entries: */
> + WARN(!cpumask_empty(desc->percpu_enabled),
> + "percpu IRQ %d still enabled on CPU%d!\n",
> + irq, cpumask_first(desc->percpu_enabled));
> + desc->action = NULL;
> +
> +#ifdef CONFIG_SMP
> + /* make sure affinity_hint is cleaned up */
> + if (WARN_ON_ONCE(desc->affinity_hint))
> + desc->affinity_hint = NULL;
> +#endif
We don't want to have an affinity hint for percpu interrupts. That's
pretty useless AFACIT :)
> +
> + raw_spin_unlock_irqrestore(&desc->lock, flags);
> +
> + unregister_handler_proc(irq, action);
> +
> + /* Make sure it's not being used on another CPU: */
> + synchronize_irq(irq);
That's not helping w/o making synchronize_irq() aware of the percpu
stuff. Also there is the question whether we need the ability to
remove such interrupts in the first place. The target users are low
level arch interrupts not some random device drivers.
Otherwise this is a pretty cool patch!
Thanks,
tglx
^ permalink raw reply
* [RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
From: Grant Likely @ 2011-09-15 22:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-7-git-send-email-rnayak@ti.com>
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote:
> The helper routine defined here (of_get_fixed_voltage_config) can
> be used to extract information about fixed regulators (which are not
> software controlable) from device tree.
>
> Add documenation about additional bindings for fixed
> regulators that can be passed through DT.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> .../devicetree/bindings/regulator/regulator.txt | 19 ++++++++++++
> drivers/of/of_regulator.c | 31 ++++++++++++++++++++
> include/linux/of_regulator.h | 7 ++++
> 3 files changed, 57 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
> index 001e5ce..f8c51d8 100644
> --- a/Documentation/devicetree/bindings/regulator/regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -2,6 +2,8 @@ Voltage/Current Regulators
>
> Required properties:
> - compatible: Must be "regulator";
> +or
> +- compatible: Must be "regulator-fixed"; /* For Fixed volatge regulator */
regulator-fixed should actually just be another driver binding that
uses the regulator binding.
>
> Optional properties:
> - supply-regulator: Name of the parent regulator
> @@ -24,6 +26,13 @@ Optional properties:
> - always-on: boolean, regulator should never be disabled
> - boot-on: bootloader/firmware enabled regulator
> - apply-uV: apply uV constraint if min == max
> +# For fixed voltage regulators
> +- supply-name: Name of the regulator supply
> +- microvolts: Output voltage of regulator
> +- gpio: gpio to use for enable control
> +- startup-delay: startup time in microseconds
> +- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
> +- enabled-at-boot: 1 = yes, 0 = no
>
> Example:
>
> @@ -35,3 +44,13 @@ Example:
> change-voltage;
> always-on;
> };
> +
> + abc-fixedregulator {
> + compatible = "regulator-fixed";
> + supply-name = "fixed-supply";
> + microvolts = <1800000>;
> + gpio = <43>;
> + startup-delay = <70000>;
> + enable-high;
> + enabled-at-boot;
> + };
> diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
> index f01d275..4d7a49d 100644
> --- a/drivers/of/of_regulator.c
> +++ b/drivers/of/of_regulator.c
> @@ -13,6 +13,7 @@
> #include <linux/slab.h>
> #include <linux/of.h>
> #include <linux/regulator/machine.h>
> +#include <linux/regulator/fixed.h>
>
> static void of_get_regulation_constraints(struct device_node *np,
> struct regulator_init_data **init_data)
> @@ -83,3 +84,33 @@ struct regulator_init_data *of_get_regulator_init_data(struct device_node *np)
> return init_data;
> }
> EXPORT_SYMBOL(of_get_regulator_init_data);
> +
> +/**
> + * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
> + * @np: Pointer to fixed-regulator device tree node
> + *
> + * Populates fixed_voltage_config structure by extracting data from device
> + * tree node, returns a pointer to the populated structure of NULL if memory
> + * alloc fails.
> + */
> +struct fixed_voltage_config *of_get_fixed_voltage_config(struct device_node *np)
> +{
> + struct fixed_voltage_config *config;
> +
> + config = kzalloc(sizeof(struct fixed_voltage_config), GFP_KERNEL);
> + if (!config)
> + return NULL;
> +
> + config->supply_name = (char *)of_get_property(np, "supply-name", NULL);
> + of_property_read_u32(np, "microvolts", &config->microvolts);
> + of_property_read_u32(np, "gpio", &config->gpio);
> + of_property_read_u32(np, "startup-delay", &config->startup_delay);
> + if (of_find_property(np, "enable-high", NULL))
> + config->enable_high = true;
> + if (of_find_property(np, "enabled-at-boot", NULL))
> + config->enabled_at_boot = true;
> + config->init_data = of_get_regulator_init_data(np);
> +
> + return config;
> +}
> +EXPORT_SYMBOL(of_get_fixed_voltage_config);
> diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
> index 5eb048c..39860c5 100644
> --- a/include/linux/of_regulator.h
> +++ b/include/linux/of_regulator.h
> @@ -11,12 +11,19 @@
> #if defined(CONFIG_OF_REGULATOR)
> extern struct regulator_init_data
> *of_get_regulator_init_data(struct device_node *np);
> +extern struct fixed_voltage_config
> + *of_get_fixed_voltage_config(struct device_node *np);
> #else
> static inline struct regulator_init_data
> *of_get_regulator_init_data(struct device_node *np)
> {
> return NULL;
> }
> +static inline struct fixed_voltage_config
> + *of_get_fixed_voltage_config(struct device_node *np)
> +{
> + return NULL;
> +}
> #endif /* CONFIG_OF_REGULATOR */
>
> #endif /* __LINUX_OF_REG_H */
> --
> 1.7.1
>
^ permalink raw reply
* [RFC PATCH 05/11] TWL: regulator: Make twl-regulator driver extract data from DT
From: Grant Likely @ 2011-09-15 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-6-git-send-email-rnayak@ti.com>
On Thu, Sep 15, 2011 at 04:52:01PM +0530, Rajendra Nayak wrote:
> Modify the twl regulator driver to extract the regulator_init_data from
> device tree when passed, instead of getting it through platform_data
> structures (on non-DT builds)
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> drivers/regulator/twl-regulator.c | 28 +++++++++++++++++++++++++---
> 1 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
> index ee8747f..df1b95a 100644
> --- a/drivers/regulator/twl-regulator.c
> +++ b/drivers/regulator/twl-regulator.c
> @@ -17,6 +17,8 @@
> #include <linux/regulator/driver.h>
> #include <linux/regulator/machine.h>
> #include <linux/i2c/twl.h>
> +#include <linux/of.h>
> +#include <linux/of_regulator.h>
>
>
> /*
> @@ -1011,6 +1013,9 @@ static int __devinit twlreg_probe(struct platform_device *pdev)
> struct regulation_constraints *c;
> struct regulator_dev *rdev;
>
> + if (pdev->dev.of_node)
> + of_property_read_u32(pdev->dev.of_node, "ti,reg-id", &pdev->id);
> +
Don't do this. As much as possible, don't reply on plaform_device->id
when using DT. Plus it is illegal to modify pdev->id after the device
is registered.
> for (i = 0, info = NULL; i < ARRAY_SIZE(twl_regs); i++) {
> if (twl_regs[i].desc.id != pdev->id)
> continue;
> @@ -1020,7 +1025,11 @@ static int __devinit twlreg_probe(struct platform_device *pdev)
> if (!info)
> return -ENODEV;
>
> - initdata = pdev->dev.platform_data;
> + if (pdev->dev.of_node)
> + initdata = of_get_regulator_init_data(pdev->dev.of_node);
> + else
> + initdata = pdev->dev.platform_data;
> +
> if (!initdata)
> return -EINVAL;
>
> @@ -1101,14 +1110,27 @@ static int __devexit twlreg_remove(struct platform_device *pdev)
>
> MODULE_ALIAS("platform:twl_reg");
>
> +#if defined(CONFIG_OF)
> +static const struct of_device_id twl_of_match[] __devinitconst = {
> + { .compatible = "ti,twl-reg", },
This looks rather generic. Is this a specific chip? It should be.
g.
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, twl_of_match);
> +#else
> +#define twl_of_match NULL
> +#endif
> +
> static struct platform_driver twlreg_driver = {
> .probe = twlreg_probe,
> .remove = __devexit_p(twlreg_remove),
> /* NOTE: short name, to work around driver model truncation of
> * "twl_regulator.12" (and friends) to "twl_regulator.1".
> */
> - .driver.name = "twl_reg",
> - .driver.owner = THIS_MODULE,
> + .driver = {
> + .name = "twl_reg",
> + .owner = THIS_MODULE,
> + .of_match_table = twl_of_match,
> + },
> };
>
> static int __init twlreg_init(void)
> --
> 1.7.1
>
^ permalink raw reply
* [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
From: Grant Likely @ 2011-09-15 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915134618.GK7988@opensource.wolfsonmicro.com>
On Thu, Sep 15, 2011 at 02:46:18PM +0100, Mark Brown wrote:
> On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
>
> > +Required properties:
> > +- compatible: Must be "regulator","ti,twl-reg";
>
> I'd expect listings for the specific chips too.
>
> > + xyz-regulator: regulator at 0 {
> > + compatible = "regulator","ti,twl-reg";
> > + ti,reg-id = <37>; /* TWL6030_REG_VAUX1_6030 */
>
> These magic numbers are *very* Linux specific, we should have a better
> way of specifying regulators - I'd off the top of my head expect that
> the compatible property would identify the regulator.
Yes, that is exactly what it should do.
g.
^ 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