* [PATCH v7 2/5] usb: s3c-hsotg: Adding phy driver support
From: Lukasz Majewski @ 2012-10-31 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121031140548.GE10998@arwen.pp.htv.fi>
Hi Felipe,
> Hi,
>
> On Tue, Oct 30, 2012 at 10:27:34AM +0530, Praveen Paneri wrote:
> > @@ -3501,20 +3511,27 @@ static int __devinit s3c_hsotg_probe(struct
> > platform_device *pdev) int ret;
> > int i;
> >
> > - plat = pdev->dev.platform_data;
> > - if (!plat) {
> > - dev_err(&pdev->dev, "no platform data defined\n");
> > - return -EINVAL;
> > - }
> > -
> > hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg),
> > GFP_KERNEL); if (!hsotg) {
> > dev_err(dev, "cannot get memory\n");
> > return -ENOMEM;
> > }
> >
> > + plat = pdev->dev.platform_data;
> > + if (!plat) {
> > + /* Fallback for transceiver */
> > + phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> > + if (IS_ERR_OR_NULL(phy)) {
> > + dev_err(&pdev->dev, "no platform data or
> > transceiver defined\n");
> > + return -EPROBE_DEFER;
> > + } else {
> > + hsotg->phy = phy;
> > + }
> > + } else {
> > + hsotg->plat = plat;
> > + }
>
> I think this should be the other way around, meaning you try to grab
> the phy, if you can't, then you fallback to pdata.
>
I agree.
The new approach is to use new PHY driver. And only when failed we
shall use legacy approach.
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
^ permalink raw reply
* [PATCH 1/3] irqchip: Move ARM GIC to drivers/irqchip
From: Rob Herring @ 2012-10-31 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121031115627.GA9123@localhost.conference>
On 10/31/2012 06:56 AM, Catalin Marinas wrote:
> On Wed, Oct 31, 2012 at 12:04:38AM +0000, Rob Herring wrote:
>> On 10/30/2012 05:47 PM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 30, 2012 at 12:21:20PM -0500, Rob Herring wrote:
>>>> Looking at this some more, arm64 doesn't need most of what's in gic.h.
>>>> The register defines should be moved into the .c file. The remaining
>>>> function declarations either are not needed (i.e. gic_init) or should
>>>> should be done like the handle_irq function pointer init. We don't want
>>>> to have platform code calling gic_cascade_irq or gic_raise_softirq
>>>> directly.
>>>
>>> Softirqs are about the SPIs which are used for SMP IPIs and platform
>>> specific wakeup of CPUs. And platform code _needs_ to specify the
>>> way IPIs are delivered on the platform. irqchip can't do that because
>>> irqchip knows nothing about SPIs (neither does genirq.)
>>
>> Right. v7 is unchanged, so the question is really only about how v8 will
>> do this. Hopefully, ARM is standardizing this for v8. We probably want
>> the gic (or other irqchip) to setup a raise_softirq function ptr on init
>> rather than having a direct call to gic_raise_softirq.
>
> In my sample ARMv8 model code I have an older version of gic.c moved to
> drivers/irqchip and modified just for the arm64 needs. The gic_of_init()
> function calls set_smp_cross_call(git_raise_softirq).
>
> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-aarch64.git;a=commitdiff;h=5cd20480f4d7b56160b3312df14fba3b2bda6798
>
> The gic_secondary_init() is done from a CPU notifier as I wanted to
> separate this from the SoC code (even on arch/arm, all the calls to
> gic_secondary_init() are the same, so it could be factored out to a
> notifier or some function pointer set by gic.c).
>
> And let's assume there is no need for gic_cascade_irq().
What about other asm header dependencies? cpu_logical_map is needed for
example. I guess I'll leave all those for now.
Rob
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Mark Jackson @ 2012-10-31 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB563F8@DBDE01.ent.ti.com>
On 31/10/12 13:57, Hiremath, Vaibhav wrote:
> On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote:
>>
>> If I try the latest mainline U-Boot (or the TI branch), I just get to "Starting kernel ..." and then
>> hangs.
>>
>
>
> I am using Mainline u-boot and it works for me. Can you paste u-boot boot
> log and environment variable here?
------------------------
mainline U-Boot boot log
------------------------
U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50)
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: cpsw
Hit any key to stop autoboot: 0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
29 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
4315695 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux-3.7.0-rc1-47802-ge7289dc-d
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4308448 Bytes = 4.1 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
------------------------
Contents of uEnv.txt
--------------------
mmcrootfstype=ext2 rootwait
^ permalink raw reply
* [PATCH RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib
From: Linus Walleij @ 2012-10-31 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351457210-25222-2-git-send-email-stigge@antcom.de>
On Sun, Oct 28, 2012 at 9:46 PM, Roland Stigge <stigge@antcom.de> wrote:
Just a quick few things I spotted:
> +struct gpio_block *gpio_block_create(unsigned *gpios, size_t size,
> + const char *name)
> +{
> + struct gpio_block *block;
> + struct gpio_block_chip *gbc;
> + struct gpio_remap *remap;
> + void *tmp;
> + int i;
> +
> + if (size < 1 || size > sizeof(unsigned long) * 8)
> + return ERR_PTR(-EINVAL);
If the most GPIOs in a block is BITS_PER_LONG, why is the
latter clause not size > BITS_PER_LONG?
Maybe there was some discussion I missed, anyway it deserves
a comment because this looks completely arbitrary.
> + for (i = 0; i < size; i++)
> + if (!gpio_is_valid(gpios[i]))
> + return ERR_PTR(-EINVAL);
> +
> + block = kzalloc(sizeof(struct gpio_block), GFP_KERNEL);
> + if (!block)
> + return ERR_PTR(-ENOMEM);
If these were instead glued to a struct device you could do
devm_kzalloc() here and have it garbage collected.
This is why
https://blueprints.launchpad.net/linux-linaro/+spec/gpiochip-to-dev
needs to happen. (Sorry for hyperlinking.)
> + block->name = name;
> + block->ngpio = size;
> + block->gpio = kzalloc(sizeof(*block->gpio) * size, GFP_KERNEL);
> + if (!block->gpio)
> + goto err1;
> +
> + memcpy(block->gpio, gpios, sizeof(*block->gpio) * size);
> +
> + for (i = 0; i < size; i++) {
> + struct gpio_chip *gc = gpio_to_chip(gpios[i]);
> + int bit = gpios[i] - gc->base;
> + int index = gpio_block_chip_index(block, gc);
> +
> + if (index < 0) {
> + block->nchip++;
> + tmp = krealloc(block->gbc,
> + sizeof(struct gpio_block_chip) *
> + block->nchip, GFP_KERNEL);
Don't do this dynamic array business. Use a linked list instead.
> + if (!tmp) {
> + kfree(block->gbc);
> + goto err2;
> + }
> + block->gbc = tmp;
> + gbc = &block->gbc[block->nchip - 1];
So this becomes a list traversal and lookup instead.
> + gbc->gc = gc;
> + gbc->remap = NULL;
> + gbc->nremap = 0;
> + gbc->mask = 0;
> + } else {
> + gbc = &block->gbc[index];
So find it in the list instead.
> + }
> + /* represents the mask necessary on calls to the driver's
> + * .get_block() and .set_block()
> + */
> + gbc->mask |= BIT(bit);
> +
> + /* collect gpios that are specified together, represented by
> + * neighboring bits
> + *
> + * Note that even though in setting remap is given a negative
> + * index, the next lines guard that the potential out-of-bounds
> + * pointer is not dereferenced when out of bounds.
> + */
/*
* Maybe I'm a bit picky on comment style but I prefer
* that the first line of a multi-line comment is blank.
* Applies everywhere.
*/
> + remap = &gbc->remap[gbc->nremap - 1];
> + if (!gbc->nremap || (bit - i != remap->offset)) {
> + gbc->nremap++;
> + tmp = krealloc(gbc->remap,
> + sizeof(struct gpio_remap) *
> + gbc->nremap, GFP_KERNEL);
I don't like this dynamic array either.
Basic pattern: wherever there is a krealloc, use a list.
If lists aren't efficient enough, use some other datastructure, rbtree or
whatever.
> + if (!tmp) {
> + kfree(gbc->remap);
> + goto err3;
> + }
> + gbc->remap = tmp;
> + remap = &gbc->remap[gbc->nremap - 1];
> + remap->offset = bit - i;
> + remap->mask = 0;
> + }
> +
> + /* represents the mask necessary for bit reordering between
> + * gpio_block (i.e. as specified on gpio_block_get() and
> + * gpio_block_set()) and gpio_chip domain (i.e. as specified on
> + * the driver's .set_block() and .get_block())
> + */
> + remap->mask |= BIT(i);
> + }
> +
> + return block;
> +err3:
> + for (i = 0; i < block->nchip - 1; i++)
> + kfree(block->gbc[i].remap);
> + kfree(block->gbc);
> +err2:
> + kfree(block->gpio);
> +err1:
> + kfree(block);
> + return ERR_PTR(-ENOMEM);
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_create);
> +
> +void gpio_block_free(struct gpio_block *block)
> +{
> + int i;
> +
> + for (i = 0; i < block->nchip; i++)
> + kfree(block->gbc[i].remap);
> + kfree(block->gpio);
> + kfree(block->gbc);
> + kfree(block);
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_free);
So if we only had a real struct device inside the gpiochip all
this boilerplate would go away, as devm_* take care of releasing
the resources.
> +unsigned long gpio_block_get(const struct gpio_block *block)
> +{
> + struct gpio_block_chip *gbc;
> + int i, j;
> + unsigned long values = 0;
> +
> + for (i = 0; i < block->nchip; i++) {
> + unsigned long remapped = 0;
> +
> + gbc = &block->gbc[i];
> +
> + if (gbc->gc->get_block) {
> + remapped = gbc->gc->get_block(gbc->gc, gbc->mask);
> + } else {
> + /* emulate */
> + for_each_set_bit(j, &gbc->mask, BITS_PER_LONG)
> + remapped |= gbc->gc->get(gbc->gc,
> + gbc->gc->base + j) << j;
> + }
> +
> + for (j = 0; j < gbc->nremap; j++) {
> + struct gpio_remap *gr = &gbc->remap[j];
> +
> + values |= (remapped >> gr->offset) & gr->mask;
> + }
> + }
> +
> + return values;
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_get);
> +
> +void gpio_block_set(struct gpio_block *block, unsigned long values)
> +{
> + struct gpio_block_chip *gbc;
> + int i, j;
> +
> + for (i = 0; i < block->nchip; i++) {
> + unsigned long remapped = 0;
> +
> + gbc = &block->gbc[i];
> +
> + for (j = 0; j < gbc->nremap; j++) {
> + struct gpio_remap *gr = &gbc->remap[j];
> +
> + remapped |= (values & gr->mask) << gr->offset;
> + }
> + if (gbc->gc->set_block) {
> + gbc->gc->set_block(gbc->gc, gbc->mask, remapped);
> + } else {
> + /* emulate */
> + for_each_set_bit(j, &gbc->mask, BITS_PER_LONG)
> + gbc->gc->set(gbc->gc, gbc->gc->base + j,
> + (remapped >> j) & 1);
> + }
> + }
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_set);
> +
> +struct gpio_block *gpio_block_find_by_name(const char *name)
> +{
> + struct gpio_block *i;
> +
> + list_for_each_entry(i, &gpio_block_list, list)
> + if (!strcmp(i->name, name))
> + return i;
And here is a list anyway, I'm getting confused of this partitioning between
using dynamic arrays and lists. Just use a list please. This part looks
good.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 2/5] usb: s3c-hsotg: Adding phy driver support
From: Felipe Balbi @ 2012-10-31 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351573057-22249-3-git-send-email-p.paneri@samsung.com>
Hi,
On Tue, Oct 30, 2012 at 10:27:34AM +0530, Praveen Paneri wrote:
> @@ -3501,20 +3511,27 @@ static int __devinit s3c_hsotg_probe(struct platform_device *pdev)
> int ret;
> int i;
>
> - plat = pdev->dev.platform_data;
> - if (!plat) {
> - dev_err(&pdev->dev, "no platform data defined\n");
> - return -EINVAL;
> - }
> -
> hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg), GFP_KERNEL);
> if (!hsotg) {
> dev_err(dev, "cannot get memory\n");
> return -ENOMEM;
> }
>
> + plat = pdev->dev.platform_data;
> + if (!plat) {
> + /* Fallback for transceiver */
> + phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> + if (IS_ERR_OR_NULL(phy)) {
> + dev_err(&pdev->dev, "no platform data or transceiver defined\n");
> + return -EPROBE_DEFER;
> + } else {
> + hsotg->phy = phy;
> + }
> + } else {
> + hsotg->plat = plat;
> + }
I think this should be the other way around, meaning you try to grab the
phy, if you can't, then you fallback to pdata.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/6d31b60c/attachment.sig>
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Haojian Zhuang @ 2012-10-31 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509032F6.1050301@gmail.com>
On Wed, Oct 31, 2012 at 4:05 AM, Daniel Mack <zonque@gmail.com> wrote:
> On 30.10.2012 21:01, Vasily Khoruzhick wrote:
> > On Mon, Oct 29, 2012 at 2:14 PM, Daniel Mack <zonque@gmail.com> wrote:
> >> On 29.10.2012 12:12, Vasily Khoruzhick wrote:
> >>> On Mon, Oct 29, 2012 at 2:00 PM, Daniel Mack <zonque@gmail.com> wrote:
> >>>
> >>>>> Well, there's an issue - Z2 does not preserve memory contents in
> deep sleep
> >>>>> (but it does in sleep), so userspace can't be fixed here
> unfortunatelly.
> >>>>> There's no another possibility to turn Z2 off, and plain sleep is too
> >>>>> power hungry.
> >>>>> So the only way to keep Z2 in low-power mode is fake power off,
> which just puts
> >>>>> Z2 in deep sleep.
> >>>>
> >>>> Why can't the userspace trigger a deep sleep then instead of powering
> >>>> off? Which details do I lack?
> >>>
> >>> How? echo mem >/sys/power/state puts system into non-deep sleep.
> Anyway, kernel
> >>> is not ready for fake power off instead of suspend (we can't resume
> >>> from deep sleep,
> >>> memory content is not preserved), so there can be some data loss.
> >>> Adding some sysfs file to control sleep type does not look like a good
> >>> idea to me.
> >>>
> >>> Btw, how other DT-capable boards handle power off?
> >>
> >> No idea. I never actually used that kind of power state.
> >
> > Hi Daniel,
> >
> > One more question: what should I use instead of pxa2xx_mfp_config in
> > DT board to configure pin modes?
>
> Haojian was working on the PXA pinctrl drivers, but I don't know how far
> that is yet.
>
> If that's not yet there, have a look at the pinctrl-single driver. It's
> admittedly not as nice to use as the constants in the board file as DT
> lacks defines for numerical constants, but's at least a workaround.
>
> On a more general note, it's arguable whether this kind of setup should
> be done in the bootloader after all.
>
>
> Daniel
>
>
Using pinctrl-single driver is preferred. I'm converting mmp pinctrl driver
into pinctrl-single
driver. I'll submit a new round in these days.
Thanks
Haojian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/bcac3740/attachment-0001.html>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Hiremath, Vaibhav @ 2012-10-31 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50912A6F.1040501@mimc.co.uk>
On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote:
> On 30/10/12 14:48, Vaibhav Hiremath wrote:
> >
> >
> > On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote:
> >>
> >> Mark,
> >>
> >> MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> >> already submitted to the list recently. So MMC support will come along with
> >> EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
> >>
> >>
> >> If you refer to the Matt's repo, you should get all the patches required to
> >> boot MMC support -
> >>
> >> https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3
> >>
> >>
> >
> > I just tested this branch (+ one fix which Matt provided [1]) on
> > BeagleBone, and MMC is working without any issues. I have tested with
> > rootFS on MMC card.
> >
> >
> > [1] - http://www.spinics.net/lists/linux-omap/msg79911.html
>
> Okay, so I'm now coming up against a brick wall regarding U-Boot.
>
> The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the
> v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git
>
> If I try the latest mainline U-Boot (or the TI branch), I just get to "Starting kernel ..." and then
> hangs.
>
> I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're
> using ?
>
I am using Mainline u-boot and it works for me. Can you paste u-boot boot
log and environment variable here?
Thanks,
Vaibhav
> Cheers
> Mark J.
>
^ permalink raw reply
* [PATCH v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
From: Guennadi Liakhovetski @ 2012-10-31 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CLxM41LYoLmPbfzSTF85Zk4B5SqHeVbGU4WjEOXw0eyg@mail.gmail.com>
On Wed, 31 Oct 2012, Fabio Estevam wrote:
> Hi Sascha,
>
> On Wed, Oct 31, 2012 at 11:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> > Quoting yourself:
> >
> >> Forgot to comment: as patch 2 relies on this change, the better, IMHO, is
> >> to send both via the same tree. If you decide to do so, please get arm
> >> maintainer's ack, instead, and we can merge both via my tree.
> >
> > That's why Fabio resent these patches with my Ack. You are free to take
> > these.
>
> I have just realized that this patch (1/2) will not apply against
> media tree because it does not have commit 27b76486a3 (media:
> mx2_camera: remove cpu_is_xxx by using platform_device_id), which
> changes from mx2_camera.0 to imx27-camera.0.
This is exactly the reason why I wasn't able to merge it. The problem was,
that this "media: mx2_camera: remove cpu_is_xxx by using
platform_device_id" patch non-trivially touched both arch/arm/ and
drivers/media/ directories. And being patch 27/34 I didn't feel like
asking the author to redo it again:-) This confirms, that it's better to
avoid such overlapping patches whenever possible.
> So it seems to be better to merge this via arm tree to avoid such conflict.
Thanks
Guennadi
> Regards,
>
> Fabio Estevam
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH v3 01/11] clk: davinci - add main PLL clock driver
From: Murali Karicheri @ 2012-10-31 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509119AE.6050505@ti.com>
On 10/31/2012 08:29 AM, Sekhar Nori wrote:
> Hi Murali,
>
> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>> This is the driver for the main PLL clock hardware found on DM SoCs.
>> This driver borrowed code from arch/arm/mach-davinci/clock.c and
>> implemented the driver as per common clock provider API. The main PLL
>> hardware typically has a multiplier, a pre-divider and a post-divider.
>> Some of the SoCs has the divider fixed meaning they can not be
>> configured through a register. HAS_PREDIV and HAS_POSTDIV flags are used
>> to tell the driver if a hardware has these dividers present or not.
>> Driver is configured through the struct clk_pll_data that has the
>> SoC specific clock data.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> ---
>> diff --git a/drivers/clk/davinci/clk-pll.c b/drivers/clk/davinci/clk-pll.c
>> +static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
>> + unsigned long parent_rate)
>> +{
>> + struct clk_pll *pll = to_clk_pll(hw);
>> + struct clk_pll_data *pll_data = pll->pll_data;
>> + u32 mult = 1, prediv = 1, postdiv = 1;
> No need to initialize mult here. I gave this comment last time around as
> well.
Yes. I missed it. I will fix it in the next revision.
>> + unsigned long rate = parent_rate;
>> +
>> + mult = readl(pll_data->reg_pllm);
>> +
>> + /*
>> + * if fixed_multiplier is non zero, multiply pllm value by this
>> + * value.
>> + */
>> + if (pll_data->fixed_multiplier)
>> + mult = pll_data->fixed_multiplier *
>> + (mult & pll_data->pllm_mask);
>> + else
>> + mult = (mult & pll_data->pllm_mask) + 1;
> Hmm, this is interpreting the 'mult' register field differently in both
> cases. In one case it is 'actual multiplier - 1' and in other case it is
> the 'actual multiplier' itself. Can we be sure that the mult register
> definition will change whenever there is a fixed multiplier in the PLL
> block? I don't think any of the existing DaVinci devices have a fixed
> multiplier. Is this on keystone?
Read section 6.4.3 (PLL Mode) in DM365 documentation (SPRUFG5a.pdf) that
states PLL multiplies the clock by 2x the value in the PLLM. In the old
code this is handled by a if cpu_is_* macro that we can't use in the
driver. So this is represented by a fixed_multiplier that can be set to
2 for DM365 and zero on other SoCs.
>> +struct clk *clk_register_davinci_pll(struct device *dev, const char *name,
>> + const char *parent_name,
>> + struct clk_pll_data *pll_data)
>> +{
>> + struct clk_init_data init;
>> + struct clk_pll *pll;
>> + struct clk *clk;
>> +
>> + if (!pll_data)
>> + return ERR_PTR(-ENODEV);
> -EINVAL? Clearly you are treating NULL value as an invalid argument here.
Ok. Will fix to ERR_PTR(-EINVAL).
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH v3 1/3] drivers: bus: ocp2scp: add pdata support
From: Felipe Balbi @ 2012-10-31 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351344956-22868-2-git-send-email-kishon@ti.com>
On Sat, Oct 27, 2012 at 07:05:54PM +0530, Kishon Vijay Abraham I wrote:
> ocp2scp was not having pdata support which makes *musb* fail for non-dt
> boot in OMAP platform. The pdata will have information about the devices
> that is connected to ocp2scp. ocp2scp driver will now make use of this
> information to create the devices that is attached to ocp2scp.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
just one small comment below. Other than that:
Acked-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/bus/omap-ocp2scp.c | 67 ++++++++++++++++++++++++++--
> include/linux/platform_data/omap_ocp2scp.h | 31 +++++++++++++
> 2 files changed, 95 insertions(+), 3 deletions(-)
> create mode 100644 include/linux/platform_data/omap_ocp2scp.h
>
> diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
> index ff63560..5db8297 100644
> --- a/drivers/bus/omap-ocp2scp.c
> +++ b/drivers/bus/omap-ocp2scp.c
> @@ -22,6 +22,26 @@
> #include <linux/pm_runtime.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> +#include <linux/platform_data/omap_ocp2scp.h>
> +
> +/**
> + * _count_resources - count for the number of resources
> + * @res: struct resource *
> + *
> + * Count and return the number of resources populated for the device that is
> + * connected to ocp2scp.
> + */
> +static unsigned _count_resources(struct resource *res)
> +{
> + int cnt = 0;
> +
> + while (res->start != res->end) {
> + cnt++;
> + res++;
> + }
> +
> + return cnt;
> +}
>
> static int ocp2scp_remove_devices(struct device *dev, void *c)
> {
> @@ -34,20 +54,61 @@ static int ocp2scp_remove_devices(struct device *dev, void *c)
>
> static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
> {
> - int ret;
> - struct device_node *np = pdev->dev.of_node;
> + int ret;
> + unsigned res_cnt, i;
> + struct device_node *np = pdev->dev.of_node;
> + struct platform_device *pdev_child;
> + struct omap_ocp2scp_platform_data *pdata = pdev->dev.platform_data;
> + struct omap_ocp2scp_dev *dev;
>
> if (np) {
> ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
> if (ret) {
> - dev_err(&pdev->dev, "failed to add resources for ocp2scp child\n");
> + dev_err(&pdev->dev,
> + "failed to add resources for ocp2scp child\n");
> goto err0;
> }
> + } else if (pdata) {
> + for (i = 0, dev = *pdata->devices; i < pdata->dev_cnt; i++,
> + dev++) {
> + res_cnt = _count_resources(dev->res);
> +
> + pdev_child = platform_device_alloc(dev->drv_name, -1);
please use PLATFORM_DEVID_AUTO instead.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/31a46a7e/attachment-0001.sig>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Mark Jackson @ 2012-10-31 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508FE8BA.1080404@ti.com>
On 30/10/12 14:48, Vaibhav Hiremath wrote:
>
>
> On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote:
>>
>> Mark,
>>
>> MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
>> already submitted to the list recently. So MMC support will come along with
>> EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
>>
>>
>> If you refer to the Matt's repo, you should get all the patches required to
>> boot MMC support -
>>
>> https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3
>>
>>
>
> I just tested this branch (+ one fix which Matt provided [1]) on
> BeagleBone, and MMC is working without any issues. I have tested with
> rootFS on MMC card.
>
>
> [1] - http://www.spinics.net/lists/linux-omap/msg79911.html
Okay, so I'm now coming up against a brick wall regarding U-Boot.
The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the
v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git
If I try the latest mainline U-Boot (or the TI branch), I just get to "Starting kernel ..." and then
hangs.
I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're
using ?
Cheers
Mark J.
^ permalink raw reply
* [PATCH 2/2] clk: ux500: Register nomadik keypad clock lookups for u8500
From: Ulf Hansson @ 2012-10-31 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351690853-13021-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/clk/ux500/u8500_clk.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index 6390486..8575096 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -343,6 +343,8 @@ void u8500_clk_init(void)
clk = clk_reg_prcc_pclk("p3_pclk5", "per3clk", U8500_CLKRST3_BASE,
BIT(5), 0);
+ clk_register_clkdev(clk, "apb_pclk", "ske");
+ clk_register_clkdev(clk, "apb_pclk", "nmk-ske-keypad");
clk = clk_reg_prcc_pclk("p3_pclk6", "per3clk", U8500_CLKRST3_BASE,
BIT(6), 0);
@@ -503,6 +505,8 @@ void u8500_clk_init(void)
clk = clk_reg_prcc_kclk("p3_ske_kclk", "rtc32k",
U8500_CLKRST3_BASE, BIT(5), CLK_SET_RATE_GATE);
+ clk_register_clkdev(clk, NULL, "ske");
+ clk_register_clkdev(clk, NULL, "nmk-ske-keypad");
clk = clk_reg_prcc_kclk("p3_uart2_kclk", "uartclk",
U8500_CLKRST3_BASE, BIT(6), CLK_SET_RATE_GATE);
--
1.7.10
^ permalink raw reply related
* [PATCH 1/2] clk: ux500: Register rng clock lookups for u8500
From: Ulf Hansson @ 2012-10-31 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351690853-13021-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/clk/ux500/u8500_clk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index afdf738..6390486 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -371,6 +371,7 @@ void u8500_clk_init(void)
clk = clk_reg_prcc_pclk("p6_pclk0", "per6clk", U8500_CLKRST6_BASE,
BIT(0), 0);
+ clk_register_clkdev(clk, "apb_pclk", "rng");
clk = clk_reg_prcc_pclk("p6_pclk1", "per6clk", U8500_CLKRST6_BASE,
BIT(1), 0);
@@ -514,5 +515,5 @@ void u8500_clk_init(void)
/* Periph6 */
clk = clk_reg_prcc_kclk("p3_rng_kclk", "rngclk",
U8500_CLKRST6_BASE, BIT(0), CLK_SET_RATE_GATE);
-
+ clk_register_clkdev(clk, NULL, "rng");
}
--
1.7.10
^ permalink raw reply related
* [PATCH 0/2] clk: ux500: Add some more clk lookups for u8500
From: Ulf Hansson @ 2012-10-31 13:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
Some more clock lookups added for rng clocks and for the nomadik ske
keypad clocks.
Ulf Hansson (2):
clk: ux500: Register rng clock lookups for u8500
clk: ux500: Register nomadik keypad clock lookups for u8500
drivers/clk/ux500/u8500_clk.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--
1.7.10
^ permalink raw reply
* [PATCH v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
From: Fabio Estevam @ 2012-10-31 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121031131652.GM1641@pengutronix.de>
Hi Sascha,
On Wed, Oct 31, 2012 at 11:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Quoting yourself:
>
>> Forgot to comment: as patch 2 relies on this change, the better, IMHO, is
>> to send both via the same tree. If you decide to do so, please get arm
>> maintainer's ack, instead, and we can merge both via my tree.
>
> That's why Fabio resent these patches with my Ack. You are free to take
> these.
I have just realized that this patch (1/2) will not apply against
media tree because it does not have commit 27b76486a3 (media:
mx2_camera: remove cpu_is_xxx by using platform_device_id), which
changes from mx2_camera.0 to imx27-camera.0.
So it seems to be better to merge this via arm tree to avoid such conflict.
Regards,
Fabio Estevam
^ permalink raw reply
* [PULL REQ] IXP4xx changes for Linux 3.7
From: Jason Cooper @ 2012-10-31 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210302227.55857.arnd@arndb.de>
On Tue, Oct 30, 2012 at 10:27:55PM +0000, Arnd Bergmann wrote:
> On Monday 29 October 2012, Richard Cochran wrote:
> > On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote:
> > >
> > > Don't get me wrong. If I had time for this it could be different.
> > > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at
> > > this point. Given the raised barriers to participate, probably aimed at
> > > paid maintainers, I have to quit doing this.
> > >
> > > BTW since Imre has probably even much less time, it would be a good time
> > > to find someone to maintain IXP4xx code. I will be publishing (from time
> > > to time) my tree (I'm using the hw myself), so even simple
> > > cherry-picking would probably make some sense.
> >
> > So if no one else wants to do this, then I am willing to look after
> > the IXP code. I think that I do have the time for it.
>
> Thanks for the offer!
Yes, thank you!
> Jason Cooper was also volunteering to help out with this, and even we can't
> convince Krzysztof to continue doing it, there is also Imre who is officially
> listed as maintainer for IXP4xx and who has not commented on this. As Krzysztof
> mentions, he probably doesn't have much time for it, but I'd like to give
> him the chance to comment as well.
Agreed.
> I'm sure we can find some solution between the four of you. Right now, I think
> we should focus on getting the bug fixes from Krzysztof's tree into mainline
> and the stable kernels where applicable, and then establish a better working
> mode for the future kernels.
We also need to keep an eye on the big picture. If we are going to
keep/maintain ixp4xx in the kernel, there are some things which need to
be done. The drivers need moved to drivers/, platform headers need
moved to platform_data/, and we may as well add devicetree bindings
while we're moving things around.
Making ixp4xx compatible with multiplatform zImage would probably help
out the embedded distros as well.
thx,
Jason.
^ permalink raw reply
* [PATCH v3 01/11] clk: davinci - add main PLL clock driver
From: Murali Karicheri @ 2012-10-31 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaa8f7N90hknaqZmNeYD1SjQx6Fm35nS34CxwnH+fwEfg@mail.gmail.com>
On 10/28/2012 03:18 PM, Linus Walleij wrote:
> On Thu, Oct 25, 2012 at 6:11 PM, Murali Karicheri <m-karicheri2@ti.com> wrote:
>
>> This is the driver for the main PLL clock hardware found on DM SoCs.
>> This driver borrowed code from arch/arm/mach-davinci/clock.c and
>> implemented the driver as per common clock provider API. The main PLL
>> hardware typically has a multiplier, a pre-divider and a post-divider.
>> Some of the SoCs has the divider fixed meaning they can not be
>> configured through a register. HAS_PREDIV and HAS_POSTDIV flags are used
>> to tell the driver if a hardware has these dividers present or not.
>> Driver is configured through the struct clk_pll_data that has the
>> SoC specific clock data.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> This looks good to me.
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
>
>
Linus,
Thanks. I will add your Acked-by in the next revision of the patch.
Murali
^ permalink raw reply
* [PATCH v3 02/11] clk: davinci - add PSC clock driver
From: Murali Karicheri @ 2012-10-31 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaNfv13xxHyA0p9M7oqRqb7j0J9gvyYvYhgCs7-z4ifhQ@mail.gmail.com>
On 10/28/2012 03:24 PM, Linus Walleij wrote:
> On Thu, Oct 25, 2012 at 6:11 PM, Murali Karicheri <m-karicheri2@ti.com> wrote:
>
>> This is the driver for the Power Sleep Controller (PSC) hardware
>> found on DM SoCs as well Keystone SoCs (c6x). This driver borrowed
>> code from arch/arm/mach-davinci/psc.c and implemented the driver
>> as per common clock provider API. The PSC module is responsible for
>> enabling/disabling the Power Domain and Clock domain for different IPs
>> present in the SoC. The driver is configured through the clock data
>> passed to the driver through struct clk_psc_data.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Here is some pedantic stuff if you're really bored:
>
>> diff --git a/drivers/clk/davinci/clk-psc.c b/drivers/clk/davinci/clk-psc.c
> (...)
>> + ptcmd = 1 << domain;
> ptcmd = BIT(domain);
>
>> + pdctl = readl(psc_base + PDCTL + 4 * domain);
>> + pdctl |= 0x100;
> pdctl |= BIT(8); /* and here a comment explaing what on earth that means */
>
>> + } else {
>> + ptcmd = 1 << domain;
> ptcmd = BIT(domain);
>
> Yours,
> Linus Walleij
>
>
Linus,
Thanks. I will fix the above and add your Acked-by in the next revision
of the patch.
Murali
^ permalink raw reply
* [PATCH v3 03/11] clk: davinci - common clk utilities to init clk driver
From: Murali Karicheri @ 2012-10-31 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZeor=V624OvBek1FccWFvYr2=mPBXZat8ELTtNTTL_rw@mail.gmail.com>
On 10/28/2012 03:25 PM, Linus Walleij wrote:
> On Thu, Oct 25, 2012 at 6:11 PM, Murali Karicheri <m-karicheri2@ti.com> wrote:
>
>> This is the common clk driver initialization functions for DaVinci
>> SoCs and other SoCs that uses similar hardware architecture.
>> clock.h also defines struct types for clock definitions in a SoC
>> and clock data type for configuring clk-mux. The initialization
>> functions are used by clock initialization code in a specific
>> platform/SoC.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> This is looking good.
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
>
Linus,
Thanks. I will add your Acked-by in the next revision of the patch.
Murali
^ permalink raw reply
* [PATCH v3 04/11] clk: davinci - add pll divider clock driver
From: Murali Karicheri @ 2012-10-31 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY3ji_twCqej6Yf8grR7oovf3jeGrbQMzybk5CK5f2Y9A@mail.gmail.com>
On 10/28/2012 03:26 PM, Linus Walleij wrote:
> On Thu, Oct 25, 2012 at 6:11 PM, Murali Karicheri <m-karicheri2@ti.com> wrote:
>
>> pll dividers are present in the pll controller of DaVinci and Other
>> SoCs that re-uses the same hardware IP. This has a enable bit for
>> bypass the divider or enable the driver. This is a sub class of the
>> clk-divider clock checks the enable bit to calculare the rate and
>> invoke the recalculate() function of the clk-divider if enabled.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> Looking good,
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
>
Linus,
Thanks. I will add your Acked-by in the next version.
Murali
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-31 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaiLXVeUg1quuw3XPTenbKOjn+aWbGQezpcyvzQCtCWow@mail.gmail.com>
On 21:12 Sun 28 Oct , Linus Walleij wrote:
> On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>
> >> drivers/spi/spi-pl022.c
> >
> > Default/sleep transitions could be moved into bus code.
>
> No that's not a good idea as long as we have both the platform bus
> and the AMBA bus doing essentially the same thing. We will then be
> having two copies of the same code in two different busses running
> out of sync. There may be other busses too.
>
> But I could prepare static helpers in <linux/pinctrl/consumer.h>
> that any bus could use. Or any driver. Probably any driver,
> because of this:
>
> As noted the bus cannot really execute the pinctrl calls to
> e.g. put a drivers pins into "sleep". Since if e.g. the bus is walking
> the suspend() ladder, shall it put the pins into sleep *before*
> or *after* calling the suspend() hook in the driver?
>
> The answer is that it does not know. Because drivers have
> different needs. Depending on how the hardware and
> system is done.
>
> I already tried to make this point:
>
> pinctrl_set_state(state_sleep);
> clk_disable();
> power_off_voltage_domain();
>
> May for some drivers have to be:
>
> clk_disable();
> power_off_voltage_domain();
> pinctrl_set_state(state_sleep);
>
> (etc)
>
> I'm not making this up, it is a very real phenomenon on the
> Ux500 and I don't think we are unique.
I agree with Linus
you can not handle pinctrl as bus levell
as each driver need different requirement before enabling the pin
as example you may need to clock the ip before muxing the pin and invertly
on some IP the pinctrl is optionnal, on other mandatory
you can not expect every driver to have the same need and requirement
yes we will have a few code duplication
but today it's few lines and those few lines will be place at different init
stage on the drivers ditto for remove or sleep/idle
>
> Moving this handling to bus code or anywhere else
> invariably implies that resource acquisition/release order
> does not matter, and my point is that it does.
100% agreed
Best Regards,
J.
>
> >> drivers/i2c/busses/i2c-nomadik.c
> >
> > Don't see pinctrl in linux-next.
>
> This code is here:
> http://marc.info/?l=linux-i2c&m=134986995731695&w=2
>
> Yours,
> Linus Walleij
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* [PATCH v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
From: Sascha Hauer @ 2012-10-31 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121031095632.536d9362@infradead.org>
Hi Mauro,
On Wed, Oct 31, 2012 at 09:56:32AM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 30 Oct 2012 10:03:25 -0200
> Fabio Estevam <fabio.estevam@freescale.com> escreveu:
>
> > During the clock conversion for mx27 the "per4_gate" clock was missed to get
> > registered as a dependency of mx2-camera driver.
> >
> > In the old mx27 clock driver we used to have:
> >
> > DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, &csi_clk1, &per4_clk);
> >
> > ,so does the same in the new clock driver
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> As it seems that those patches depend on some patches at the arm tree,
> the better is to merge them via -arm tree.
Quoting yourself:
> Forgot to comment: as patch 2 relies on this change, the better, IMHO, is
> to send both via the same tree. If you decide to do so, please get arm
> maintainer's ack, instead, and we can merge both via my tree.
That's why Fabio resent these patches with my Ack. You are free to take
these.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 1/2] input: qt1070: add pinctrl consumer
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-31 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaTciRNsG8viz19FQajFExX+ApPNcnnVBneecSe_w-EsA@mail.gmail.com>
On 22:37 Tue 30 Oct , Linus Walleij wrote:
>
> On Tue, Oct 23, 2012 at 3:29 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
>
> > If no pinctrl available just report a warning as some architecture may not
> > need to do anything.
> >
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: linux-input at vger.kernel.org
>
> We're having a discussion on the level of where to impose pinctrl.
>
> Jean-Christophe, could you please check the thread
> "Input: omap4-keypad: Add pinctrl support"
> and tell us what you think is the best approach?
ok I check it
Best Regards,
J.
^ permalink raw reply
* [PATCH] ARM: zynq: move ttc timer code to drivers/clocksource
From: Josh Cartwright @ 2012-10-31 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b8e9679-dade-4448-8c16-362de455ead0@AM1EHSMHS002.ehs.local>
On Wed, Oct 31, 2012 at 08:48:38AM +0000, Michal Simek wrote:
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> > On Tuesday 30 October 2012, Michal Simek wrote:
> > > On 10/29/2012 07:56 PM, Josh Cartwright wrote:
[..]
> >
> > > > delete mode 100644 arch/arm/mach-zynq/common.h
> > > > delete mode 100644 arch/arm/mach-zynq/timer.c
> > > > create mode 100644 drivers/clocksource/xilinx_ttc.c
> > > > create mode 100644 include/linux/xilinx_ttc.h
> > >
> > > Really?
> > > If yes. shouldn't be there any better naming convention especially
> > > for headers. linux/clocksource/xilinx_ttc.h.
> >
> > Moving it is certainly the right direction, but I think we need a
> > better way to handle those forward declarations. "struct sys_timer"
> > is actually an ARM specific structure, so we might just want to add
> > all the forward declarations for the timers into
> > arch/arm/include/asm/mach/time.h. It's not ideal to do it like that,
> > but I think it's much better than having a new globally visible
> > header for each timer that is used on ARM.
> >
> > Eventually, we might want to do something similar to what we are
> > discussing for the top-level IRQ controllers at the moment, where we
> > just autodetect them from DT if possible, so we don't need to have
> > any pointer to the timer from arch code at all.
>
> Ok. It means that it is not big deal to keep timer as is in mach and
> when we have any generic solution we can follow it. This patch just
> move the code out of mach-zynq. It should be done across architecture
> because for example timer I use for microblaze can be used by zynq
> too, also by Xilinx ppc.
That all makes sense. Since posting, I've had to rework this a bit for
getting COMMON_CLK support working with the TTC. I'll pull this patch
(in proper form, and with some slight modifications) into my pending
COMMON_CLK support patchset.
Thanks,
Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/50460231/attachment.sig>
^ permalink raw reply
* [PATCH v3 01/11] clk: davinci - add main PLL clock driver
From: Sekhar Nori @ 2012-10-31 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351181518-11882-2-git-send-email-m-karicheri2@ti.com>
Hi Murali,
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
> This is the driver for the main PLL clock hardware found on DM SoCs.
> This driver borrowed code from arch/arm/mach-davinci/clock.c and
> implemented the driver as per common clock provider API. The main PLL
> hardware typically has a multiplier, a pre-divider and a post-divider.
> Some of the SoCs has the divider fixed meaning they can not be
> configured through a register. HAS_PREDIV and HAS_POSTDIV flags are used
> to tell the driver if a hardware has these dividers present or not.
> Driver is configured through the struct clk_pll_data that has the
> SoC specific clock data.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
> diff --git a/drivers/clk/davinci/clk-pll.c b/drivers/clk/davinci/clk-pll.c
> +static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct clk_pll *pll = to_clk_pll(hw);
> + struct clk_pll_data *pll_data = pll->pll_data;
> + u32 mult = 1, prediv = 1, postdiv = 1;
No need to initialize mult here. I gave this comment last time around as
well.
> + unsigned long rate = parent_rate;
> +
> + mult = readl(pll_data->reg_pllm);
> +
> + /*
> + * if fixed_multiplier is non zero, multiply pllm value by this
> + * value.
> + */
> + if (pll_data->fixed_multiplier)
> + mult = pll_data->fixed_multiplier *
> + (mult & pll_data->pllm_mask);
> + else
> + mult = (mult & pll_data->pllm_mask) + 1;
Hmm, this is interpreting the 'mult' register field differently in both
cases. In one case it is 'actual multiplier - 1' and in other case it is
the 'actual multiplier' itself. Can we be sure that the mult register
definition will change whenever there is a fixed multiplier in the PLL
block? I don't think any of the existing DaVinci devices have a fixed
multiplier. Is this on keystone?
> +struct clk *clk_register_davinci_pll(struct device *dev, const char *name,
> + const char *parent_name,
> + struct clk_pll_data *pll_data)
> +{
> + struct clk_init_data init;
> + struct clk_pll *pll;
> + struct clk *clk;
> +
> + if (!pll_data)
> + return ERR_PTR(-ENODEV);
-EINVAL? Clearly you are treating NULL value as an invalid argument here.
Thanks,
Sekhar
^ 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