* Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Laurent Pinchart @ 2014-02-11 17:24 UTC (permalink / raw)
To: Philipp Zabel
Cc: Russell King - ARM Linux, Rob Herring, Mauro Carvalho Chehab,
Grant Likely, Rob Herring, Sylwester Nawrocki, Tomi Valkeinen,
Kyungmin Park,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Philipp Zabel
In-Reply-To: <1392136617.6943.33.camel-/rZezPiN1rtR6QfukMTsflXZhhPuCNm+@public.gmane.org>
Hi Philipp,
On Tuesday 11 February 2014 17:36:57 Philipp Zabel wrote:
> Am Dienstag, den 11.02.2014, 16:23 +0100 schrieb Laurent Pinchart:
> > On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote:
> > > On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote:
> > > > On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote:
> > > > > This allows to reuse the same parser code from outside the V4L2
> > > > > framework, most importantly from display drivers. There have been
> > > > > patches that duplicate the code (and I am going to send one of my
> > > > > own),
> > > > > such as
> > > > > http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.h
> > > > > tml
> > > > > and others that parse the same binding in a different way:
> > > > > https://www.mail-archive.com/linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg100761.ht
> > > > > ml
> > > > >
> > > > > I think that all common video interface parsing helpers should be
> > > > > moved to a single place, outside of the specific subsystems, so that
> > > > > it can be reused by all drivers.
> > > >
> > > > Perhaps that should be done rather than moving to drivers/of now and
> > > > then again to somewhere else.
> > >
> > > Do you have a better suggestion where it should move to?
> > >
> > > drivers/gpu/drm - no, because v4l2 wants to use it
> > > drivers/media/video - no, because DRM drivers want to use it
> > > drivers/video - no, because v4l2 and drm drivers want to use it
> >
> > Just pointing out a missing location (which might be rejected due to
> > similar concerns), there's also drivers/media, which isn't V4L-specific.
>
> Since drivers/Makefile has media/ in obj-y, moving the graph helpers to
> drivers/media should technically work.
>
> > > Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it
> > > into drivers/of ?
>
> include/media/of_graph.h,
> drivers/media/of_graph.c?
I'm personally fine with that.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch v5 1/2] dmaengine: add Qualcomm BAM dma driver
From: Vinod Koul @ 2014-02-11 17:30 UTC (permalink / raw)
To: Andy Gross
Cc: Dan Williams, dmaengine, devicetree, linux-kernel,
linux-arm-kernel, linux-arm-msm
In-Reply-To: <1391546556-27702-2-git-send-email-agross@codeaurora.org>
On Tue, Feb 04, 2014 at 02:42:35PM -0600, Andy Gross wrote:
> Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
> found in the MSM 8x74 platforms.
>
> Each BAM DMA device is associated with a specific on-chip peripheral. Each
> channel provides a uni-directional data transfer engine that is capable of
> transferring data between the peripheral and system memory (System mode), or
> between two peripherals (BAM2BAM).
>
> The initial release of this driver only supports slave transfers between
> peripherals and system memory.
>
> Signed-off-by: Andy Gross <agross@codeaurora.org>
> +++ b/drivers/dma/qcom_bam_dma.c
> @@ -0,0 +1,1066 @@
> +/*
> + * QCOM BAM DMA engine driver
> + *
> + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
This is bit strange, usually copyright is retained by your employer, but I am
fine with it :)
> +struct bam_desc_hw {
> + u32 addr; /* Buffer physical address */
this is where we might have an issue. Is this the DMA register which is 32bit
wide or you are descibing it so.
Will this work if you are in 64 bit?
> + u16 size; /* Buffer size in bytes */
> + u16 flags;
> +};
> +
> +/**
> + * bam_reset_channel - Reset individual BAM DMA channel
> + * @bchan: bam channel
> + *
> + * This function resets a specific BAM channel
> + */
> +static void bam_reset_channel(struct bam_chan *bchan)
> +{
> + struct bam_device *bdev = bchan->bdev;
> +
> + /* reset channel */
> + writel_relaxed(1, bdev->regs + BAM_P_RST(bchan->id));
> + writel_relaxed(0, bdev->regs + BAM_P_RST(bchan->id));
> +
> + /* don't allow reorder of the channel reset */
> + wmb();
Documentation/memory-barriers.txt describes wmb() as a CPU barier but based on
above you want it to be a compiler barrier then you should do 1st write,
barrier(), second write.
> +
> + /* make sure hw is initialized when channel is used the first time */
> + bchan->initialized = 0;
> +}
okay why no locks held while reset?
> +
> +/**
> + * bam_chan_init_hw - Initialize channel hardware
> + * @bchan: bam channel
> + *
> + * This function resets and initializes the BAM channel
> + */
> +static void bam_chan_init_hw(struct bam_chan *bchan,
> + enum dma_transfer_direction dir)
> +{
> + struct bam_device *bdev = bchan->bdev;
> + u32 val;
> +
> + /* Reset the channel to clear internal state of the FIFO */
> + bam_reset_channel(bchan);
> +
> + /*
> + * write out 8 byte aligned address. We have enough space for this
> + * because we allocated 1 more descriptor (8 bytes) than we can use
> + */
> + writel_relaxed(ALIGN(bchan->fifo_phys, sizeof(struct bam_desc_hw)),
> + bdev->regs + BAM_P_DESC_FIFO_ADDR(bchan->id));
> + writel_relaxed(BAM_DESC_FIFO_SIZE, bdev->regs +
> + BAM_P_FIFO_SIZES(bchan->id));
> +
> + /* enable the per pipe interrupts, enable EOT, ERR, and INT irqs */
> + writel_relaxed(P_DEFAULT_IRQS_EN, bdev->regs + BAM_P_IRQ_EN(bchan->id));
> +
> + /* unmask the specific pipe and EE combo */
> + val = readl_relaxed(bdev->regs + BAM_IRQ_SRCS_MSK_EE(bdev->ee));
> + val |= BIT(bchan->id);
> + writel_relaxed(val, bdev->regs + BAM_IRQ_SRCS_MSK_EE(bdev->ee));
> +
> + /* set fixed direction and mode, then enable channel */
> + val = P_EN | P_SYS_MODE;
> + if (dir == DMA_DEV_TO_MEM)
> + val |= P_DIRECTION;
> +
> + /* make sure the other stores occur before enabling channel */
> + wmb();
here again!
> + writel_relaxed(val, bdev->regs + BAM_P_CTRL(bchan->id));
> +
> + bchan->initialized = 1;
> +
> + /* init FIFO pointers */
> + bchan->head = 0;
> + bchan->tail = 0;
> +}
> +
> +/**
> + * bam_alloc_chan - Allocate channel resources for DMA channel.
> + * @chan: specified channel
> + *
> + * This function allocates the FIFO descriptor memory
> + */
> +static int bam_alloc_chan(struct dma_chan *chan)
> +{
> + struct bam_chan *bchan = to_bam_chan(chan);
> + struct bam_device *bdev = bchan->bdev;
> +
> + /* allocate FIFO descriptor space, but only if necessary */
> + if (!bchan->fifo_virt) {
> + bchan->fifo_virt = dma_alloc_writecombine(bdev->dev,
> + BAM_DESC_FIFO_SIZE, &bchan->fifo_phys,
> + GFP_KERNEL);
> +
> + if (!bchan->fifo_virt) {
> + dev_err(bdev->dev, "Failed to allocate desc fifo\n");
> + return -ENOMEM;
> + }
> + }
> +
> + return BAM_DESC_FIFO_SIZE;
But you cna have SW descriptors more than HW ones and issue new ones once HW is
done with them. Why tie the limit to what HW supports and not create a better
driver?
> +
> +/**
> + * bam_slave_config - set slave configuration for channel
> + * @chan: dma channel
> + * @cfg: slave configuration
> + *
> + * Sets slave configuration for channel
> + *
> + */
> +static void bam_slave_config(struct bam_chan *bchan,
> + struct dma_slave_config *cfg)
> +{
> + struct bam_device *bdev = bchan->bdev;
> + u32 maxburst;
> +
> + if (bchan->slave.direction == DMA_DEV_TO_MEM)
> + maxburst = bchan->slave.src_maxburst = cfg->src_maxburst;
> + else
> + maxburst = bchan->slave.dst_maxburst = cfg->dst_maxburst;
can you remove usage of slave.direction have save both. I am going to remove
this member...
> +
> + /* set desc threshold */
> + writel_relaxed(maxburst, bdev->regs + BAM_DESC_CNT_TRSHLD);
> +}
> +
> +/**
> + * bam_prep_slave_sg - Prep slave sg transaction
> + *
> + * @chan: dma channel
> + * @sgl: scatter gather list
> + * @sg_len: length of sg
> + * @direction: DMA transfer direction
> + * @flags: DMA flags
> + * @context: transfer context (unused)
> + */
> +static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
> + struct scatterlist *sgl, unsigned int sg_len,
> + enum dma_transfer_direction direction, unsigned long flags,
> + void *context)
> +{
> + struct bam_chan *bchan = to_bam_chan(chan);
> + struct bam_device *bdev = bchan->bdev;
> + struct bam_async_desc *async_desc;
> + struct scatterlist *sg;
> + u32 i;
> + struct bam_desc_hw *desc;
> +
> +
> + if (!is_slave_direction(direction)) {
> + dev_err(bdev->dev, "invalid dma direction\n");
> + return NULL;
> + }
> +
> +
> + /* allocate enough room to accomodate the number of entries */
> + async_desc = kzalloc(sizeof(*async_desc) +
> + (sg_len * sizeof(struct bam_desc_hw)), GFP_NOWAIT);
this seems to assume that each sg entry length will not exceed the HW capablity.
Does engine support any length descriptor, if not you may want to split to
multiple.
> +
> + if (!async_desc) {
> + dev_err(bdev->dev, "failed to allocate async descriptor\n");
> + goto err_out;
> + }
> +
> + async_desc->num_desc = sg_len;
> + async_desc->curr_desc = async_desc->desc;
> + async_desc->dir = direction;
> +
> + /* fill in descriptors, align hw descriptor to 8 bytes */
> + desc = async_desc->desc;
> + for_each_sg(sgl, sg, sg_len, i) {
> + if (sg_dma_len(sg) > BAM_MAX_DATA_SIZE) {
> + dev_err(bdev->dev, "segment exceeds max size\n");
> + goto err_out;
gottcha, okay why not split here to multiple descriptors with max size all but
last?
> + }
> +
> + desc->addr = sg_dma_address(sg);
> + desc->size = sg_dma_len(sg);
> + async_desc->length += sg_dma_len(sg);
> + desc++;
> + }
> +
> + return vchan_tx_prep(&bchan->vc, &async_desc->vd, flags);
> +
> +err_out:
> + kfree(async_desc);
> + return NULL;
> +}
> +
> +/**
> + * bam_dma_terminate_all - terminate all transactions on a channel
> + * @bchan: bam dma channel
> + *
> + * Dequeues and frees all transactions
> + * No callbacks are done
> + *
> + */
> +static void bam_dma_terminate_all(struct bam_chan *bchan)
> +{
> + unsigned long flag;
> + LIST_HEAD(head);
> +
> + /* remove all transactions, including active transaction */
> + spin_lock_irqsave(&bchan->vc.lock, flag);
> + if (bchan->curr_txd) {
> + list_add(&bchan->curr_txd->vd.node, &bchan->vc.desc_issued);
> + bchan->curr_txd = NULL;
> + }
> +
> + vchan_get_all_descriptors(&bchan->vc, &head);
> + spin_unlock_irqrestore(&bchan->vc.lock, flag);
> +
> + vchan_dma_desc_free_list(&bchan->vc, &head);
why drop the lock here, i dont think this one needs to be called with lock
dropped, didnt see it garbbing.
> +}
> +
> +/**
> + * bam_control - DMA device control
> + * @chan: dma channel
> + * @cmd: control cmd
> + * @arg: cmd argument
> + *
> + * Perform DMA control command
> + *
> + */
> +static int bam_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> + unsigned long arg)
> +{
> + struct bam_chan *bchan = to_bam_chan(chan);
> + struct bam_device *bdev = bchan->bdev;
> + int ret = 0;
> + unsigned long flag;
> +
> + switch (cmd) {
> + case DMA_PAUSE:
> + spin_lock_irqsave(&bchan->vc.lock, flag);
> + writel_relaxed(1, bdev->regs + BAM_P_HALT(bchan->id));
> + bchan->paused = 1;
> + spin_unlock_irqrestore(&bchan->vc.lock, flag);
> + break;
> + case DMA_RESUME:
> + spin_lock_irqsave(&bchan->vc.lock, flag);
> + writel_relaxed(0, bdev->regs + BAM_P_HALT(bchan->id));
> + bchan->paused = 0;
> + spin_unlock_irqrestore(&bchan->vc.lock, flag);
> + break;
> + case DMA_TERMINATE_ALL:
> + bam_dma_terminate_all(bchan);
> + break;
> + case DMA_SLAVE_CONFIG:
> + bam_slave_config(bchan, (struct dma_slave_config *)arg);
> + break;
> + default:
> + ret = -ENXIO;
> + break;
> + }
empty line after each break would be appreciated.
> +
> + return ret;
> +}
> +
> +/**
> + * bam_start_dma - start next transaction
> + * @bchan - bam dma channel
> + *
> + * Note: must hold bam dma channel vc.lock
> + */
> +static void bam_start_dma(struct bam_chan *bchan)
> +{
> + struct virt_dma_desc *vd = vchan_next_desc(&bchan->vc);
> + struct bam_device *bdev = bchan->bdev;
> + struct bam_async_desc *async_desc;
> + struct bam_desc_hw *desc;
> + struct bam_desc_hw *fifo = PTR_ALIGN(bchan->fifo_virt,
> + sizeof(struct bam_desc_hw));
> +
> + if (!vd)
> + return;
> +
> + list_del(&vd->node);
> +
> + async_desc = container_of(vd, struct bam_async_desc, vd);
> + bchan->curr_txd = async_desc;
> +
> + /* on first use, initialize the channel hardware */
> + if (!bchan->initialized)
> + bam_chan_init_hw(bchan, async_desc->dir);
> +
> +
> + desc = bchan->curr_txd->curr_desc;
> +
> + if (async_desc->num_desc > MAX_DESCRIPTORS)
> + async_desc->xfer_len = MAX_DESCRIPTORS;
> + else
> + async_desc->xfer_len = async_desc->num_desc;
> +
> + /* set INT on last descriptor */
> + desc[async_desc->xfer_len - 1].flags |= DESC_FLAG_INT;
> +
> + if (bchan->tail + async_desc->xfer_len > MAX_DESCRIPTORS) {
> + u32 partial = MAX_DESCRIPTORS - bchan->tail;
> +
> + memcpy(&fifo[bchan->tail], desc,
> + partial * sizeof(struct bam_desc_hw));
> + memcpy(fifo, &desc[partial], (async_desc->xfer_len - partial) *
> + sizeof(struct bam_desc_hw));
> + } else {
> + memcpy(&fifo[bchan->tail], desc,
> + async_desc->xfer_len * sizeof(struct bam_desc_hw));
where is the destination memeory located, device or system memory. I think
later, right?
> + }
> +
> + bchan->tail += async_desc->xfer_len;
> + bchan->tail %= MAX_DESCRIPTORS;
> +
> + /* ensure descriptor writes and dma start not reordered */
> + wmb();
> + writel_relaxed(bchan->tail * sizeof(struct bam_desc_hw),
> + bdev->regs + BAM_P_EVNT_REG(bchan->id));
> +}
> +
Overall driver loooks fine mostly with few comments as above.
And yes for 2nd patch, would need someone to ACK it before we can appply this
--
~Vinod
^ permalink raw reply
* Re: [PATCH 4/8] ARM: mvebu: make use of of_find_matching_node_and_match
From: Gregory CLEMENT @ 2014-02-11 17:31 UTC (permalink / raw)
To: Thomas Petazzoni, Jason Cooper
Cc: Josh Cartwright, Andrew Lunn, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <20140211181048.6934bdd3@skate>
On 11/02/2014 18:10, Thomas Petazzoni wrote:
> Dear Jason Cooper,
>
> On Tue, 11 Feb 2014 11:53:14 -0500, Jason Cooper wrote:
>
>>> - np = of_find_matching_node(NULL, of_system_controller_table);
>>> + np = of_find_matching_node_and_match(NULL, of_system_controller_table,
>>> + &match);
>>> if (np) {
>>> - const struct of_device_id *match =
>>> - of_match_node(of_system_controller_table, np);
>>
>>
>>> - BUG_ON(!match);
>>
>> Gregory, is it ok to remove this? It was added with the original code
>> submission for mach-mvebu. mvebu_restart() will handle this
>> gracefully...
>
> The BUG_ON here can normally never be reached. If
> of_find_matching_node() returns a non-NULL result, then of_match_node()
> should also return a non-NULL result.
>
> Or I'm missing something :)
No you're almost right!
The only case we can get it, would be if we were declaring something like:
static struct of_device_id of_system_controller_table[] = {
{
.compatible = "foo,bar-controller",
},
[...]
instead of
static struct of_device_id of_system_controller_table[] = {
{
.compatible = "foo,bar",
.data = (void *) &bar_controller,
},
[...]
This test is very paranoid, so I agree to remove it.
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks,
Gregory
>
> Thomas
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] driver core & of: Mark of_nodes of added device as populated
From: Christopher Covington @ 2014-02-11 17:32 UTC (permalink / raw)
To: Pawel Moll
Cc: linux-kernel, linux-arm-kernel, devicetree, lm-sensors, arm,
Mark Rutland, Mike Turquette, Samuel Ortiz, Arnd Bergmann,
Ian Campbell, Dmitry Eremin-Solenikov, Greg Kroah-Hartman,
Mark Brown, Liam Girdwood, Rob Herring, Guenter Roeck, Kumar Gala,
Grant Likely, Lee Jones, David Woodhouse, Jean Delvare
In-Reply-To: <1392137610-27842-2-git-send-email-pawel.moll@arm.com>
Hi Pawel,
On 02/11/2014 11:53 AM, Pawel Moll wrote:
> This patch tries to solve that issue in a generic way,
> adding a "populated" flag which is set in the device_node
> structure when a device is being created in the core.
> Later, of_platform_populate() skips such nodes (and
> its children) in a similar way to the non-available ones.
Will there never be a case where it is useful for a parent node to be created
early, but not necessarily the child nodes? Might only skipping nodes
explicitly marked as populated be a more universal solution?
Regards,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* Re: [PATCH 4/8] ARM: mvebu: make use of of_find_matching_node_and_match
From: Jason Cooper @ 2014-02-11 17:34 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Thomas Petazzoni, Josh Cartwright, Andrew Lunn, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <52FA5E75.7030402-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Feb 11, 2014 at 06:31:33PM +0100, Gregory CLEMENT wrote:
> On 11/02/2014 18:10, Thomas Petazzoni wrote:
> > Dear Jason Cooper,
> >
> > On Tue, 11 Feb 2014 11:53:14 -0500, Jason Cooper wrote:
> >
> >>> - np = of_find_matching_node(NULL, of_system_controller_table);
> >>> + np = of_find_matching_node_and_match(NULL, of_system_controller_table,
> >>> + &match);
> >>> if (np) {
> >>> - const struct of_device_id *match =
> >>> - of_match_node(of_system_controller_table, np);
> >>
> >>
> >>> - BUG_ON(!match);
> >>
> >> Gregory, is it ok to remove this? It was added with the original code
> >> submission for mach-mvebu. mvebu_restart() will handle this
> >> gracefully...
> >
> > The BUG_ON here can normally never be reached. If
> > of_find_matching_node() returns a non-NULL result, then of_match_node()
> > should also return a non-NULL result.
> >
> > Or I'm missing something :)
>
> No you're almost right!
>
> The only case we can get it, would be if we were declaring something like:
>
> static struct of_device_id of_system_controller_table[] = {
> {
> .compatible = "foo,bar-controller",
> },
> [...]
>
> instead of
>
> static struct of_device_id of_system_controller_table[] = {
> {
> .compatible = "foo,bar",
> .data = (void *) &bar_controller,
> },
> [...]
>
> This test is very paranoid, so I agree to remove it.
>
>
> Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Ok, great! Josh, do you want us to take the two mvebu patches through
mvebu/arm-soc? Or would you prefer to take them?
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Mauro Carvalho Chehab @ 2014-02-11 17:41 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Rob Herring, Grant Likely, Rob Herring, Tomi Valkeinen,
Kyungmin Park, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
Philipp Zabel, Guennadi Liakhovetski
In-Reply-To: <52FA5C5A.1090008@samsung.com>
Em Tue, 11 Feb 2014 18:22:34 +0100
Sylwester Nawrocki <s.nawrocki@samsung.com> escreveu:
> (adding Guennadi to Cc)
>
> On 11/02/14 17:36, Philipp Zabel wrote:
> > Am Dienstag, den 11.02.2014, 16:23 +0100 schrieb Laurent Pinchart:
> >> Hi Russell,
> >>
> >> On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote:
> >>> On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote:
> >>>> On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote:
> >>>>> This allows to reuse the same parser code from outside the V4L2
> >>>>> framework, most importantly from display drivers. There have been
> >>>>> patches that duplicate the code (and I am going to send one of my own),
> >>>>> such as
> >>>>> http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
> >>>>> and others that parse the same binding in a different way:
> >>>>> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
> >>>>>
> >>>>> I think that all common video interface parsing helpers should be moved
> >>>>> to a single place, outside of the specific subsystems, so that it can
> >>>>> be reused by all drivers.
> >>>>
> >>>> Perhaps that should be done rather than moving to drivers/of now and
> >>>> then again to somewhere else.
> >>>
> >>> Do you have a better suggestion where it should move to?
> >>>
> >>> drivers/gpu/drm - no, because v4l2 wants to use it
> >>> drivers/media/video - no, because DRM drivers want to use it
> >>> drivers/video - no, because v4l2 and drm drivers want to use it
> >>
> >> Just pointing out a missing location (which might be rejected due to similar
> >> concerns), there's also drivers/media, which isn't V4L-specific.
> >
> > Since drivers/Makefile has media/ in obj-y, moving the graph helpers to
> > drivers/media should technically work.
> >
> >>> Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it
> >>> into drivers/of ?
> >
> > include/media/of_graph.h,
> > drivers/media/of_graph.c?
>
> drivers/media sounds like a good alternative to me.
>From my side, I'm ok with putting them at drivers/media. You may add my acked-by
for such change:
Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> I would just remove also v4l2_of_{parse/get}* and update the users
> to call of_graph_* directly, there should not be many of them.
>
> --
> Thanks,
> Sylwester
>
--
Cheers,
Mauro
^ permalink raw reply
* Re: [PATCH 4/8] ARM: mvebu: make use of of_find_matching_node_and_match
From: Josh Cartwright @ 2014-02-11 17:43 UTC (permalink / raw)
To: Jason Cooper
Cc: Gregory CLEMENT, Thomas Petazzoni, Andrew Lunn, Russell King,
devicetree, linux-kernel, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20140211173446.GC27395@titan.lakedaemon.net>
On Tue, Feb 11, 2014 at 12:34:46PM -0500, Jason Cooper wrote:
>
> Ok, great! Josh, do you want us to take the two mvebu patches through
> mvebu/arm-soc? Or would you prefer to take them?
Please, take them through the mvebu tree.
Thanks,
Josh
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH V3] net/dt: Add support for overriding phy configuration from device tree
From: Florian Fainelli @ 2014-02-11 17:43 UTC (permalink / raw)
To: Gerlando Falauto
Cc: Matthew Garrett, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kishon Vijay Abraham I
In-Reply-To: <52F9E8E6.1090006-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org>
Hi Gerlando,
2014-02-11 1:09 GMT-08:00 Gerlando Falauto <gerlando.falauto-SkAbAL50j+6IwRZHo2/mJg@public.gmane.orgm>:
> Hi Florian,
>
> first of all, thank you for your answer.
>
>
> On 02/10/2014 06:09 PM, Florian Fainelli wrote:
>>
>> Hi Gerlando,
>>
>> Le lundi 10 février 2014, 17:14:59 Gerlando Falauto a écrit :
>>>
>>> Hi,
>>>
>>> I'm currently trying to fix an issue for which this patch provides a
>>> partial solution, so apologies in advance for jumping into the
>>> discussion for my own purposes...
>>>
>>> On 02/04/2014 09:39 PM, Florian Fainelli wrote:> 2014-01-17 Matthew
>>>
>>> Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>:
>>> >> Some hardware may be broken in interesting and board-specific ways,
>>> such
>>> >> that various bits of functionality don't work. This patch provides a
>>> >> mechanism for overriding mii registers during init based on the
>>>
>>> contents of
>>>
>>> >> the device tree data, allowing board-specific fixups without having
>>> to
>>> >> pollute generic code.
>>> >
>>> > It would be good to explain exactly how your hardware is broken
>>> > exactly. I really do not think that such a fine-grained setting where
>>> > you could disable, e.g: 100BaseT_Full, but allow 100BaseT_Half to
>>> > remain usable makes that much sense. In general, Gigabit might be
>>> > badly broken, but 100 and 10Mbits/sec should work fine. How about the
>>> > MASTER-SLAVE bit, is overriding it really required?
>>> >
>>> > Is not a PHY fixup registered for a specific OUI the solution you are
>>> > looking for? I am also concerned that this creates PHY
>>> troubleshooting
>>> > issues much harder to debug than before as we may have no idea about
>>> > how much information has been put in Device Tree to override that.
>>> >
>>> > Finally, how about making this more general just like the BCM87xx PHY
>>> > driver, which is supplied value/reg pairs directly? There are 16
>>> > common MII registers, and 16 others for vendor specific registers,
>>> > this is just covering for about 2% of the possible changes.
>>>
>>> Good point. That would easily help me with my current issue, which
>>> requires autoneg to be disabled to begin with (by clearing BMCR_ANENABLE
>>> from register 0).
>>
>>
>> Is there a point in time (e.g: after some specific initial configuration
>> has
>> been made) where BMCR_ANENABLE can be used?
>
>
> What do you mean? In my case, for some HW-related reason (due to the PHY
> counterpart I guess) autoneg needs to be disabled.
> This is currently done by the bootloader code (which clears the bit).
> What I'm looking for is some way for the kernel to either reinforce this
> setting, or just take that into account and skip autoneg.
> On top of that, there's a HW errata about that particular PHY, which
> requires certain operations to be performed on the PHY as a workaround *WHEN
> AUTONEG IS DISABLED*. That I'd implement on a PHY-specif driver.
Ok.
>
>
>>> This would not however fix it entirely (I tried a quick hardwired
>>> implementation), as the whole PHY machinery would not take that into
>>> account and would re-enable autoneg anyway.
>>> I also tried changing the patch so that phydev->support gets updated
>>
>>
>> There are multiple things that you could try doing here:
>>
>> - override the PHY state machine in your read_status callback to make sure
>> that you always set phydev->autoneg set to AUTONEG_ENABLE
>
>
> [you mean AUTONEG_DISABLE, right?]
Right, I fat fingered here.
> Uhm, but I don't want to implement a driver for that PHY that always
> disables autoneg. I only want to disable autoneg for that particular board.
> I figure I might register a fixup for that board, but that kindof makes
> everything more complicated and less clear. Plus, what should be the
> criterion to determine whether we're running on that particular hardware?
of_machine_is_compatible() plus reading the specific PHY OUI should
provide you with with an unique machine + PHY tuple. If your machine
name is too generic.
>
>
>> - clear the SUPPORTED_Autoneg bits from phydev->supported right after PHY
>> registration and before the call to phy_start()
>
>
> I actually tried clearing it by tweaking the patch on this thread, but the
> end result is that it does not produce any effect (see further comments
> below). Only thing that seems to play a role here is explictly setting
> phydev->autoneg = AUTONEG_DISABLE.
>
>
>> - set the PHY_HAS_MAGICANEG bit in your PHY driver flag
>
>
> Again, this seems to play no role whatsoever here:
>
> } else if (0 == phydev->link_timeout--) {
> needs_aneg = 1;
> /* If we have the magic_aneg bit,
> * we try again */
> if (phydev->drv->flags & PHY_HAS_MAGICANEG)
> break;
> }
> break;
> case PHY_NOLINK:
>
> This code might have made sense when it was written in 2006 -- back then,
> the break statement was skipping some fallback code. But now it seems to do
> nothing.
>
>
>>
>>>
>>> (instead of phydev->advertising):
>>> >> + if (!of_property_read_u32(np, override->prop, &tmp))
>>> {
>>> >> + if (tmp) {
>>> >> + *val |= override->value;
>>> >> + phydev->advertising |=
>>>
>>> override->supported;
>>>
>>> >> + } else {
>>> >> + phydev->advertising &=
>>>
>>> ~(override->supported);
>>>
>>> >> + }
>>> >> +
>>> >> + *mask |= override->value;
>>>
>>> What I find weird is that the only way phydev->autoneg could ever be set
>>> to disabled is from here (phy.c):
>>>
>>> static void phy_sanitize_settings(struct phy_device *phydev)
>>> {
>>> u32 features = phydev->supported;
>>> int idx;
>>>
>>> /* Sanitize settings based on PHY capabilities */
>>> if ((features & SUPPORTED_Autoneg) == 0)
>>> phydev->autoneg = AUTONEG_DISABLE;
>>>
>>> which is in turn only called when phydev->autoneg is set to
>>> AUTONEG_DISABLE to begin with:
>>>
>>> int phy_start_aneg(struct phy_device *phydev)
>>> {
>>> int err;
>>>
>>> mutex_lock(&phydev->lock);
>>>
>>> if (AUTONEG_DISABLE == phydev->autoneg)
>>> phy_sanitize_settings(phydev);
>>>
>>> So could someone please help me figure out what I'm missing here?
>>
>>
>> At first glance it looks like the PHY driver should be reading the phydev-
>>>
>>> autoneg value when the PHY driver config_aneg() callback is called to be
>>
>> allowed to set the forced speed and settings.
>>
>> The way phy_sanitize_settings() is coded does not make it return a mask of
>> features, but only the forced supported speed and duplex. Then when the
>> link
>> is forced but we are having some issues getting a link status, libphy
>> tries
>> lower speeds and this function is used again to provide the next
>> speed/duplex
>> pair to try.
>>
>
> What I was trying to say is that phy_sanitize_settings() is only called when
> phydev->autoneg == AUTONEG_DISABLE, and in turn it's the only generic
> function setting phydev->autoneg = AUTONEG_DISABLE.
> So perhaps the condition should read:
>
> - if (AUTONEG_DISABLE == phydev->autoneg)
> + if ((features & SUPPORTED_Autoneg) == 0)
> phy_sanitize_settings(phydev);
>
> Or else, some other parts of the generic code should take care of setting it
> to AUTONEG_DISABLE, depending on whether the feature is supported or not.
> What I found weird is explicitly setting a value (phydev->autoneg =
> AUTONEG_DISABLE), from a static function which is only called when that
> condition is already true.
I do not think that this change is correct either, let me cook a patch
for you to allow disabling autoneg from the start.
>
> BTW, I feel like disabling autoneg from the start has never been a use case
> before, am I right?
Not really no, and that is because most hardware does not need quirks
to work correctly.
>
> Thanks!
> Gerlando
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/8] ARM: at91: make use of of_find_matching_node_and_match
From: Nicolas Ferre @ 2014-02-11 17:46 UTC (permalink / raw)
To: Josh Cartwright
Cc: Andrew Victor, Jean-Christophe Plagniol-Villard, devicetree,
linux-kernel, Russell King, linux-arm-kernel
In-Reply-To: <1392135847-30791-4-git-send-email-joshc@codeaurora.org>
On 11/02/2014 17:24, Josh Cartwright :
> Instead of the of_find_matching_node()/of_match_node() pair, which requires two
> iterations through the match table, make use of of_find_matching_node_and_match(),
> which only iterates through the table once.
>
> While we're here, mark the rtsc id table const.
Well, I might remove this one, just because other id tables are not
marked as "const" in the same file... So it can be good to change all of
them in a raw.
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> ---
> arch/arm/mach-at91/setup.c | 16 ++++------------
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index f7ca97b..e884de8 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -352,7 +352,7 @@ void __init at91_ioremap_matrix(u32 base_addr)
> }
>
> #if defined(CONFIG_OF)
> -static struct of_device_id rstc_ids[] = {
> +static const struct of_device_id rstc_ids[] = {
> { .compatible = "atmel,at91sam9260-rstc", .data = at91sam9_alt_restart },
> { .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
> { /*sentinel*/ }
> @@ -363,7 +363,7 @@ static void at91_dt_rstc(void)
> struct device_node *np;
> const struct of_device_id *of_id;
>
> - np = of_find_matching_node(NULL, rstc_ids);
> + np = of_find_matching_node_and_match(NULL, rstc_ids, &of_id);
> if (!np)
> panic("unable to find compatible rstc node in dtb\n");
>
> @@ -371,10 +371,6 @@ static void at91_dt_rstc(void)
> if (!at91_rstc_base)
> panic("unable to map rstc cpu registers\n");
>
> - of_id = of_match_node(rstc_ids, np);
> - if (!of_id)
> - panic("AT91: rtsc no restart function available\n");
> -
> arm_pm_restart = of_id->data;
>
> of_node_put(np);
> @@ -392,7 +388,7 @@ static void at91_dt_ramc(void)
> struct device_node *np;
> const struct of_device_id *of_id;
>
> - np = of_find_matching_node(NULL, ramc_ids);
> + np = of_find_matching_node_and_match(NULL, ramc_ids, &of_id);
> if (!np)
> panic("unable to find compatible ram controller node in dtb\n");
>
> @@ -402,11 +398,7 @@ static void at91_dt_ramc(void)
> /* the controller may have 2 banks */
> at91_ramc_base[1] = of_iomap(np, 1);
>
> - of_id = of_match_node(ramc_ids, np);
> - if (!of_id)
> - pr_warn("AT91: ramc no standby function available\n");
> - else
> - at91_pm_set_standby(of_id->data);
> + at91_pm_set_standby(of_id->data);
Even if it changes the strict behavior of the function, I do not see any
advantage in keeping the pr_warn() path instead of a simple panic()
protecting the "find" and "match" together...
So, without the "const" modification, it ends up with a:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
=> if you want, I can take the patch with me through arm-soc with at91
material for 3.15 and complete your "const" modification. What do you
think about that?
>
> of_node_put(np);
> }
>
Thanks for having taking care of this file, bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: [Patch v5 1/2] dmaengine: add Qualcomm BAM dma driver
From: Josh Cartwright @ 2014-02-11 17:49 UTC (permalink / raw)
To: Vinod Koul
Cc: Andy Gross, Dan Williams, dmaengine, devicetree, linux-kernel,
linux-arm-kernel, linux-arm-msm
In-Reply-To: <20140211173048.GP10628@intel.com>
On Tue, Feb 11, 2014 at 11:00:48PM +0530, Vinod Koul wrote:
> On Tue, Feb 04, 2014 at 02:42:35PM -0600, Andy Gross wrote:
> > Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
> > found in the MSM 8x74 platforms.
> >
> > Each BAM DMA device is associated with a specific on-chip peripheral. Each
> > channel provides a uni-directional data transfer engine that is capable of
> > transferring data between the peripheral and system memory (System mode), or
> > between two peripherals (BAM2BAM).
> >
> > The initial release of this driver only supports slave transfers between
> > peripherals and system memory.
> >
> > Signed-off-by: Andy Gross <agross@codeaurora.org>
>
> > +++ b/drivers/dma/qcom_bam_dma.c
[..]
> > +static void bam_reset_channel(struct bam_chan *bchan)
> > +{
> > + struct bam_device *bdev = bchan->bdev;
> > +
> > + /* reset channel */
> > + writel_relaxed(1, bdev->regs + BAM_P_RST(bchan->id));
> > + writel_relaxed(0, bdev->regs + BAM_P_RST(bchan->id));
> > +
> > + /* don't allow reorder of the channel reset */
> > + wmb();
> Documentation/memory-barriers.txt describes wmb() as a CPU barier but based on
> above you want it to be a compiler barrier then you should do 1st write,
> barrier(), second write.
It could also be that the intent was to prevent these writes from being
ordered before setting the initialized flag below, either way the
comment could be made clearer.
> > +
> > + /* make sure hw is initialized when channel is used the first time */
> > + bchan->initialized = 0;
> > +}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [Patch v5 1/2] dmaengine: add Qualcomm BAM dma driver
From: Josh Cartwright @ 2014-02-11 17:50 UTC (permalink / raw)
To: Vinod Koul
Cc: Andy Gross, Dan Williams, dmaengine, devicetree, linux-kernel,
linux-arm-kernel, linux-arm-msm
In-Reply-To: <20140211174910.GE841@joshc.qualcomm.com>
Ugh.
On Tue, Feb 11, 2014 at 11:49:10AM -0600, Josh Cartwright wrote:
> On Tue, Feb 11, 2014 at 11:00:48PM +0530, Vinod Koul wrote:
> > On Tue, Feb 04, 2014 at 02:42:35PM -0600, Andy Gross wrote:
> > > Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
> > > found in the MSM 8x74 platforms.
> > >
> > > Each BAM DMA device is associated with a specific on-chip peripheral. Each
> > > channel provides a uni-directional data transfer engine that is capable of
> > > transferring data between the peripheral and system memory (System mode), or
> > > between two peripherals (BAM2BAM).
> > >
> > > The initial release of this driver only supports slave transfers between
> > > peripherals and system memory.
> > >
> > > Signed-off-by: Andy Gross <agross@codeaurora.org>
> >
> > > +++ b/drivers/dma/qcom_bam_dma.c
> [..]
> > > +static void bam_reset_channel(struct bam_chan *bchan)
> > > +{
> > > + struct bam_device *bdev = bchan->bdev;
> > > +
> > > + /* reset channel */
> > > + writel_relaxed(1, bdev->regs + BAM_P_RST(bchan->id));
> > > + writel_relaxed(0, bdev->regs + BAM_P_RST(bchan->id));
> > > +
> > > + /* don't allow reorder of the channel reset */
> > > + wmb();
> > Documentation/memory-barriers.txt describes wmb() as a CPU barier but based on
> > above you want it to be a compiler barrier then you should do 1st write,
> > barrier(), second write.
>
> It could also be that the intent was to prevent these writes from being
> ordered before setting the initialized flag below, either way the
^ after
> comment could be made clearer.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v2 0/2] ohci-/ehci-platform: Change compatible string to generic-?hci
From: Kevin Hilman @ 2014-02-11 17:53 UTC (permalink / raw)
To: Hans de Goede
Cc: Greg Kroah-Hartman, Roger Quadros, Alan Stern, Tony Prisk,
Florian Fainelli, Maxime Ripard, Arnd Bergmann, linux-usb,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <1392136529-5060-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> Hi Greg,
>
> And here is v2 of my ohci-/ehci-platform fixes for the regression of USB
> support on various ARM boards I caused in linux-next.
>
> As expected some people still did not like the ?hci-platform compatible
> string I went for in v1, hence this v2. The good news is it seems everyone
> seems to be able to live with generic-?hci as compatible now, so it seems this
> issue is finally settled.
>
> Please add these 2 patches to your usb-next tree, as said in the cover-letter
> of v1, I'm fine with you squashing these into the first 2 patches of my
> original series, but if you want them separate to preserve history that is
> fine too.
I tested this series on top of next-20140211 on the OMAP platforms where
I noticed the regressions, and confirm it fixes the problem.
Tested-by: Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Kevin
^ permalink raw reply
* Re: [Patch v5 1/2] dmaengine: add Qualcomm BAM dma driver
From: Vinod Koul @ 2014-02-11 18:03 UTC (permalink / raw)
To: Josh Cartwright
Cc: Andy Gross, Dan Williams, dmaengine, devicetree, linux-kernel,
linux-arm-kernel, linux-arm-msm
In-Reply-To: <20140211174910.GE841@joshc.qualcomm.com>
On Tue, Feb 11, 2014 at 11:49:10AM -0600, Josh Cartwright wrote:
> On Tue, Feb 11, 2014 at 11:00:48PM +0530, Vinod Koul wrote:
> > On Tue, Feb 04, 2014 at 02:42:35PM -0600, Andy Gross wrote:
> > > Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
> > > found in the MSM 8x74 platforms.
> > >
> > > Each BAM DMA device is associated with a specific on-chip peripheral. Each
> > > channel provides a uni-directional data transfer engine that is capable of
> > > transferring data between the peripheral and system memory (System mode), or
> > > between two peripherals (BAM2BAM).
> > >
> > > The initial release of this driver only supports slave transfers between
> > > peripherals and system memory.
> > >
> > > Signed-off-by: Andy Gross <agross@codeaurora.org>
> >
> > > +++ b/drivers/dma/qcom_bam_dma.c
> [..]
> > > +static void bam_reset_channel(struct bam_chan *bchan)
> > > +{
> > > + struct bam_device *bdev = bchan->bdev;
> > > +
> > > + /* reset channel */
> > > + writel_relaxed(1, bdev->regs + BAM_P_RST(bchan->id));
> > > + writel_relaxed(0, bdev->regs + BAM_P_RST(bchan->id));
> > > +
> > > + /* don't allow reorder of the channel reset */
> > > + wmb();
> > Documentation/memory-barriers.txt describes wmb() as a CPU barier but based on
> > above you want it to be a compiler barrier then you should do 1st write,
> > barrier(), second write.
>
> It could also be that the intent was to prevent these writes from being
> ordered before setting the initialized flag below, either way the
> comment could be made clearer.
yes for that case, but i am suspecting the comment is correct as it would make
sense to ensure reset is in sequence...
--
~Vinod
>
> > > +
> > > + /* make sure hw is initialized when channel is used the first time */
> > > + bchan->initialized = 0;
> > > +}
>
--
^ permalink raw reply
* Re: [PATCH] of: Turn of_match_node into a static inline when CONFIG_OF isn't set
From: Josh Cartwright @ 2014-02-11 18:08 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-kernel, devicetree, Grant Likely, Rob Herring
In-Reply-To: <6446980.WMjvBYStRY@avalon>
On Tue, Feb 11, 2014 at 06:20:49PM +0100, Laurent Pinchart wrote:
> On Tuesday 11 February 2014 10:48:26 Josh Cartwright wrote:
> > On Tue, Feb 11, 2014 at 03:55:35PM +0100, Laurent Pinchart wrote:
> > > On Tuesday 11 February 2014 08:41:08 Josh Cartwright wrote:
> > > > On Tue, Feb 11, 2014 at 01:36:51PM +0100, Laurent Pinchart wrote:
[..]
> > I am a bit weary about having an of_match_node() user that both directly
> > dereferences the result (i.e. of_match_node(matches, np)->data) _and_
> > builds when !CONFIG_OF; most likely due to a traumatic childhood event
> > where demons flew out my nose.
>
> I can assign the intermediate value to a variable before dereferencing it and
> drop my of_match_node() patch if it makes everybody happier.
Assuming you also intend to handle the case of_match_node() may return
NULL, or otherwise prevent the execution of this codepath when
!CONFIG_OF, then, yes, that sounds good.
It sure would be convenient if platform_device had a 'const struct
of_device_id *of_id_entry' member similar to the existing struct
platform_device_id one, that was set up during platform device matching.
Most platform_driver users of of_match_node() would simply go away.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH] of: Turn of_match_node into a static inline when CONFIG_OF isn't set
From: Geert Uytterhoeven @ 2014-02-11 18:29 UTC (permalink / raw)
To: Josh Cartwright
Cc: Laurent Pinchart,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Grant Likely,
Rob Herring
In-Reply-To: <20140211180845.GG841-OP5zVEFNDbfdOxZ39nK119BPR1lH4CV8@public.gmane.org>
On Tue, Feb 11, 2014 at 7:08 PM, Josh Cartwright <joshc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> It sure would be convenient if platform_device had a 'const struct
> of_device_id *of_id_entry' member similar to the existing struct
> platform_device_id one, that was set up during platform device matching.
> Most platform_driver users of of_match_node() would simply go away.
Can't the entry be shared for both platform_device_id and of_device_id?
Only one of them can be valid at the same time, right?
Ideally, all xxx_device_id look like
struct xxx_device_id {
... /* bus-specific ID information */
kernel_ulong_t driver_data;
};
This may be formalized in some way, using a base class, but thay may
require reordering the fields, like:
struct base_device_id {
kernel_ulong_t driver_data;
long id[0];
};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/8] ARM: at91: make use of of_find_matching_node_and_match
From: Josh Cartwright @ 2014-02-11 18:44 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Andrew Victor, Jean-Christophe Plagniol-Villard,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <52FA61F4.90905-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On Tue, Feb 11, 2014 at 06:46:28PM +0100, Nicolas Ferre wrote:
> On 11/02/2014 17:24, Josh Cartwright :
> > Instead of the of_find_matching_node()/of_match_node() pair, which requires two
> > iterations through the match table, make use of of_find_matching_node_and_match(),
> > which only iterates through the table once.
> >
> > While we're here, mark the rtsc id table const.
>
> Well, I might remove this one, just because other id tables are not
> marked as "const" in the same file... So it can be good to change all of
> them in a raw.
Indeed, I was only looking for a specific pattern.
[..]
> => if you want, I can take the patch with me through arm-soc with at91
> material for 3.15 and complete your "const" modification. What do you
> think about that?
Yes, this sounds good.
Thanks,
Josh
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: omap3-n9 family: mark proper OMAP version
From: Aaro Koskinen @ 2014-02-11 18:51 UTC (permalink / raw)
To: Nishanth Menon
Cc: Benoît Cousson, Tony Lindgren, linux-omap, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1392132541-25340-1-git-send-email-nm@ti.com>
Hi,
On Tue, Feb 11, 2014 at 09:29:01AM -0600, Nishanth Menon wrote:
> Nokia N900 uses OMAP3430 and N9/N950 uses OMAP3630. Mark SoC compatibilty
> as per Documentation/devicetree/bindings/arm/omap/omap.txt else
> N9/N950 will be probed as a OMAP3430 type device, since default ti,omap3
> maps to OMAP3430 compatibility.
I already sent & tested patches for this:
http://marc.info/?l=linux-omap&m=139194800711362&w=2
http://marc.info/?l=linux-omap&m=139194800011360&w=2
The N9/N950 is mandatory for 3.14, as the boot hangs without it.
A.
> Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>
> just build tested. but given examples such as
> http://thread.gmane.org/gmane.linux.ports.arm.omap/110006
>
> I guess, some form of failure is expected.
>
> based on v3.14-rc2
>
> arch/arm/boot/dts/omap3-n9.dts | 2 +-
> arch/arm/boot/dts/omap3-n900.dts | 2 +-
> arch/arm/boot/dts/omap3-n950.dts | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> index 39828ce..9938b5d 100644
> --- a/arch/arm/boot/dts/omap3-n9.dts
> +++ b/arch/arm/boot/dts/omap3-n9.dts
> @@ -14,5 +14,5 @@
>
> / {
> model = "Nokia N9";
> - compatible = "nokia,omap3-n9", "ti,omap3";
> + compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
> };
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index 6fc85f9..97db027 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -13,7 +13,7 @@
>
> / {
> model = "Nokia N900";
> - compatible = "nokia,omap3-n900", "ti,omap3";
> + compatible = "nokia,omap3-n900", "ti,omap3430", "ti,omap3";
>
> cpus {
> cpu@0 {
> diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
> index b076a52..261c558 100644
> --- a/arch/arm/boot/dts/omap3-n950.dts
> +++ b/arch/arm/boot/dts/omap3-n950.dts
> @@ -14,5 +14,5 @@
>
> / {
> model = "Nokia N950";
> - compatible = "nokia,omap3-n950", "ti,omap3";
> + compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
> };
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of/gpio: Define OF_GPIO_OPEN_DRAIN flag for Open Drain outputs.
From: David Daney @ 2014-02-11 18:51 UTC (permalink / raw)
To: Alexandre Courbot
Cc: David Daney, Grant Likely, Rob Herring,
devicetree@vger.kernel.org, Linus Walleij,
linux-gpio@vger.kernel.org, Linux Kernel Mailing List,
David Daney
In-Reply-To: <CAAVeFu+_WKzLdhWcB_km3iDj419OhtMXEKzz_yWoL3WUm+7kQQ@mail.gmail.com>
On 02/10/2014 08:31 PM, Alexandre Courbot wrote:
> On Tue, Feb 11, 2014 at 7:05 AM, David Daney <ddaney.cavm@gmail.com> wrote:
>> From: David Daney <david.daney@cavium.com>
>>
>> When we have a GPIO pin connected to an open-drain network, we want a
>> standard way of specifying this in the device tree. So we choose bit
>> 1 of the flag field to indicate open drain.
>>
>> A typical use case would be something like:
>>
>> enum of_gpio_flags f;
>> .
>> .
>> .
>> reset_gpio = of_get_named_gpio_flags(node, "reset", 0, &f);
>> .
>> .
>> .
>> ret = gpio_request_one(reset_gpio,
>> (f & OF_GPIO_OPEN_DRAIN) ? GPIOF_OPEN_DRAIN : 0,
>> "reset");
>> .
>> .
>> .
>> gpio_direction_output(reset_gpio, 1);
>> gpio_set_value(reset_gpio, 0);
>> msleep(20);
>> gpio_set_value(reset_gpio, 1);
>
> This is also useful for gpiod_get(). However, while you are at it,
> could you also add a flag for the OF_GPIO_OPEN_SOURCE property? My joy
> would be complete if you could also take the time to update
> of_find_gpio() to pass these new flags back to the caller as it
> already does for OF_GPIO_ACTIVE_LOW.
>
> Then you could even switch your use-case to the gpiod interface and
> not bother with passing these flags by yourself anymore. Just sayin'.
> ;)
Thanks for the suggestion. I will send a revised patch set for your
consideration.
David Daney
^ permalink raw reply
* Re: [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Grant Likely @ 2014-02-11 19:01 UTC (permalink / raw)
To: Tomasz Figa, Marek Szyprowski,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
Cc: Kyungmin Park, Benjamin Herrenschmidt, Arnd Bergmann,
Michal Nazarewicz, Sascha Hauer, Laura Abbott, Rob Herring,
Olof Johansson, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Tomasz Figa, Kumar Gala, Nishanth Peethambaran,
Marc, Josh Cartwright
In-Reply-To: <52FA33E2.4050004-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Tue, 11 Feb 2014 15:29:54 +0100, Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> > Yes, if only because it is an define usage of the reg property. If a
> > devtree has multiple tuples in reg, then all of those tuples should be
> > treated as reserved, even if the kernel doesn't know how to use them.
> >
> > I would not do the same for size/align/alloc-ranges unless there is a
> > very specific use case that you can define. These ones are different
> > from the static regions because they aren't ever used to protect
> > something that already exists in the memory.
>
> Is there a reason why multiple regions could not be used for this
> purpose, instead of adding extra complexity of having multiple reg
> entries per region?
>
> I.e. I don't see a difference between
>
> reg1: region@00000000 {
> reg = <0x00000000 0x1000>;
> };
>
> reg2: region@10000000 {
> reg = <0x10000000 0x1000>;
> };
>
> user {
> regions = <®1>, <®2>;
> };
>
> and
>
> reg: region@00000000 {
> reg = <0x00000000 0x1000>, <0x10000000 0x1000>;
> };
>
> user {
> regions = <®>;
> };
>
> except that the former IMHO better suits the definition of memory
> region, which I see as a single contiguous range of memory and can be
> simplified to have a single reg entry per region.
My point is rather if multiple reg tuples are found in a reserved memory
node, the kernel must respect them and reserve the memory. I'm not
arguing about whether or not that makes for a good binding.
g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] dt: Update binding information for mvebu gating clocks with Armada 380/385
From: Jason Cooper @ 2014-02-11 19:06 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, Andrew Lunn, Mike Turquette, Tawfik Bayouk,
devicetree, linux-kernel, Nadav Haklai, Ezequiel Garcia,
Gregory CLEMENT, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20140210185908.3374eaf6@skate>
On Mon, Feb 10, 2014 at 06:59:08PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Mon, 10 Feb 2014 18:53:50 +0100, Andrew Lunn wrote:
> > > +The following is a list of provided IDs for Armada 380/385:
> > > +ID Clock Peripheral
> > > +-----------------------------------
> > > +0 audio Audio
> > > +2 ge2 Gigabit Ethernet 2
> > > +3 ge1 Gigabit Ethernet 1
> > > +4 ge0 Gigabit Ethernet 0
> > > +5 pex1 PCIe 1
> > > +6 pex2 PCIe 2
> > > +7 pex3 PCIe 3
> > > +8 pex4 PCIe 0
> >
> > Is that last one a typo? It at least looks a bit odd.
>
> Right, this should be:
>
> 8 pex0 PCIe 0
>
> (just checked again in the datasheet)
I can fix this up when I pull it in for Mike. No need to redo the
series just for this.
I'll let it sit for a day or two more before I pull it to give everyone
a chance to look it over.
thx,
Jason.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] of: Turn of_match_node into a static inline when CONFIG_OF isn't set
From: Laurent Pinchart @ 2014-02-11 19:17 UTC (permalink / raw)
To: Josh Cartwright; +Cc: linux-kernel, devicetree, Grant Likely, Rob Herring
In-Reply-To: <20140211180845.GG841@joshc.qualcomm.com>
Hi Josh,
On Tuesday 11 February 2014 12:08:46 Josh Cartwright wrote:
> On Tue, Feb 11, 2014 at 06:20:49PM +0100, Laurent Pinchart wrote:
> > On Tuesday 11 February 2014 10:48:26 Josh Cartwright wrote:
> > > On Tue, Feb 11, 2014 at 03:55:35PM +0100, Laurent Pinchart wrote:
> > > > On Tuesday 11 February 2014 08:41:08 Josh Cartwright wrote:
> > > > > On Tue, Feb 11, 2014 at 01:36:51PM +0100, Laurent Pinchart wrote:
> [..]
>
> > > I am a bit weary about having an of_match_node() user that both directly
> > > dereferences the result (i.e. of_match_node(matches, np)->data) _and_
> > > builds when !CONFIG_OF; most likely due to a traumatic childhood event
> > > where demons flew out my nose.
> >
> > I can assign the intermediate value to a variable before dereferencing it
> > and drop my of_match_node() patch if it makes everybody happier.
>
> Assuming you also intend to handle the case of_match_node() may return
> NULL, or otherwise prevent the execution of this codepath when
> !CONFIG_OF, then, yes, that sounds good.
I'll condition the call of that function to IS_ENABLED(CONFIG_OF), yes.
> It sure would be convenient if platform_device had a 'const struct
> of_device_id *of_id_entry' member similar to the existing struct
> platform_device_id one, that was set up during platform device matching.
> Most platform_driver users of of_match_node() would simply go away.
There's definitely room for improvement (although in this particular case the
driver handles an I2C device, not a platform device).
I've always been slightly bothered by the duplication of matching information
between native/legacy device IDs and OF device IDs. I haven't really given
this a thought though, but I believe something should be done.
I've just remembered that, in the I2C case, the I2C core selects the
appropriate i2c_device_id matching entry based on the compatible string,
provided that the i2c_device_id table matches the of_device_id table with I2C
device names set to the OF compatible string with the vendor prefix stripped
off. Just food for thought.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/8] bus: mvebu-mbus: make use of of_find_matching_node_and_match
From: Jason Cooper @ 2014-02-11 19:22 UTC (permalink / raw)
To: Josh Cartwright
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, linux-kernel,
devicetree, linux-arm-kernel
In-Reply-To: <1392135847-30791-3-git-send-email-joshc@codeaurora.org>
On Tue, Feb 11, 2014 at 10:24:00AM -0600, Josh Cartwright wrote:
> Instead of the of_find_matching_node()/of_match_node() pair, which requires two
> iterations through the match table, make use of of_find_matching_node_and_match(),
> which only iterates through the table once.
>
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> ---
> drivers/bus/mvebu-mbus.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Applied to mvebu/drivers
thx,
Jason.
^ permalink raw reply
* Re: [PATCH 4/8] ARM: mvebu: make use of of_find_matching_node_and_match
From: Jason Cooper @ 2014-02-11 19:29 UTC (permalink / raw)
To: Josh Cartwright
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, devicetree,
Russell King, linux-kernel, linux-arm-kernel
In-Reply-To: <1392135847-30791-5-git-send-email-joshc@codeaurora.org>
On Tue, Feb 11, 2014 at 10:24:02AM -0600, Josh Cartwright wrote:
> Instead of the of_find_matching_node()/of_match_node() pair, which requires two
> iterations through the match table, make use of of_find_matching_node_and_match(),
> which only iterates through the table once.
>
> While we're here, mark the of_system_controller table const.
>
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> ---
> arch/arm/mach-mvebu/system-controller.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
Applied to mvebu/soc with Thomas' Reviewed-by, and Gregory's Ack.
thx,
Jason.
^ permalink raw reply
* [PATCH v5 0/8] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: David Lanzendörfer @ 2014-02-11 19:33 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Laurent Pinchart,
Mike Turquette, Simon Baatz, Hans de Goede, Emilio López,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Chris Ball,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H Hartley Sweeten,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Tejun Heo, Maxime Ripard,
Guennadi Liakhovetski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hello
The following patchset adds support for the SD/MMC host found in the Allwinner SoCs.
It contains all the necessary modifications for clock environment and also the device
tree script modification which add it to all the boards using it.
The clock environment function needed for phase offset configuration has
been proposed and implemented by Emilio.
A lot of work and cleanup has been done by Hans de Goede. Special thanks to him!
This patchset is the 4th attempt to send this driver upstream.
Changes since v1:
-Using mmc_of_parse instead of diy dt parsing
-Adding nodes for all mmc controller to the dtsi files,
including sofar unused controllers
-Using generic GPIO slot library for WP/CD
-Adding additional MMC device nodes into DTSI files
Changes since v2:
-Add missing Signed-off-by tags
-Stop using __raw_readl / __raw_writel so that barriers are properly used
-Adding missing new lines
-Adding missing patch for automatic reparenting of clocks
Changes since v3:
-Move clk_enable / disable into host_init / exit (Hans)
-Fix hang on boot caused by irq storm (Hans)
Changes since v4:
-moving sunxi-mci.{c/h} to sunxi-mmc.{c/h}
-removing camel cases from the defines in sunxi-mmc.h
-moving defines out of the struct definition
since this is bad coding style
-adding documentation for the device tree binding
---
David Lanzendörfer (5):
ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
ARM: dts: sun7i: Add support for mmc
ARM: dts: sun4i: Add support for mmc
ARM: dts: sun5i: Add support for mmc
ARM: sunxi: Add documentation for driver for SD/MMC hosts found on Allwinner sunxi SoCs
Emilio López (2):
clk: sunxi: factors: automatic reparenting support
clk: sunxi: Implement MMC phase control
Hans de Goede (1):
ARM: sunxi: clk: export clk_sunxi_mmc_phase_control
.../devicetree/bindings/mmc/sunxi-mmc.txt | 32 +
arch/arm/boot/dts/sun4i-a10-a1000.dts | 8
arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 8
arch/arm/boot/dts/sun4i-a10.dtsi | 54 +
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 30 +
arch/arm/boot/dts/sun5i-a10s.dtsi | 44 +
arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts | 15
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 15
arch/arm/boot/dts/sun5i-a13.dtsi | 37 +
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 8
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 8
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 23 +
arch/arm/boot/dts/sun7i-a20.dtsi | 61 +
drivers/clk/sunxi/clk-factors.c | 36 +
drivers/clk/sunxi/clk-sunxi.c | 35 +
drivers/mmc/host/Kconfig | 7
drivers/mmc/host/Makefile | 2
drivers/mmc/host/sunxi-mmc.c | 872 ++++++++++++++++++++
drivers/mmc/host/sunxi-mmc.h | 239 +++++
include/linux/clk/sunxi.h | 22 +
20 files changed, 1556 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
create mode 100644 drivers/mmc/host/sunxi-mmc.c
create mode 100644 drivers/mmc/host/sunxi-mmc.h
create mode 100644 include/linux/clk/sunxi.h
--
Signature
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* [PATCH v5 1/8] clk: sunxi: factors: automatic reparenting support
From: David Lanzendörfer @ 2014-02-11 19:33 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Laurent Pinchart,
Mike Turquette, Simon Baatz, Hans de Goede, Emilio López,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Chris Ball,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H Hartley Sweeten,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Tejun Heo, Maxime Ripard,
Guennadi Liakhovetski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140211190543.4568.83517.stgit-GPtPHOohwllnsqa/0SyWJQ@public.gmane.org>
From: Emilio López <emilio-0Z03zUJReD5OxF6Tv1QG9Q@public.gmane.org>
This commit implements .determine_rate, so that our factor clocks can be
reparented when needed.
Signed-off-by: Emilio López <emilio-0Z03zUJReD5OxF6Tv1QG9Q@public.gmane.org>
---
drivers/clk/sunxi/clk-factors.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index 9e23264..3806d97 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -77,6 +77,41 @@ static long clk_factors_round_rate(struct clk_hw *hw, unsigned long rate,
return rate;
}
+static long clk_factors_determine_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *best_parent_rate,
+ struct clk **best_parent_p)
+{
+ struct clk *clk = hw->clk, *parent, *best_parent = NULL;
+ int i, num_parents;
+ unsigned long parent_rate, best = 0, child_rate, best_child_rate = 0;
+
+ /* find the parent that can help provide the fastest rate <= rate */
+ num_parents = __clk_get_num_parents(clk);
+ for (i = 0; i < num_parents; i++) {
+ parent = clk_get_parent_by_index(clk, i);
+ if (!parent)
+ continue;
+ if (__clk_get_flags(clk) & CLK_SET_RATE_PARENT)
+ parent_rate = __clk_round_rate(parent, rate);
+ else
+ parent_rate = __clk_get_rate(parent);
+
+ child_rate = clk_factors_round_rate(hw, rate, &parent_rate);
+
+ if (child_rate <= rate && child_rate > best_child_rate) {
+ best_parent = parent;
+ best = parent_rate;
+ best_child_rate = child_rate;
+ }
+ }
+
+ if (best_parent)
+ *best_parent_p = best_parent;
+ *best_parent_rate = best;
+
+ return best_child_rate;
+}
+
static int clk_factors_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
@@ -113,6 +148,7 @@ static int clk_factors_set_rate(struct clk_hw *hw, unsigned long rate,
}
const struct clk_ops clk_factors_ops = {
+ .determine_rate = clk_factors_determine_rate,
.recalc_rate = clk_factors_recalc_rate,
.round_rate = clk_factors_round_rate,
.set_rate = clk_factors_set_rate,
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply related
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