* [GIT PULL] Ux500 pin changes
From: Arnd Bergmann @ 2012-11-15 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115112032.GB21682@gmail.com>
On Thursday 15 November 2012, Lee Jones wrote:
> On Thu, 15 Nov 2012, Linus Walleij wrote:
>
> > On Mon, Nov 12, 2012 at 11:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > > u8500_defconfig now gives me two new errors in arm-soc/for-next when building with
> > > -Werror:
> > >
> > > arch/arm/mach-ux500/board-mop500-pins.c:73:22: error: 'out_hi_wkup_pdis' defined but not used [-Werror=unused-variable]
> >
> > I've sent a fix for this, could you apply that patch directly to the
> > drivers branch?
> >
> > > and the existing:
> > >
> > > ERROR (phandle_references): Reference to non-existent node or label "tc3589x_gpio"
> > >
> > > Can you provide patches to fix these up?
> >
> > What on earth is that? Lee, do you know how to fix this one up, I shamelessly
> > assume it to be related to commit:
> > commit 3113e679021a3a6bace1c62a8432cc0ec27c09ab
> > "gpio: Enable the tc3298x GPIO expander driver for Device Tree"
>
> I haven't seen this error.
>
> Which kernel is this? How do I reproduce?
>
It's currently in arm-soc/for-next. Reproduce with "make u8500_defconfig && make".
I haven't bisected the problem, but it's obvious that some dts files reference
the "tc3589x_gpio" file that is not defined anywhere.
Arnd
^ permalink raw reply
* [PATCH] mmc: Standardise capability type
From: Arnd Bergmann @ 2012-11-15 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ+V1aiQ-c62v9jdv93wMGu9hrSnXj_a9jx3uOTbot44A@mail.gmail.com>
On Thursday 15 November 2012, Linus Walleij wrote:
>
> On Wed, Nov 14, 2012 at 1:35 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > There are discrepancies with regards to how MMC capabilities
> > are carried throughout the subsystem. Let's standardise them
> > to elevate any confusion.
> >
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: linux-mmc at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Looks good to me, and these are obviously
> u32 bitfields by design, so:
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge
From: Rajanikanth HV @ 2012-11-15 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509E8694.7080609@gmail.com>
On Saturday 10 November 2012 10:23 PM, Francesco Lavra wrote:
>>> I don't get the point of declaring the char array and copying the string
>>> in it, when you could simply use just the pointer returned by
>>> of_get_property().
>>
>> I am considering a corner case where in 'battery-type' property is not
>> present and battery is connected.In this case i promote battery to
>> UNKNOWN from null.
>
> You could achieve the same result without using the char array, with
> this assignment:
>
> btech = "UNKNOWN";
>
>> FYI: Further, btemp driver will identify the connected battery based on
>> resistance value and decide to use.
>> Ref: ab8500_btemp_id(...) ab8500_btemp.c
>>
>>> Anyway, if the string property is longer than 8 characters, you are
>>> writing past the size of the destination array.
>>
>> i believe it is safe as power_supply.h comprises defines having battery
>> technology type in 4 characters length which is normally the case and
>> 7 chars length being "UNKNOWN" seldom referred
>
> You should be able to handle whatever the device tree contains, and if
> it contains unexpected data this is not a good excuse for locking up the
> system.
agreed, if we were to go by what device tree contains then explicit
assignment for battery type as "UNKNOWN" is not required, hence only 2
use case persist as :
a) property name with one of the said value be present
(as per documentation)
b) property name not present
^ permalink raw reply
* Kernel uncompression error
From: Vasily Khoruzhick @ 2012-11-15 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mwyjw1og.fsf@lebrac.rtp-net.org>
On Thu, Nov 15, 2012 at 2:22 PM, Arnaud Patard
<arnaud.patard@rtp-net.org> wrote:
>
> I guess that a lot of people don't care anymore about 2410 or can't
> help. For instance, the only serial port available on my h1940 is the IR
> one and I don't have a device to receive the ir data anymore so this
> won't help. I won't even talk about gta01, which has no support in
> mainline. It may also be the usual -ENOTIME error.
Well, I've s3c2440 and s3c2442 (they're close enough to s3c2410)
machines with serial port, I can take a look.
Regards
Vasily
^ permalink raw reply
* Kernel uncompression error
From: Russell King - ARM Linux @ 2012-11-15 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVdDGszU1jMDXjFepvnSmiRTWJ=A_23BL2LEty+170FNsA@mail.gmail.com>
On Thu, Nov 15, 2012 at 02:29:40PM +0300, Vasily Khoruzhick wrote:
> On Wed, Nov 14, 2012 at 8:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, Nov 14, 2012 at 10:23:55PM +0800, woody wrote:
> >> I just built a 3.2.x ARM kernel and tried to have it boot by a boot
> >> loader (vivi) on my s3c2410a ARM board. The kernel was built with
> >> default configuration s3c2410.
> >
> > I reported that S3C2410 is totally dead with 3.x kernels about a month
> > ago and got no response what so ever from anyone. I guess S3C2410 is
> > just not cared for anymore.
>
> It was working at least for 3.1 (tested on h1940 machine),
> can you give a link to your post? I still care about s3c2410 and s3c244x :)
Subject: s3c2410 bast (== lists.arm.linux.org.uk) - appears to be broken
with 3.1.8...
^ permalink raw reply
* [PATCH] mmc: Standardise capability type
From: Linus Walleij @ 2012-11-15 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352896551-17948-1-git-send-email-lee.jones@linaro.org>
On Wed, Nov 14, 2012 at 1:35 PM, Lee Jones <lee.jones@linaro.org> wrote:
> There are discrepancies with regards to how MMC capabilities
> are carried throughout the subsystem. Let's standardise them
> to elevate any confusion.
>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Looks good to me, and these are obviously
u32 bitfields by design, so:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Kernel uncompression error
From: Vasily Khoruzhick @ 2012-11-15 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121114173453.GJ3290@n2100.arm.linux.org.uk>
On Wed, Nov 14, 2012 at 8:34 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Nov 14, 2012 at 10:23:55PM +0800, woody wrote:
>> I just built a 3.2.x ARM kernel and tried to have it boot by a boot
>> loader (vivi) on my s3c2410a ARM board. The kernel was built with
>> default configuration s3c2410.
>
> I reported that S3C2410 is totally dead with 3.x kernels about a month
> ago and got no response what so ever from anyone. I guess S3C2410 is
> just not cared for anymore.
It was working at least for 3.1 (tested on h1940 machine),
can you give a link to your post? I still care about s3c2410 and s3c244x :)
> When I get sufficient motivation, I'll try and track down what's going
> wrong, but it means taking the old mailing list server (and now list
> archive) offline for a while.
>
> I don't think it's cache related; different image sizes seem to behave
> differently - and when they _do_ successfully decompress, they don't
> boot at all.
Regards
Vasily
^ permalink raw reply
* [PATCH 1/2] Boottime: A tool for automatic measurement of kernel/bootloader boot time
From: Lee Jones @ 2012-11-15 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2UX0Wyr-QKw3=tbUXeuEhHe04_cFkkAp6bB2Rr-x7ViHQ@mail.gmail.com>
> > +/* for automatic boot timing testcases */
> > +#define ATAG_BOOTTIME 0x41000403
> Where can I refer this ATAG usage? can you point out the reference URL
> or patches?
I assumed this would be in Mainline u-boot, but apparently not.
On closer inspection of the internal ST-Ericsson u-boot, this
functionality appears to be provided by patches which currently
exist as delta. So in essence, the bootloader you use will have
to be patched in a similar way for you to retrieve information
surrounding bootloader boot times.
And there was me thinking it was magic. ;)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Kernel uncompression error
From: Arnaud Patard (Rtp) @ 2012-11-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115093233.GM3290@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> On Thu, Nov 15, 2012 at 01:56:47PM +0800, woody wrote:
>> On 11/15/2012 1:34 AM, Russell King - ARM Linux wrote:
>>> On Wed, Nov 14, 2012 at 10:23:55PM +0800, woody wrote:
>>>> I just built a 3.2.x ARM kernel and tried to have it boot by a boot
>>>> loader (vivi) on my s3c2410a ARM board. The kernel was built with
>>>> default configuration s3c2410.
>>>
>>> I reported that S3C2410 is totally dead with 3.x kernels about a month
>>> ago and got no response what so ever from anyone. I guess S3C2410 is
>>> just not cared for anymore.
>>>
>>> When I get sufficient motivation, I'll try and track down what's going
>>> wrong, but it means taking the old mailing list server (and now list
>>> archive) offline for a while.
>>>
>>> I don't think it's cache related; different image sizes seem to behave
>>> differently - and when they _do_ successfully decompress, they don't
>>> boot at all.
>>
>> Now I switched from 3.2.x kernel to the latest stable 3.6.6. And, I did
>> a lot of configuration to make the zImage size smaller, now it is 1.5M.
>> After download it to the board, I got another error:
>>
>> "Uncompressing Linux... done, booting the kernel."
>>
>> Then the kernel halted.
>>
>> I noticed, the dots (...) in the kernel log seems very short, is this a
>> clue or just normal?
>
> You've not told me anything I don't already know... As I said, it needs
> investigation as to what's going on. I was rather hoping that the Samsung
> people would look at it, but alas there seems to be zero interest from
> them.
I guess that a lot of people don't care anymore about 2410 or can't
help. For instance, the only serial port available on my h1940 is the IR
one and I don't have a device to receive the ir data anymore so this
won't help. I won't even talk about gta01, which has no support in
mainline. It may also be the usual -ENOTIME error.
Arnaud
^ permalink raw reply
* [GIT PULL] Ux500 pin changes
From: Lee Jones @ 2012-11-15 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ0_3ow9VwGGvFtj_pbYNG+cctB6kUK1FBe4sjU=MTgww@mail.gmail.com>
On Thu, 15 Nov 2012, Linus Walleij wrote:
> On Mon, Nov 12, 2012 at 11:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > u8500_defconfig now gives me two new errors in arm-soc/for-next when building with
> > -Werror:
> >
> > arch/arm/mach-ux500/board-mop500-pins.c:73:22: error: 'out_hi_wkup_pdis' defined but not used [-Werror=unused-variable]
>
> I've sent a fix for this, could you apply that patch directly to the
> drivers branch?
>
> > and the existing:
> >
> > ERROR (phandle_references): Reference to non-existent node or label "tc3589x_gpio"
> >
> > Can you provide patches to fix these up?
>
> What on earth is that? Lee, do you know how to fix this one up, I shamelessly
> assume it to be related to commit:
> commit 3113e679021a3a6bace1c62a8432cc0ec27c09ab
> "gpio: Enable the tc3298x GPIO expander driver for Device Tree"
I haven't seen this error.
Which kernel is this? How do I reproduce?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Fwd: [PATCH 1/7] I2c-nomadik: Fix the usage of wait_for_completion_timeout
From: Srinidhi Kasagar @ 2012-11-15 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115101820.GC418@pengutronix.de>
On Thu, Nov 15, 2012 at 11:18:20 +0100, Wolfram Sang wrote:
> On Thu, Nov 15, 2012 at 03:27:42PM +0530, Srinidhi Kasagar wrote:
> > On Thu, Nov 15, 2012 at 10:29:53 +0100, Wolfram Sang wrote:
> > >
> > > > > - if (timeout < 0) {
> > > > > - dev_err(&dev->adev->dev,
> > > > > - "wait_for_completion_timeout "
> > > > > - "returned %d waiting for event\n", timeout);
> > > > > - status = timeout;
> > > > > - }
> > > > > -
> > > > No, it is wrong. You need to update the status variable in the case of timeout.
> > >
> > > Looking at the patch context, such code comes later.
> > But it causes regressions; without looking at the "later" code, we can't afford merging
> > this code now.
>
> Later as in "a few lines later" not "some time later". Or am I missing
> something else?
I was too fast in reading emails after my short vacation...Sorry.
Acked-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
regards/srinidhi
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Linus Walleij @ 2012-11-15 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115105954.GA17119@lizard>
On Thu, Nov 15, 2012 at 11:59 AM, Anton Vorontsov
<anton.vorontsov@linaro.org> wrote:
> On Thu, Nov 15, 2012 at 11:35:36AM +0100, Linus Walleij wrote:
>> On Mon, Nov 12, 2012 at 7:58 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> > On 11/12/2012 11:43 AM, Anton Vorontsov wrote:
>>
>> >> Should the gpio driver fix its bindings then?.. Polarity is a quite
>> >> generic concept of a GPIO, and flags are there for a reason. I'd rather
>> >> prefer having
>> >
>> > There is no "GPIO driver" to fix; each GPIO driver has its own bindings,
>> > and unfortunately, some of the GPIO binding authors chose not to include
>> > any flags cell in the GPIO specifier (e.g. Samsung ARM SoCs IIRC, but
>> > there are probably more).
>>
>> So can I read this something like we have been too liberal with the
>> GPIO DT bindings and they are now a bit messy and need to be shaped
>> up? I don't know how to achieve that :-(
>
> I guess there's really no reason to panic. :)
>
> 'git grep gpio-cells Documentation/' shows just mrvl-gpio.txt and
> twl6040.txt having the wrong gpio-cells (i.e. 1).
>
> But even these can use one cells for both flags and pin number (unless you
> really have 4294967295 GPIOs per controller).
>
> FWIW, current Samsung SOCs use 3 and even 4 cells for a GPIO specifier,
> which is absolutely fine. Plus, the Samsung bindings do specify the
> inversion flag. So, unless we have a lot of other [undocumented] bindings,
> I don't see a big mess. And everything I currently see is fixable.
I agree it's not that big a mess...
I was more thinking about how to convince the people who can
test this to fix it up.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/3] power: Add simple poweroff-gpio driver
From: Linus Walleij @ 2012-11-15 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352821485-10032-2-git-send-email-andrew@lunn.ch>
On Tue, Nov 13, 2012 at 4:44 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> From: Jamie Lentin <jm@lentin.co.uk>
>
> Given appropriate devicetree bindings, this driver registers a
> pm_power_off function to set a GPIO line high/low to power down
> your board.
>
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
This looks good to me!
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
From: Catalin Marinas @ 2012-11-15 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A43D58.5030404@gmail.com>
On Thu, Nov 15, 2012 at 12:54:48AM +0000, Rob Herring wrote:
> On 11/14/2012 04:21 PM, Tony Lindgren wrote:
> > * Rob Herring <robherring2@gmail.com> [121114 13:59]:
> >> On 11/14/2012 02:32 PM, Tony Lindgren wrote:
> >>>
> >>> Checking for the bit already set should work in this case, I'll post
> >>> a patch for that shortly.
> >>
> >> Can you actually read the state of the diagnostic register in non-secure
> >> mode? If you can on the A9, is the same true on A8 or others?
> >
> > Looks like it can be read on at least TI omap 4430 which is A9.
> > But it reads as zero, so the below patch is what I came up with.
> >
> > No idea if assuming that zero value for the diagnostic register
> > is safe.. What's the default value of the diagnostic register supposed
> > to be?
>
> RTFM. Oh, wait it's a super secret, undocumented register. We shouldn't
> even be talking about it.
>
> It could vary by rev, but I see 0 for the reset value, so this would not
> work if the bootloader did not do any setup of the diagnostic register.
>
> One way to determine secure mode on the A9 would be seeing if you can
> change the auxcr register. Something like this (untested):
>
> mrc p15, 0, r0, c1, c0, 1; Read ACTLR
> eor r1, r0, #0x100 ; Modify alloc in 1 way
> mcr p15, 0, r1, c1, c0, 1
> mrc p15, 0, r2, c1, c0, 1; Read ACTLR
> mcr p15, 0, r0, c1, c0, 1 ; Restore original value
> cmp r1, r2
> bne skip_errata
This would fail on platforms where Linux runs in non-secure mode. What
we do for some errata workarounds is to test whether the bit was already
set and avoid writing the register. But this assumes that, for a given
workaround in the kernel, there is a corresponding workaround in the
code running before the kernel (boot-loader, firmware) which sets that
bit.
Since the kernel will run more often in non-secure mode (on Cortex-A15
you need this for the virtualisation extensions) I strongly suggest that
the workaround (usually undocumented bit setting) is done before the
kernel is started and we simply remove it from Linux (or add a clear
comment that it only works if running in secure mode; if unsure say
'N').
I don't think it's worth the hassle detecting whether the kernel runs in
secure or non-secure mode, just assume the latter and get SoC vendors to
update the boot loaders or firmware (if possible) with any errata
workarounds.
Having a common SMC API for errata workarounds is not feasible since not
all registers are public, most are implementation specific and it could
have secure implications with exposing them.
--
Catalin
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Anton Vorontsov @ 2012-11-15 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb=ra9NwqEneyMoM5YnOFTVQoBxPATjUN6anooXVLiCjw@mail.gmail.com>
On Thu, Nov 15, 2012 at 11:35:36AM +0100, Linus Walleij wrote:
> On Mon, Nov 12, 2012 at 7:58 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 11/12/2012 11:43 AM, Anton Vorontsov wrote:
>
> >> Should the gpio driver fix its bindings then?.. Polarity is a quite
> >> generic concept of a GPIO, and flags are there for a reason. I'd rather
> >> prefer having
> >
> > There is no "GPIO driver" to fix; each GPIO driver has its own bindings,
> > and unfortunately, some of the GPIO binding authors chose not to include
> > any flags cell in the GPIO specifier (e.g. Samsung ARM SoCs IIRC, but
> > there are probably more).
>
> So can I read this something like we have been too liberal with the
> GPIO DT bindings and they are now a bit messy and need to be shaped
> up? I don't know how to achieve that :-(
I guess there's really no reason to panic. :)
'git grep gpio-cells Documentation/' shows just mrvl-gpio.txt and
twl6040.txt having the wrong gpio-cells (i.e. 1).
But even these can use one cells for both flags and pin number (unless you
really have 4294967295 GPIOs per controller).
FWIW, current Samsung SOCs use 3 and even 4 cells for a GPIO specifier,
which is absolutely fine. Plus, the Samsung bindings do specify the
inversion flag. So, unless we have a lot of other [undocumented] bindings,
I don't see a big mess. And everything I currently see is fixable.
Thanks,
Anton.
^ permalink raw reply
* Build failure: OMAP4430 failed due to exynos4 pinctrl
From: Linus Walleij @ 2012-11-15 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01a601cdc15d$5a4c46c0$0ee4d440$%kim@samsung.com>
On Tue, Nov 13, 2012 at 6:11 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>> Date: Wed, 10 Oct 2012 13:31:45 +0000
>> Subject: [PATCH] pinctrl: samsung: don't allow enabling pinctrl-samsung
>> standalone
>>
>> The main samsung pinctrl module references the specific exynos4210
>> pinctrl driver, which selects the main driver in Kconfig.
>>
>> Making the main driver a silent "bool" option avoid this potential
>> build error if CONFIG_PINCTRL_SAMSUNG=y && CONFIG_PINCTRL_EXYNOS4=n:
>>
>> drivers/built-in.o:(.rodata+0x4e4): undefined reference to
>> `exynos4210_pin_ctrl'
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Tomasz Figa <t.figa@samsung.com>
>> Cc: Kyungmin Park <kyungmin.park@samsung.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Kukjin Kim <kgene.kim@samsung.com>
>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>
> Linus, can you pick this up in your pinctrl/fixes ree?
OK done.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/2] Boottime: measure bootloader and kernel bootup time
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-15 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115103528.GA21682@gmail.com>
On 10:35 Thu 15 Nov , Lee Jones wrote:
> On Thu, 15 Nov 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> > On 10:04 Thu 15 Nov , Lee Jones wrote:
> > > This patchset supplies a new tool which measures boottime inclusive
> > > of bootloader involvement. It seems to be accurate and adds no
> > > latency to the booting of the system.
> > >
> > > In the first round of testing we booted the kernel 3 times each with
> > > boottime enabled and disabled. Actually, when it was disabled, the
> > > code was completely removed from the kernel source and the kernel was
> > > rebuilt. The difference between present & enabled and completely
> > > removed was very little indeed. In fact, averaging out the 3 runs of
> > > each, when boottime was enabled the system booted 4ms _faster_, go
> > > figure!
> > >
> > > Enabled Disabled
> > > 1st run 2.983093 2.985168
> > > 2nd run 2.973266 2.971801
> > > 3rd run 2.975402 2.987304
> > > Average 2.977254 2.981424 -0.004171 (-4ms)
> > >
> > >
> > > For the next round of testing, we delayed the bootloader for varying
> > > amounts of time, then started to remove key components from kernel
> > > functionality to see if the boottime system would pick-up on them.
> > >
> > > /* Hang around in the bootloader for a while. */
> > > $ cat /sys/kernel/debug/boottime/summary
> > > kernel: 42864 msecs
> > > total: 42864 msecs
> > > kernel: cpu0 system: 56% idle: 43% iowait: 0% irq: 0%
> > > cpu1 system: 4% idle: 95% iowait: 0% irq: 0%
> > >
> > > /* Hang around in the bootloader for a smaller amount of time. */
> > > kernel: 12351 msecs
> > > total: 12351 msecs
> > > kernel: cpu0 system: 56% idle: 43% iowait: 0% irq: 0%
> > > cpu1 system: 2% idle: 97% iowait: 0% irq: 0%
> > >
> > > /* Instant boot. (1st run) */
> > > kernel: 7833 msecs
> > > total: 7833 msecs
> > > kernel: cpu0 system: 55% idle: 44% iowait: 0% irq: 0%
> > > cpu1 system: 3% idle: 96% iowait: 0% irq: 0%
> > >
> > > /* Instant boot. (2nd run) */
> > > kernel: 7817 msecs
> > > total: 7817 msecs
> > > kernel: cpu0 system: 53% idle: 46% iowait: 0% irq: 0%
> > > cpu1 system: 8% idle: 91% iowait: 0% irq: 0%
> > >
> > > /* Instant boot. (3rd run) */
> > > kernel: 7747 msecs
> > > total: 7747 msecs
> > > kernel: cpu0 system: 56% idle: 42% iowait: 0% irq: 0%
> > > cpu1 system: 2% idle: 97% iowait: 0% irq: 0%
> > 7/8s? on a u9500 wow it's really slow
>
> No, this is a u8500.
>
> > I do 2/3s here
>
> Really? You installed this quick.
>
> Are you sure you did it correctly?
yes we spend less than 2s (~ 1.5s) in the bootloader
I measure it via scope
>
> Don't forget, this times from power-on to userspace.
yes
to the shell prompt
and gexbox 13s IIRC application
Best Regards,
J.
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 1/7] I2c-nomadik: Fix the usage of wait_for_completion_timeout
From: Chuansheng Liu @ 2012-11-15 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115095741.GA6280@bnru10>
timeout is never < 0, so status = timeout is never getting run. This patch delete pointless
code. Could you show the regression? Thanks.
? 2012-11-15?17:57?Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> ???
> On Thu, Nov 15, 2012 at 10:29:53 +0100, Wolfram Sang wrote:
>>
>>>> - if (timeout < 0) {
>>>> - dev_err(&dev->adev->dev,
>>>> - "wait_for_completion_timeout "
>>>> - "returned %d waiting for event\n", timeout);
>>>> - status = timeout;
>>>> - }
>>>> -
>>> No, it is wrong. You need to update the status variable in the case of timeout.
>>
>> Looking at the patch context, such code comes later.
> But it causes regressions; without looking at the "later" code, we can't afford merging
> this code now.
>
> regards/srinidhi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121115/0f1d0c0f/attachment-0001.html>
^ permalink raw reply
* [GIT PULL] Ux500 pin changes
From: Linus Walleij @ 2012-11-15 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211122235.00973.arnd@arndb.de>
On Mon, Nov 12, 2012 at 11:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> u8500_defconfig now gives me two new errors in arm-soc/for-next when building with
> -Werror:
>
> arch/arm/mach-ux500/board-mop500-pins.c:73:22: error: 'out_hi_wkup_pdis' defined but not used [-Werror=unused-variable]
I've sent a fix for this, could you apply that patch directly to the
drivers branch?
> and the existing:
>
> ERROR (phandle_references): Reference to non-existent node or label "tc3589x_gpio"
>
> Can you provide patches to fix these up?
What on earth is that? Lee, do you know how to fix this one up, I shamelessly
assume it to be related to commit:
commit 3113e679021a3a6bace1c62a8432cc0ec27c09ab
"gpio: Enable the tc3298x GPIO expander driver for Device Tree"
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: ux500: fix pin warning
From: Linus Walleij @ 2012-11-15 10:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
Recent pin changes produce this warning:
arch/arm/mach-ux500/board-mop500-pins.c:73:22:
error: 'out_hi_wkup_pdis' defined but not used
[-Werror=unused-variable]
Fix this by deleting the offending definition.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-ux500/board-mop500-pins.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-pins.c b/arch/arm/mach-ux500/board-mop500-pins.c
index 5770ed0..6679d8a 100644
--- a/arch/arm/mach-ux500/board-mop500-pins.c
+++ b/arch/arm/mach-ux500/board-mop500-pins.c
@@ -71,8 +71,6 @@ BIAS(in_wkup_pdis_en, PIN_SLPM_DIR_INPUT|PIN_SLPM_WAKEUP_ENABLE|
PIN_SLPM_PDIS_ENABLED);
BIAS(in_wkup_pdis, PIN_SLPM_DIR_INPUT|PIN_SLPM_WAKEUP_ENABLE|
PIN_SLPM_PDIS_DISABLED);
-BIAS(out_hi_wkup_pdis, PIN_SLPM_OUTPUT_HIGH|PIN_SLPM_WAKEUP_ENABLE|
- PIN_SLPM_PDIS_DISABLED);
BIAS(out_wkup_pdis, PIN_SLPM_DIR_OUTPUT|PIN_SLPM_WAKEUP_ENABLE|
PIN_SLPM_PDIS_DISABLED);
--
1.7.11.3
^ permalink raw reply related
* [PATCH v3 04/11] ARM: Exynos4: Migrate clock support to common clock framework
From: Tomasz Figa @ 2012-11-15 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwQaPXueu6aVoaNQE3BD1gVRRh2pC0LWfjVC71M7QHMYDQ@mail.gmail.com>
On Thursday 15 of November 2012 14:43:21 Thomas Abraham wrote:
> On 15 November 2012 05:01, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> > On Thursday 15 of November 2012 03:37:26 Thomas Abraham wrote:
> >> Remove Samsung specific clock support in Exynos4 and migrate to use
> >> common clock framework.
> >>
> >> Cc: Kukjin Kim <kgene.kim@samsung.com>
> >> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> >> ---
> >>
> >> arch/arm/mach-exynos/Kconfig | 1 +
> >> arch/arm/mach-exynos/Makefile | 3 -
> >> arch/arm/mach-exynos/clock-exynos4.c | 1602
> >>
> >> ---------------------------- arch/arm/mach-exynos/clock-exynos4.h
> >>
> >> | 35 -
> >>
> >> arch/arm/mach-exynos/clock-exynos4210.c | 188 ----
> >> arch/arm/mach-exynos/clock-exynos4212.c | 192 ----
> >> arch/arm/mach-exynos/common.c | 22 +-
> >> arch/arm/mach-exynos/common.h | 3 +
> >> arch/arm/mach-exynos/mach-armlex4210.c | 1 -
> >> arch/arm/mach-exynos/mach-exynos4-dt.c | 1 -
> >> arch/arm/mach-exynos/mach-nuri.c | 1 -
> >> arch/arm/mach-exynos/mach-origen.c | 1 -
> >> arch/arm/mach-exynos/mach-smdk4x12.c | 1 -
> >> arch/arm/mach-exynos/mach-smdkv310.c | 1 -
> >> arch/arm/mach-exynos/mach-universal_c210.c | 1 -
> >> arch/arm/mach-exynos/mct.c | 19 +
> >> arch/arm/plat-samsung/Kconfig | 4 +-
> >> 17 files changed, 27 insertions(+), 2049 deletions(-)
> >> delete mode 100644 arch/arm/mach-exynos/clock-exynos4.c
> >> delete mode 100644 arch/arm/mach-exynos/clock-exynos4.h
> >> delete mode 100644 arch/arm/mach-exynos/clock-exynos4210.c
> >> delete mode 100644 arch/arm/mach-exynos/clock-exynos4212.c
> >
> > [snip]
> >
> >> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
> >> index f7792b8..c2e806c 100644
> >> --- a/arch/arm/mach-exynos/mct.c
> >> +++ b/arch/arm/mach-exynos/mct.c
> >> @@ -31,6 +31,7 @@
> >>
> >> #include <mach/map.h>
> >> #include <mach/irqs.h>
> >> #include <asm/mach/time.h>
> >>
> >> +#include "common.h"
> >>
> >> #define EXYNOS4_MCTREG(x) (x)
> >> #define EXYNOS4_MCT_G_CNT_L EXYNOS4_MCTREG(0x100)
> >>
> >> @@ -517,6 +518,24 @@ static void __init exynos4_timer_init(void)
> >>
> >> struct device_node *np;
> >> u32 nr_irqs, i;
> >>
> >> +#ifdef CONFIG_COMMON_CLK
> >> + /*
> >> + * Clock lookup should be functional now since the MCT
> >> controller
> >> driver + * looks up clocks. So the clock initialization is
> >> initiated here. + */
> >> + if (of_have_populated_dt()) {
> >> + if (of_machine_is_compatible("samsung,exynos4210") ||
> >> + of_machine_is_compatible("samsung,exynos4212")
> >> || +
> >> of_machine_is_compatible("samsung,exynos4412")) +
> >> exynos4_clk_init();
> >> + } else {
> >> + if (soc_is_exynos4210() || soc_is_exynos4212() ||
> >> + soc_is_exynos4412()) {
> >> + exynos4_clk_init();
> >> + }
> >> + }
> >> +#endif
> >> +
> >
> > I don't like the idea of initializing the clocks from timer
> > initialization. What about some platforms where MCT isn't used? It is
> > also far from being elegant.
>
> Very true, I did also prefer not do this. But, clock lookup should be
> functional atleast by the time mct initialization begins. So I tried
> few options such as adding .early_init_call callback in MACHINE_DESC
> which then can call exynos4_clk_init, but that did not help since
> mem_init isn't complete by then and memory allocation failed during
> clock registration. Other methods also did not help much. If you know
> of a solution to get around this, could you please let me know.
This is somehow similar to the problem with mapping SYSRAM_NS for Exynos
secure firmware. Currently it must be mapped statically using io_table,
because ioremap does not work early enough. I guess this kind of approach
might be also enough for clocks, until io mem mapping becomes accessible
early enough, but someone else should also comment this.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Linus Walleij @ 2012-11-15 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A146E7.2040608@wwwdotorg.org>
On Mon, Nov 12, 2012 at 7:58 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/12/2012 11:43 AM, Anton Vorontsov wrote:
>> Should the gpio driver fix its bindings then?.. Polarity is a quite
>> generic concept of a GPIO, and flags are there for a reason. I'd rather
>> prefer having
>
> There is no "GPIO driver" to fix; each GPIO driver has its own bindings,
> and unfortunately, some of the GPIO binding authors chose not to include
> any flags cell in the GPIO specifier (e.g. Samsung ARM SoCs IIRC, but
> there are probably more).
So can I read this something like we have been too liberal with the
GPIO DT bindings and they are now a bit messy and need to be shaped
up? I don't know how to achieve that :-(
Alerting Grant to see if he has something to add on this subject...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/2] Boottime: measure bootloader and kernel bootup time
From: Lee Jones @ 2012-11-15 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115101508.GB4398@game.jcrosoft.org>
On Thu, 15 Nov 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:04 Thu 15 Nov , Lee Jones wrote:
> > This patchset supplies a new tool which measures boottime inclusive
> > of bootloader involvement. It seems to be accurate and adds no
> > latency to the booting of the system.
> >
> > In the first round of testing we booted the kernel 3 times each with
> > boottime enabled and disabled. Actually, when it was disabled, the
> > code was completely removed from the kernel source and the kernel was
> > rebuilt. The difference between present & enabled and completely
> > removed was very little indeed. In fact, averaging out the 3 runs of
> > each, when boottime was enabled the system booted 4ms _faster_, go
> > figure!
> >
> > Enabled Disabled
> > 1st run 2.983093 2.985168
> > 2nd run 2.973266 2.971801
> > 3rd run 2.975402 2.987304
> > Average 2.977254 2.981424 -0.004171 (-4ms)
> >
> >
> > For the next round of testing, we delayed the bootloader for varying
> > amounts of time, then started to remove key components from kernel
> > functionality to see if the boottime system would pick-up on them.
> >
> > /* Hang around in the bootloader for a while. */
> > $ cat /sys/kernel/debug/boottime/summary
> > kernel: 42864 msecs
> > total: 42864 msecs
> > kernel: cpu0 system: 56% idle: 43% iowait: 0% irq: 0%
> > cpu1 system: 4% idle: 95% iowait: 0% irq: 0%
> >
> > /* Hang around in the bootloader for a smaller amount of time. */
> > kernel: 12351 msecs
> > total: 12351 msecs
> > kernel: cpu0 system: 56% idle: 43% iowait: 0% irq: 0%
> > cpu1 system: 2% idle: 97% iowait: 0% irq: 0%
> >
> > /* Instant boot. (1st run) */
> > kernel: 7833 msecs
> > total: 7833 msecs
> > kernel: cpu0 system: 55% idle: 44% iowait: 0% irq: 0%
> > cpu1 system: 3% idle: 96% iowait: 0% irq: 0%
> >
> > /* Instant boot. (2nd run) */
> > kernel: 7817 msecs
> > total: 7817 msecs
> > kernel: cpu0 system: 53% idle: 46% iowait: 0% irq: 0%
> > cpu1 system: 8% idle: 91% iowait: 0% irq: 0%
> >
> > /* Instant boot. (3rd run) */
> > kernel: 7747 msecs
> > total: 7747 msecs
> > kernel: cpu0 system: 56% idle: 42% iowait: 0% irq: 0%
> > cpu1 system: 2% idle: 97% iowait: 0% irq: 0%
> 7/8s? on a u9500 wow it's really slow
No, this is a u8500.
> I do 2/3s here
Really? You installed this quick.
Are you sure you did it correctly?
Don't forget, this times from power-on to userspace.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 0/2] clk: ux500: Make mtu driver use apb_pclock
From: Linus Walleij @ 2012-11-15 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112183615.17970.20162@nucleus>
On Mon, Nov 12, 2012 at 7:36 PM, Mike Turquette <mturquette@ti.com> wrote:
> Quoting Linus Walleij (2012-11-11 10:47:46)
>> I don't know quite how ingenious git is in detecting
>> patches on moved files, but if it's causing trouble
>> I think it's better if you could ACK them and we
>> could reubmit them to ARM SoC on the multiplatform
>> branch. i.e. this one:
>> http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=shortlog;h=refs/heads/next/multiplatform
>>
>
> Those patches have my ACK. Do you want to wait to see if something goes
> boom or would you rather I drop them from clk-next preemptively?
Hm that's basically a question of how smart git is when
merging these trees together.
Arnd, Olof: what is your experience? If one tree is moving
files and another tree is patching them, should we try to
rebase these onto your branch in ARM SoC and submit
them there instead?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 01/11] clk: samsung: add common clock framework helper functions for Samsung platforms
From: Tomasz Figa @ 2012-11-15 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwR=9Gx5kx-JwVNUaa8Tej-3NG03U4zbYBKr36rPAOtPvw@mail.gmail.com>
On Thursday 15 of November 2012 14:03:12 Thomas Abraham wrote:
> Hi Tomasz,
>
> Thanks for reviewing these patches!
>
> On 15 November 2012 04:42, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> > Hi Thomas,
> >
> > Looks mostly good, but I have some minor comments inline.
> >
> > On Thursday 15 of November 2012 03:37:23 Thomas Abraham wrote:
> >> All Samsung platforms include different types of clock including
> >> fixed-rate, mux, divider and gate clock types. There are typically
> >> hundreds of such clocks on each of the Samsung platforms. To enable
> >> Samsung platforms to register these clocks using the common clock
> >> framework, a bunch of utility functions are introduced here which
> >> simplify the clock registration process. The clocks are usually
> >> statically instantiated and registered with common clock framework.
> >>
> >> Cc: Mike Turquette <mturquette@linaro.org>
> >> Cc: Kukjin Kim <kgene.kim@samsung.com>
> >> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> >> ---
> >>
> >> drivers/clk/Makefile | 1 +
> >> drivers/clk/samsung/Makefile | 5 +
> >> drivers/clk/samsung/clk.c | 176
> >> ++++++++++++++++++++++++++++++++++
> >> drivers/clk/samsung/clk.h | 218
> >>
> >> ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 400
> >> insertions(+), 0 deletions(-)
> >>
> >> create mode 100644 drivers/clk/samsung/Makefile
> >> create mode 100644 drivers/clk/samsung/clk.c
> >> create mode 100644 drivers/clk/samsung/clk.h
> >>
> >> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> >> index 2701235..808f8e1 100644
> >> --- a/drivers/clk/Makefile
> >> +++ b/drivers/clk/Makefile
> >> @@ -19,6 +19,7 @@ endif
> >>
> >> obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
> >> obj-$(CONFIG_ARCH_U8500) += ux500/
> >> obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
> >>
> >> +obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
> >>
> >> # Chip specific
> >> obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
> >>
> >> diff --git a/drivers/clk/samsung/Makefile
> >> b/drivers/clk/samsung/Makefile new file mode 100644
> >> index 0000000..3f926b0
> >> --- /dev/null
> >> +++ b/drivers/clk/samsung/Makefile
> >> @@ -0,0 +1,5 @@
> >> +#
> >> +# Samsung Clock specific Makefile
> >> +#
> >> +
> >> +obj-$(CONFIG_PLAT_SAMSUNG) += clk.o
> >> diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
> >> new file mode 100644
> >> index 0000000..ebc6fb6
> >> --- /dev/null
> >> +++ b/drivers/clk/samsung/clk.c
> >> @@ -0,0 +1,176 @@
> >> +/*
> >> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> >> + * Copyright (c) 2012 Linaro Ltd.
> >> + * Author: Thomas Abraham <thomas.ab@samsung.com>
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> modify + * it under the terms of the GNU General Public License
> >> version 2 as + * published by the Free Software Foundation.
> >> + *
> >> + * This file includes utility functions to register clocks to common
> >> + * clock framework for Samsung platforms.
> >> +*/
> >> +
> >> +#include "clk.h"
> >> +
> >> +static DEFINE_SPINLOCK(lock);
> >> +static struct clk **clk_table;
> >> +static struct clk_onecell_data clk_data;
> >> +void __iomem *reg_base;
> >
> > Shouldn't it be static?
>
> Yes, I missed that. Will fix.
>
> >> +
> >> +/* setup the essentials required to support clock lookup using ccf
> >> */
> >> +void __init samsung_clk_init(struct device_node *np, void __iomem
> >> *base, + unsigned long nr_clks)
> >> +{
> >> + reg_base = base;
> >> + if (!np)
> >> + return;
> >> +
> >> + clk_table = kzalloc(sizeof(struct clk *) * nr_clks,
> >> GFP_KERNEL);
> >> + if (!clk_table)
> >> + panic("could not allocate clock lookup table\n");
> >> +
> >> + clk_data.clks = clk_table;
> >> + clk_data.clk_num = nr_clks;
> >> + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> >> +}
> >> +
> >> +/* add a clock instance to the clock lookup table used for dt based
> >> lookup */ +void samsung_clk_add_lookup(struct clk *clk, unsigned int
> >> id) +{
> >> + if (clk_table && id)
> >
> > I'm not sure if we really need this kind of checks, but if we do, then
> > shouldn't we also check id against clk_data.clk_num to prevent out of
> > bound index?
>
> The entry into the lookup table is required only for device tree based
> platforms. And clk_table is a dynamically allocated table if booting
> with device tree support. Since the call to samsung_clk_add_lookup is
> made for non-dt platforms as well, the check for clk_table ensures
> that the entry to lookup table is done only for device tree enabled
> platforms. The check for 'id' ensures that the lookup entry index 0 is
> not used. There is no clock which has id as 0.
>
> >> + clk_table[id] = clk;
> >> +}
> >> +
> >> +/* register a list of fixed clocks */
> >> +void __init samsung_clk_register_fixed_rate(
> >> + struct samsung_fixed_rate_clock *list, unsigned int
> >> nr_clk) +{
> >> + struct clk *clk;
> >> + unsigned int idx, ret;
> >> +
> >> + for (idx = 0; idx < nr_clk; idx++, list++) {
> >> + clk = clk_register_fixed_rate(NULL, list->name,
> >> + list->parent_name, list->flags,
> >> list->fixed_rate); + if (IS_ERR(clk)) {
> >> + pr_err("%s: failed to register clock %s\n",
> >> __func__, + list->name);
> >> + continue;
> >> + }
> >> +
> >> + samsung_clk_add_lookup(clk, list->id);
> >> +
> >> + /*
> >> + * Unconditionally add a clock lookup for the fixed
> >> rate
> >
> > clocks.
> >
> >> + * There are not many of these on any of Samsung
> >> platforms. + */
> >> + ret = clk_register_clkdev(clk, list->name, NULL);
> >> + if (ret)
> >> + pr_err("%s: failed to register clock lookup for
> >> %s", + __func__, list->name);
> >> + }
> >> +}
> >> +
> >> +/* register a list of mux clocks */
> >> +void __init samsung_clk_register_mux(struct samsung_mux_clock *list,
> >> + unsigned int nr_clk)
> >> +{
> >> + struct clk *clk;
> >> + unsigned int idx, ret;
> >> +
> >> + for (idx = 0; idx < nr_clk; idx++, list++) {
> >> + clk = clk_register_mux(NULL, list->name,
> >> list->parent_names, + list->num_parents,
> >> list->flags, reg_base + list->offset, +
> >> list->shift, list->width, list->mux_flags, &lock); + if
> >> (IS_ERR(clk)) {
> >> + pr_err("%s: failed to register clock %s\n",
> >> __func__, + list->name);
> >> + continue;
> >> + }
> >> +
> >> + samsung_clk_add_lookup(clk, list->id);
> >> +
> >> + /* register a clock lookup only if a clock alias is
> >> specified>
> > */
> >
> >> + if (list->alias) {
> >> + ret = clk_register_clkdev(clk, list->alias,
> >> + list->dev_name);
> >> + if (ret)
> >> + pr_err("%s: failed to register lookup
> >> %s\n", + __func__,
> >> list->alias); + }
> >> + }
> >> +}
> >> +
> >> +/* register a list of div clocks */
> >> +void __init samsung_clk_register_div(struct samsung_div_clock *list,
> >> + unsigned int nr_clk)
> >> +{
> >> + struct clk *clk;
> >> + unsigned int idx, ret;
> >> +
> >> + for (idx = 0; idx < nr_clk; idx++, list++) {
> >> + clk = clk_register_divider(NULL, list->name, list-
> >>
> >>parent_name,
> >>
> >> + list->flags, reg_base + list->offset,
> >> list->shift, + list->width, list->div_flags,
> >> &lock);
> >> + if (IS_ERR(clk)) {
> >> + pr_err("clock: failed to register clock %s\n",
> >> + list->name);
> >> + continue;
> >> + }
> >> +
> >> + samsung_clk_add_lookup(clk, list->id);
> >> +
> >> + /* register a clock lookup only if a clock alias is
> >> specified>
> > */
> >
> >> + if (list->alias) {
> >> + ret = clk_register_clkdev(clk, list->alias,
> >> + list->dev_name);
> >> + if (ret)
> >> + pr_err("%s: failed to register lookup
> >> %s\n", + __func__,
> >> list->alias); + }
> >> + }
> >> +}
> >> +
> >> +/* register a list of gate clocks */
> >> +void __init samsung_clk_register_gate(struct samsung_gate_clock
> >> *list,
> >> + unsigned int nr_clk)
> >> +{
> >> + struct clk *clk;
> >> + unsigned int idx, ret;
> >> +
> >> + for (idx = 0; idx < nr_clk; idx++, list++) {
> >> + clk = clk_register_gate(NULL, list->name,
> >> list->parent_name, + list->flags,
> >> reg_base + list->offset, +
> >> list->bit_idx, list->gate_flags, &lock); + if
> >> (IS_ERR(clk)) {
> >> + pr_err("clock: failed to register clock %s\n",
> >> + list->name);
> >> + continue;
> >> + }
> >> +
> >> + /* register a clock lookup only if a clock alias is
> >> specified>
> > */
> >
> >> + if (list->alias) {
> >> + ret = clk_register_clkdev(clk, list->alias,
> >> +
> >> list->dev_name);
> >> + if (ret)
> >> + pr_err("%s: failed to register lookup
> >> %s\n", + __func__, list->alias);
> >> + }
> >> +
> >> + samsung_clk_add_lookup(clk, list->id);
> >> + }
> >> +}
> >> +
> >> +/* utility function to get the rate of a specified clock */
> >> +unsigned long _get_rate(const char *clk_name)
> >> +{
> >> + struct clk *clk;
> >> + unsigned long rate;
> >> +
> >> + clk = clk_get(NULL, clk_name);
> >> + if (IS_ERR(clk))
> >> + return 0;
> >> + rate = clk_get_rate(clk);
> >> + clk_put(clk);
> >> + return rate;
> >> +}
> >> diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
> >> new file mode 100644
> >> index 0000000..ab43498
> >> --- /dev/null
> >> +++ b/drivers/clk/samsung/clk.h
> >> @@ -0,0 +1,218 @@
> >> +/*
> >> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> >> + * Copyright (c) 2012 Linaro Ltd.
> >> + * Author: Thomas Abraham <thomas.ab@samsung.com>
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> modify + * it under the terms of the GNU General Public License
> >> version 2 as + * published by the Free Software Foundation.
> >> + *
> >> + * Common Clock Framework support for all Samsung platforms
> >> +*/
> >> +
> >> +#ifndef __SAMSUNG_CLK_H
> >> +#define __SAMSUNG_CLK_H
> >> +
> >> +#include <linux/clk.h>
> >> +#include <linux/clkdev.h>
> >> +#include <linux/io.h>
> >> +#include <linux/clk-provider.h>
> >> +#include <linux/of.h>
> >> +#include <linux/of_address.h>
> >> +
> >> +#include <mach/map.h>
> >> +
> >> +/**
> >> + * struct samsung_fixed_rate_clock: information about fixed-rate
> >> clock
> >> + * @id: platform specific id of the clock.
> >> + * @name: name of this fixed-rate clock.
> >> + * @parent_name: optional parent clock name.
> >> + * @flags: optional fixed-rate clock flags.
> >> + * @fixed-rate: fixed clock rate of this clock.
> >> + */
> >> +struct samsung_fixed_rate_clock {
> >> + unsigned int id;
> >> + char *name;
> >
> > Shouldn't it be const char *name?
>
> Yes, I will fix this.
>
> >> + const char *parent_name;
> >> + unsigned long flags;
> >> + unsigned long fixed_rate;
> >> +};
> >> +
> >> +#define FRATE(_id, cname, pname, f, frate) \
> >> + { \
> >> + .id = _id, \
> >> + .name = cname, \
> >> + .parent_name = pname, \
> >> + .flags = f, \
> >> + .fixed_rate = frate, \
> >> + }
> >> +
> >> +/**
> >> + * struct samsung_mux_clock: information about mux clock
> >> + * @id: platform specific id of the clock.
> >> + * @dev_name: name of the device to which this clock belongs.
> >> + * @name: name of this mux clock.
> >> + * @parent_names: array of pointer to parent clock names.
> >> + * @num_parents: number of parents listed in @parent_names.
> >> + * @flags: optional flags for basic clock.
> >> + * @offset: offset of the register for configuring the mux.
> >> + * @shift: starting bit location of the mux control bit-field in
> >> @reg.
> >> + * @width: width of the mux control bit-field in @reg.
> >> + * @mux_flags: flags for mux-type clock.
> >> + * @alias: optional clock alias name to be assigned to this clock.
> >> + */
> >> +struct samsung_mux_clock {
> >> + const unsigned int id;
> >
> > Is const unsigned int really correct?
>
> Sorry, I did not get the problem here.
Basically this const does not give us anything, while it could make
problems in future.
Let's say that one would want to register a clock in runtime, dynamically
allocating a samsung_*_clock structure. It wouldn't be possible, because
he wouldn't be able to set the id field.
Instead of making particular fields in the structures constant, I would
prefer making the arrays of these structures constant, as they are
statically initialized anyway.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ 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