Re: [PATCH v5 2/4] media: ov2640: add async probe function
Hi Josh,
Thanks for a patch update. I think it looks good as a first step in your
patch series, just a minor comment below:
On Tue, 10 Feb 2015, Josh Wu wrote:
> In async probe, there is a case that ov2640 is probed before the
> host device which provided 'mclk'.
> To support this async probe, we will get 'mclk' at first in the probe(),
> if failed it will return -EPROBE_DEFER. That will let ov2640 wait for
> the host device probed.
>
> Signed-off-by: Josh Wu
> ---
>
> Changes in v5:
> - don't change the ov2640_s_power() code.
> - will get 'mclk' at the beginning of ov2640_probe().
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> drivers/media/i2c/soc_camera/ov2640.c | 29 +++--
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/i2c/soc_camera/ov2640.c
> b/drivers/media/i2c/soc_camera/ov2640.c
> index 1fdce2f..057dd49 100644
> --- a/drivers/media/i2c/soc_camera/ov2640.c
> +++ b/drivers/media/i2c/soc_camera/ov2640.c
> @@ -1068,6 +1068,10 @@ static int ov2640_probe(struct i2c_client *client,
> return -ENOMEM;
> }
>
> + priv->clk = v4l2_clk_get(&client->dev, "mclk");
> + if (IS_ERR(priv->clk))
> + return -EPROBE_DEFER;
> +
> v4l2_i2c_subdev_init(&priv->subdev, client, &ov2640_subdev_ops);
> v4l2_ctrl_handler_init(&priv->hdl, 2);
> v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
> @@ -1075,24 +1079,28 @@ static int ov2640_probe(struct i2c_client *client,
> v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
> V4L2_CID_HFLIP, 0, 1, 1, 0);
> priv->subdev.ctrl_handler = &priv->hdl;
> - if (priv->hdl.error)
> - return priv->hdl.error;
> -
> - priv->clk = v4l2_clk_get(&client->dev, "mclk");
> - if (IS_ERR(priv->clk)) {
> - ret = PTR_ERR(priv->clk);
> - goto eclkget;
> + if (priv->hdl.error) {
> + ret = priv->hdl.error;
> + goto err_clk;
> }
>
> ret = ov2640_video_probe(client);
> if (ret) {
> - v4l2_clk_put(priv->clk);
> -eclkget:
> - v4l2_ctrl_handler_free(&priv->hdl);
> + goto err_videoprobe;
Since you add a "goto" here, you don't need an "else" after it, and the
"probed" success message should go down, so, just make it
ret = ov2640_video_probe(client);
if (ret < 0)
goto err_videoprobe;
ret = v4l2_async_register_subdev(&priv->subdev);
if (ret < 0)
goto err_videoprobe;
dev_info(&adapter->dev, "OV2640 Probed\n");
return 0;
err_...
Thanks
Guennadi
> } else {
> dev_info(&adapter->dev, "OV2640 Probed\n");
> }
>
> + ret = v4l2_async_register_subdev(&priv->subdev);
> + if (ret < 0)
> + goto err_videoprobe;
> +
> + return 0;
> +
> +err_videoprobe:
> + v4l2_ctrl_handler_free(&priv->hdl);
> +err_clk:
> + v4l2_clk_put(priv->clk);
> return ret;
> }
>
> @@ -1100,6 +1108,7 @@ static int ov2640_remove(struct i2c_client *client)
> {
> struct ov2640_priv *priv = to_ov2640(client);
>
> + v4l2_async_unregister_subdev(&priv->subdev);
> v4l2_clk_put(priv->clk);
> v4l2_device_unregister_subdev(&priv->subdev);
> v4l2_ctrl_handler_free(&priv->hdl);
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] dmaengine: nbpfaxi: convert to tasklet
It is common among dmaengine drivers to use a tasklet for bottom half
interrupt processing. Convert nbpfaxi to do the same.
Signed-off-by: Guennadi Liakhovetski
---
drivers/dma/nbpfaxi.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c
index 5b40ac8..cea6a37 100644
--- a/drivers/dma/nbpfaxi.c
+++ b/drivers/dma/nbpfaxi.c
@@ -197,6 +197,7 @@ struct nbpf_desc_page {
*/
struct nbpf_channel {
struct dma_chan dma_chan;
+ struct tasklet_struct tasklet;
void __iomem *base;
struct nbpf_device *nbpf;
char name[16];
@@ -,9 +1112,9 @@ static struct dma_chan *nbpf_of_xlate(struct
of_phandle_args *dma_spec,
return dchan;
}
-static irqreturn_t nbpf_chan_irqt(int irq, void *dev)
+static void nbpf_chan_tasklet(unsigned long data)
{
- struct nbpf_channel *chan = dev;
+ struct nbpf_channel *chan = (struct nbpf_channel *)data;
struct nbpf_desc *desc, *tmp;
dma_async_tx_callback callback;
void *param;
@@ -1176,8 +1177,6 @@ static irqreturn_t nbpf_chan_irqt(int irq, void *dev)
if (must_put)
nbpf_desc_put(desc);
}
-
- return IRQ_HANDLED;
}
static irqreturn_t nbpf_chan_irq(int irq, void *dev)
@@ -1186,6 +1185,7 @@ static irqreturn_t nbpf_chan_irq(int irq, void *dev)
bool done = nbpf_status_get(chan);
struct nbpf_desc *desc;
irqreturn_t ret;
+ bool bh = false;
if (!done)
return IRQ_NONE;
@@ -1200,7 +1200,8 @@ static irqreturn_t nbpf_chan_irq(int irq, void *dev)
ret = IRQ_NONE;
goto unlock;
} else {
- ret = IRQ_WAKE_THREAD;
+ ret = IRQ_HANDLED;
+ bh = true;
}
list_move_tail(&desc->node, &chan->done);
@@ -1216,6 +1217,9 @@ static irqreturn_t nbpf_chan_irq(int irq, void *dev)
unlock:
spin_unlock(&chan->lock);
+ if (bh)
+ tasklet_schedule(&chan->tasklet);
+
return ret;
}
@@ -1258,8 +1262,9 @@ static int nbpf_chan_probe(struct nbpf_device *nbpf, int
n)
snprintf(chan->name, sizeof(chan->name), "nbpf %d", n);
- ret = devm_request_threaded_irq(dma_dev->dev, chan->irq,
- nbpf_chan_irq, nbpf_chan_irqt, IRQF_SHARED,
+ tasklet_init(&chan->tasklet, nbpf_chan_tasklet, (unsigned long)chan);
+ ret = devm_request_irq(dma_dev->dev, chan->irq,
+ nbpf_chan_irq, IRQF_SHARED,
chan->name, chan);
if (ret < 0)
return ret;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] dmaengine: nbpfaxi: fix a theoretical race
A race possibility exists if a DMA slave driver tries to free channel resources witout waiting for all transfers to complete and without explicitly terminating all requests. In such a case the IRQ processing thread can race with .device_free_chan_resources(). To fix this race empty all descriptor lists before freeing descriptor cache. Signed-off-by: Guennadi Liakhovetski --- drivers/dma/nbpfaxi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c index 77c5a89..5b40ac8 100644 --- a/drivers/dma/nbpfaxi.c +++ b/drivers/dma/nbpfaxi.c @@ -1054,6 +1054,7 @@ static void nbpf_free_chan_resources(struct dma_chan *dchan) dev_dbg(dchan->device->dev, "Entry %s()\n", __func__); nbpf_chan_halt(chan); + nbpf_chan_idle(chan); /* Clean up for if a channel is re-used for MEMCPY after slave DMA */ nbpf_chan_prepare_default(chan); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
Hi Vinod, On Fri, 1 Aug 2014, Vinod Koul wrote: > On Thu, Jul 31, 2014 at 03:42:44PM +0200, Guennadi Liakhovetski wrote: > > Ok. This doesn't seem to progress. You suggested in your previous mail, > > that I can provide an incremental patch to add devm_free(_threaded)_irq() > > and synchronize_irq() to .release(). I still think, that this doesn't make > > much sense, but if you insist... Alternatively, my proposal would be to > > fix the thoretical race in .free_chan_resources(). Would you accept such a > > patch instead of what you were proposing? I can also convert the driver to > > using a tasklet, if required. Would it suffice, if I do those patches as > > fixes after -rc1? I'm leaving on a holiday tomorrow and I still have to > > finalise some other work, so, preparing those patches today doesn't seem > > realistic to me... Would this be acceptable? > Can you please send both, incrementally is fine. > I will merge them tomorrow Sorry, do you mean I should send those incremental patches for the original one to become acceptable? As I explained above, I'm on a holiday now, so, I hoped it would be acceptble to get this patch in and let me do the other two later, possibly after -rc1 as fixes. If you definitely would like all 3 patches now... Well, I could try, but this won't be easy... Thanks Guennadi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
On Thu, 31 Jul 2014, Vinod Koul wrote:
> On Sat, Jul 26, 2014 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> > On Fri, 25 Jul 2014, Vinod Koul wrote:
> > > And please also see there were regression on few of them, recently dw was
> > > fixed for this case. Similarly few other drivers were fixed for their
> > > behaviour in tasklet kill, syncronizing the irq and freeing up behaviour.
> > >
> > > So now back to this driver, since you are using devm_ the irq is not
> > > freed,
> > > so how does it prevent race.
> >
> > How is it not freed? Of course it is freed, but later - after .release()
> > has completed.
> >
> > As for races - AFAIU, no interrupts should be coming after all DMA
> > channels have been freed, and .release() will not be called as long as any
> > channels are in use. However, I think, there might be a chance for a race
> > if the user would try to free a DMA channel before all descriptors have
> > completed and without calling TERMINATE_ALL. I think this would be an
> > abnormal behaviour - usually you either wait for all descriptors to
> > complete or terminate any remaining ones, but if such a buggy DMA slave
> > driver would be used, and if .device_free_chan_resources() gets called
> > (on a different CPU core) after a hard IRQ has completed and before the
> > IRQ thread has run (this would be the same if a tasklet was used in the
> > driver instead of an IRQ thread), i.e.
> >
> > CPU core #0 CPU core #1
> >
> > DMA IRQ
> > schedule IRQ thread
> > .device_free_chan_resources()
> > IRQ thread:
> > nbpf_chan_irqt()
> >
> > then there can be a problem, because .device_free_chan_resources() would
> > free descriptor pages and the IRQ thread would try to use them.
> >
> > Again, I consider that case to be a buggy DMA slave and even then such a
> > race would be very unlikely, but theoretically it might be possible. The
> > fix can be as simple as calling nbpf_chan_idle() from
> > nbpf_free_chan_resources(). Would you like a new version with this single
> > change or would such an incremental patch suffice?
>
> There are two issues in the current driver.
> 1. You have a spurious irq. That will lead your irq running. Although
> your driver handlers can handle this, but with remove it will race and cause
> panic because your have not freed irq.
Why? Why should it panic? The managed resource handling framework will
free IRQs before freeing the private driver object, so, pointers will
still be valid, because those objects, including memory for all channels:
nbpf = devm_kzalloc(dev, sizeof(*nbpf) + num_channels *
sizeof(nbpf->chan[0]), GFP_KERNEL);
are allocated before interrupts are requested. This is a very important
guarantee, without which nothing would work. So, these lines in the IRQ
handler:
static irqreturn_t nbpf_chan_irq(int irq, void *dev)
{
struct nbpf_channel *chan = dev;
bool done = nbpf_status_get(chan);
struct nbpf_desc *desc;
irqreturn_t ret;
if (!done)
return IRQ_NONE;
will run without problem.
> 2. There is nothing in your .remove which ensures all the threads have
> exited. Yes with the above argument this sounds not so simple to achieve as
> typically we get irq, callback and free the channel. But as your rightly
> pointed in multi-core systems there can be instance where you get back to
> back interrupts where descriptor sizes where small, so while processing your
> some thread maybe still stuck while user frees up.
>
> The job of .remove is to ensure you clean up everything. the fact that you
> can still get irq after remove makes this a not so good design!
Ok, I mentioned in one of my previous mails the possibility of IRQ threads
racing with .free_chan_resources(). And .free_chan_resources() should
complete before .remove(), right? So, in fact we do have to fix my
theoretical race, then your race will be fixed automatically too.
> > > If we do ensure that, then yes driver is fine
> > > and can be merged, otherwise needs a fix
> > > >
> > > > > You need to run free_irq and synchronize_irq()
> > > > > to ensure everything is proper before freeing up.
> > > > >
> > > > > Also why threaded_irq when dmaengine API mandates you to use tasklet?
> > > > > The
> > > > > callback is supposed to be invoked from a tasklet.
> > > >
> > > > As for this one. Yes, I'm aware, that most other dmaengine drivers use
> > > > a
> > > > tasklet for bo
Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
Hi Vinod, On Mon, 28 Jul 2014, Guennadi Liakhovetski wrote: > > Looking at the code again, I think we need to free irq (you can call > > devm_free_irq()) and call syncronize_irq so that anything pending is > > flushed. So if you can send follow up patch doing these in .remove, we can > > merge these > > This is a nice offer, thanks! But to accept it I'd like to understand: why > do you think we need that? In my previous email I presented to you a > theoretical and improbable race situation, that I can foresee. You erased > it in your reply, but it was dealing with the > .device_free_chan_resources() method, so, your suspected race is a > different one. Could you please explain to me, why do you think interrupts > are possible during .release()? Aren't all channels guaranteed to have > been freed by that time? It would be great to get an explanation for your comment, please? How can interrupts come after all channels have been freed? Or how can .release() be called while some channels are still in use? Thanks Guennadi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
Hi Vinod,
On Mon, 28 Jul 2014, Vinod Koul wrote:
> On Sat, Jul 26, 2014 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> > On Fri, 25 Jul 2014, Vinod Koul wrote:
> >
> > > On Fri, Jul 25, 2014 at 05:00:53PM +0200, Guennadi Liakhovetski wrote:
> > > > Hi Vinod,
> > > >
> > > > On Fri, 25 Jul 2014, Vinod Koul wrote:
> > > >
> > > > Thanks for your review. However, I find the following a bit odd. As you
> > > > remember, you already reviewed v2 of this driver:
> > > >
> > > > http://www.spinics.net/lists/dmaengine/msg00880.html
> > > >
> > > > and provided your comments to it, which I addressed in versions 3 and
> > > > 4.
> > > > Code, that you're commenting on here, hasn't (significantly) changed
> > > > since
> > > > v1. During your v2 review it didn't seem offending to you, now it does.
> > > > Does this mean, that if / once I fix these issues, your next review
> > > > might
> > > > find some more _old_ code snippets, that you decide aren't appropriate?
> > > >
> > > > This isn't the first time such a thing is happening with various
> > > > reviewers
> > > > and patch submitters. I think a reasonable approach is to "trust your
> > > > own
> > > > review." Once I've reviewed a piece of code and found it ok, I
> > > > _normally_
> > > > won't ask a patch author to modify code, that didn't change since my
> > > > previous review. Simple. Of course, sometimes it does happen, that the
> > > > first review skips some important flaws, but then I consider that my
> > > > fault, if I didn't find them during the first round and try to find a
> > > > solution to minimise the damage to the author. Now, to specific
> > > > comments.
> > > I agree you can blame me for not spotting them earlier and yes criticism
> > > is
> > > fair. But then overall goal is to ensure that code is better, so even if
> > > comment comes late we should accept it.
> >
> > Apparently, our approaches differ somewhat here. I explained already what
> > I normally do in such cases.
> >
> > > > > On Sat, Jul 19, 2014 at 12:48:51PM +0200, Guennadi Liakhovetski wrote:
> > > > > > This patch adds a driver for NBPF DMAC IP cores from Renesas,
> > > > > > designed for
> > > > > > the AMBA AXI bus.
> > > > > >
> > > > >
> > > > > > +struct nbpf_desc {
> > > > > > + struct dma_async_tx_descriptor async_tx;
> > > > > > + bool user_wait;
> > > > > sounds odd?
> > > >
> > > > Maybe it's not the best name, I can gladly try to improve it, but I'm
> > > > sure
> > > > I'm not the best "namer," so, the same can be said about more or less
> > > > every identifier in all my code - it could be improved. However, I
> > > > don't
> > > > think it's critical enough to delay mainlining until the next kernel
> > > > version?
> > > No it is not critical at all!
> > >
> > > > > > +static int nbpf_chan_probe(struct nbpf_device *nbpf, int n)
> > > > > > +{
> > > > > > + struct dma_device *dma_dev = &nbpf->dma_dev;
> > > > > > + struct nbpf_channel *chan = nbpf->chan + n;
> > > > > > + int ret;
> > > > > > +
> > > > > > + chan->nbpf = nbpf;
> > > > > > + chan->base = nbpf->base + NBPF_REG_CHAN_OFFSET +
> > > > > > NBPF_REG_CHAN_SIZE * n;
> > > > > > + INIT_LIST_HEAD(&chan->desc_page);
> > > > > > + spin_lock_init(&chan->lock);
> > > > > > + chan->dma_chan.device = dma_dev;
> > > > > > + dma_cookie_init(&chan->dma_chan);
> > > > > > + nbpf_chan_prepare_default(chan);
> > > > > > +
> > > > > > + dev_dbg(dma_dev->dev, "%s(): channel %d: -> %p\n", __func__, n,
> > > > > > chan->base);
> > > > > > +
> > > > > > + snprintf(chan->name, sizeof(chan->name), "nbpf %d", n);
> > > > > > +
> > > > > > + ret = devm_request_threaded_irq(dma_dev->dev,
Re: [PATCH v3 3/3] media: atmel-isi: add primary DT support
Hi Josh,
Thanks for a prompt update! A couple of minor questions:
On Fri, 25 Jul 2014, Josh Wu wrote:
> This patch add the DT support for Atmel ISI driver.
> It use the same v4l2 DT interface that defined in video-interfaces.txt.
>
> Signed-off-by: Josh Wu
> Cc: devicetree@vger.kernel.org
> Reviewed-by: Laurent Pinchart
> ---
> v2 -> v3:
> add bus-width property support.
> add error handling when calling atmel_isi_probe_dt().
>
> v1 -> v2:
> refine the binding document.
> add port node description.
> removed the optional property.
>
> .../devicetree/bindings/media/atmel-isi.txt| 51 +
> drivers/media/platform/soc_camera/atmel-isi.c | 64
> +-
> 2 files changed, 113 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt
> b/Documentation/devicetree/bindings/media/atmel-isi.txt
> new file mode 100644
> index 000..17e71b7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
> @@ -0,0 +1,51 @@
> +Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
> +--
> +
> +Required properties:
> +- compatible: must be "atmel,at91sam9g45-isi"
> +- reg: physical base address and length of the registers set for the device;
> +- interrupts: should contain IRQ line for the ISI;
> +- clocks: list of clock specifiers, corresponding to entries in
> + the clock-names property;
> +- clock-names: must contain "isi_clk", which is the isi peripherial clock.
> +
> +ISI supports a single port node with parallel bus. It should contain one
> +'port' child node with child 'endpoint' node. Please refer to the bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> + isi: isi@f0034000 {
> + compatible = "atmel,at91sam9g45-isi";
> + reg = <0xf0034000 0x4000>;
> + interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
> +
> + clocks = <&isi_clk>;
> + clock-names = "isi_clk";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_isi>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + isi_0: endpoint {
> + remote-endpoint = <&ov2640_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> +
> + i2c1: i2c@f0018000 {
> + ov2640: camera@0x30 {
> + compatible = "omnivision,ov2640";
> + reg = <0x30>;
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
> b/drivers/media/platform/soc_camera/atmel-isi.c
> index 74af560..ca4e43e 100644
> --- a/drivers/media/platform/soc_camera/atmel-isi.c
> +++ b/drivers/media/platform/soc_camera/atmel-isi.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define MAX_BUFFER_NUM 32
> @@ -33,6 +34,7 @@
> #define VID_LIMIT_BYTES (16 * 1024 * 1024)
> #define MIN_FRAME_RATE 15
> #define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
> +#define ISI_DEFAULT_MCLK_FREQ2500
>
> /* Frame buffer descriptor */
> struct fbd {
> @@ -883,6 +885,50 @@ static int atmel_isi_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int atmel_isi_probe_dt(struct atmel_isi *isi,
> + struct platform_device *pdev)
> +{
> + struct device_node *np= pdev->dev.of_node;
> + struct v4l2_of_endpoint ep;
> + int err;
> +
> + /* Default settings for ISI */
> + isi->pdata.full_mode = 1;
> + isi->pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
> + isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
> +
> + np = of_graph_get_next_endpoint(np, NULL);
> + if (!np) {
> + dev_err(&pdev->dev, "Could not find the endpoint\n");
> + return -EINVAL;
> + }
> +
> + err = v4l2_of_parse_endpoint(np, &ep);
> + if (err) {
> + dev_err(&pdev->dev, "Could not parse the endpoint\n");
> + goto err_probe_dt;
> + }
> +
> + switch (ep.bus.parallel.bus_width) {
> + case 8:
> + isi->pdata.data_width_flags = ISI_DATAWIDTH_8;
> + break;
> + case 10:
> + isi->pdata.data_width_flags = ISI_DATAWIDTH_10;
> + break;
Wouldn't it be natural, if bus_width=10 is specified in DT to enable both
ISI_DATAWIDTH_8 and ISI_DATAWIDTH_10?
> +
Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
On Fri, 25 Jul 2014, Vinod Koul wrote:
> On Fri, Jul 25, 2014 at 05:00:53PM +0200, Guennadi Liakhovetski wrote:
> > Hi Vinod,
> >
> > On Fri, 25 Jul 2014, Vinod Koul wrote:
> >
> > Thanks for your review. However, I find the following a bit odd. As you
> > remember, you already reviewed v2 of this driver:
> >
> > http://www.spinics.net/lists/dmaengine/msg00880.html
> >
> > and provided your comments to it, which I addressed in versions 3 and 4.
> > Code, that you're commenting on here, hasn't (significantly) changed since
> > v1. During your v2 review it didn't seem offending to you, now it does.
> > Does this mean, that if / once I fix these issues, your next review might
> > find some more _old_ code snippets, that you decide aren't appropriate?
> >
> > This isn't the first time such a thing is happening with various reviewers
> > and patch submitters. I think a reasonable approach is to "trust your own
> > review." Once I've reviewed a piece of code and found it ok, I _normally_
> > won't ask a patch author to modify code, that didn't change since my
> > previous review. Simple. Of course, sometimes it does happen, that the
> > first review skips some important flaws, but then I consider that my
> > fault, if I didn't find them during the first round and try to find a
> > solution to minimise the damage to the author. Now, to specific comments.
> I agree you can blame me for not spotting them earlier and yes criticism is
> fair. But then overall goal is to ensure that code is better, so even if
> comment comes late we should accept it.
Apparently, our approaches differ somewhat here. I explained already what
I normally do in such cases.
> > > On Sat, Jul 19, 2014 at 12:48:51PM +0200, Guennadi Liakhovetski wrote:
> > > > This patch adds a driver for NBPF DMAC IP cores from Renesas, designed
> > > > for
> > > > the AMBA AXI bus.
> > > >
> > >
> > > > +struct nbpf_desc {
> > > > + struct dma_async_tx_descriptor async_tx;
> > > > + bool user_wait;
> > > sounds odd?
> >
> > Maybe it's not the best name, I can gladly try to improve it, but I'm sure
> > I'm not the best "namer," so, the same can be said about more or less
> > every identifier in all my code - it could be improved. However, I don't
> > think it's critical enough to delay mainlining until the next kernel
> > version?
> No it is not critical at all!
>
> > > > +static int nbpf_chan_probe(struct nbpf_device *nbpf, int n)
> > > > +{
> > > > + struct dma_device *dma_dev = &nbpf->dma_dev;
> > > > + struct nbpf_channel *chan = nbpf->chan + n;
> > > > + int ret;
> > > > +
> > > > + chan->nbpf = nbpf;
> > > > + chan->base = nbpf->base + NBPF_REG_CHAN_OFFSET +
> > > > NBPF_REG_CHAN_SIZE * n;
> > > > + INIT_LIST_HEAD(&chan->desc_page);
> > > > + spin_lock_init(&chan->lock);
> > > > + chan->dma_chan.device = dma_dev;
> > > > + dma_cookie_init(&chan->dma_chan);
> > > > + nbpf_chan_prepare_default(chan);
> > > > +
> > > > + dev_dbg(dma_dev->dev, "%s(): channel %d: -> %p\n", __func__, n,
> > > > chan->base);
> > > > +
> > > > + snprintf(chan->name, sizeof(chan->name), "nbpf %d", n);
> > > > +
> > > > + ret = devm_request_threaded_irq(dma_dev->dev, chan->irq,
> > > > + nbpf_chan_irq, nbpf_chan_irqt, IRQF_SHARED,
> > > > + chan->name, chan);
> > > devm_request_irq and friends arent apt here. You are in .remove and get an
> > > irq, what prevents that race?
> >
> > How is this your comment different for DMA drivers from any other drivers?
> > Of course you have to make sure no more interrupts are arriving once in
> > .remove() you lost the ability to handle IRQs. So, AFAIU, it's always a
> > per-case study: you have to look at .remove() and consider, what happens
> > if IRQ hits at any point inside it - if at all possible. Besides, DMA
> > engine drivers are additionally protected by incremented module
> > use-counts, once a channel is in use? As soon as a channel is released
> > your driver has to make sure no more IRQs are occurring. Besides, there's
> > a dma
Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
Hi Vinod,
On Fri, 25 Jul 2014, Vinod Koul wrote:
Thanks for your review. However, I find the following a bit odd. As you
remember, you already reviewed v2 of this driver:
http://www.spinics.net/lists/dmaengine/msg00880.html
and provided your comments to it, which I addressed in versions 3 and 4.
Code, that you're commenting on here, hasn't (significantly) changed since
v1. During your v2 review it didn't seem offending to you, now it does.
Does this mean, that if / once I fix these issues, your next review might
find some more _old_ code snippets, that you decide aren't appropriate?
This isn't the first time such a thing is happening with various reviewers
and patch submitters. I think a reasonable approach is to "trust your own
review." Once I've reviewed a piece of code and found it ok, I _normally_
won't ask a patch author to modify code, that didn't change since my
previous review. Simple. Of course, sometimes it does happen, that the
first review skips some important flaws, but then I consider that my
fault, if I didn't find them during the first round and try to find a
solution to minimise the damage to the author. Now, to specific comments.
> On Sat, Jul 19, 2014 at 12:48:51PM +0200, Guennadi Liakhovetski wrote:
> > This patch adds a driver for NBPF DMAC IP cores from Renesas, designed for
> > the AMBA AXI bus.
> >
>
> > +struct nbpf_desc {
> > + struct dma_async_tx_descriptor async_tx;
> > + bool user_wait;
> sounds odd?
Maybe it's not the best name, I can gladly try to improve it, but I'm sure
I'm not the best "namer," so, the same can be said about more or less
every identifier in all my code - it could be improved. However, I don't
think it's critical enough to delay mainlining until the next kernel
version?
> > +static int nbpf_chan_probe(struct nbpf_device *nbpf, int n)
> > +{
> > + struct dma_device *dma_dev = &nbpf->dma_dev;
> > + struct nbpf_channel *chan = nbpf->chan + n;
> > + int ret;
> > +
> > + chan->nbpf = nbpf;
> > + chan->base = nbpf->base + NBPF_REG_CHAN_OFFSET + NBPF_REG_CHAN_SIZE * n;
> > + INIT_LIST_HEAD(&chan->desc_page);
> > + spin_lock_init(&chan->lock);
> > + chan->dma_chan.device = dma_dev;
> > + dma_cookie_init(&chan->dma_chan);
> > + nbpf_chan_prepare_default(chan);
> > +
> > + dev_dbg(dma_dev->dev, "%s(): channel %d: -> %p\n", __func__, n,
> > chan->base);
> > +
> > + snprintf(chan->name, sizeof(chan->name), "nbpf %d", n);
> > +
> > + ret = devm_request_threaded_irq(dma_dev->dev, chan->irq,
> > + nbpf_chan_irq, nbpf_chan_irqt, IRQF_SHARED,
> > + chan->name, chan);
> devm_request_irq and friends arent apt here. You are in .remove and get an
> irq, what prevents that race?
How is this your comment different for DMA drivers from any other drivers?
Of course you have to make sure no more interrupts are arriving once in
.remove() you lost the ability to handle IRQs. So, AFAIU, it's always a
per-case study: you have to look at .remove() and consider, what happens
if IRQ hits at any point inside it - if at all possible. Besides, DMA
engine drivers are additionally protected by incremented module
use-counts, once a channel is in use? As soon as a channel is released
your driver has to make sure no more IRQs are occurring. Besides, there's
a dmaengine_get()... So, I think, we really need to first find a race
possibility, and then fix it. Besides, you could try
grep -rl devm_request_irq drivers/dma/*.c
> You need to run free_irq and synchronize_irq()
> to ensure everything is proper before freeing up.
>
> Also why threaded_irq when dmaengine API mandates you to use tasklet? The
> callback is supposed to be invoked from a tasklet.
As for this one. Yes, I'm aware, that most other dmaengine drivers use a
tasklet for bottom half IRQ processing. But is there a real requirement
for that? This driver has been written in the end of last year and has
been in use since then - no problems. As long as proper locking is used,
an IRQ thread seems to work just fine here. And allows us to leverage the
threaded-IRQ API instead of inventing own bottom-half processing.
But if there's a _real_ essential reason to use a tasklet here, I can
switch, np. Does it really have to be done now or would an incremental
patch suffice?
Thanks
Guennadi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] media: soc_camera: pxa_camera device-tree support
(re-adding Cc) On Wed, 23 Jul 2014, Robert Jarzmik wrote: > Guennadi Liakhovetski writes: > > > Add device-tree support to pxa_camera host driver. > > > > Signed-off-by: Robert Jarzmik > > [g.liakhovet...@gmx.de: added of_node_put()] > > Signed-off-by: Guennadi Liakhovetski > > --- > > > > Robert, could you review and test this version, please? > Review +1. > Tested and works fine, so good to go. Thanks for a quick test! One question: to test this you also needed a version of Ben's "soc_camera: add support for dt binding soc_camera drivers" patch, right? Did you use the last version from Ben or my amended version, that I sent yesterday? If you didn't use my version, would it be possible for you to test it and reply with your tested-by if all looks ok? Thanks Guennadi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] media: soc_camera: pxa_camera device-tree support
Add device-tree support to pxa_camera host driver.
Signed-off-by: Robert Jarzmik
[g.liakhovet...@gmx.de: added of_node_put()]
Signed-off-by: Guennadi Liakhovetski
---
Robert, could you review and test this version, please?
Thanks
Guennadi
drivers/media/platform/soc_camera/pxa_camera.c | 81 +-
1 file changed, 79 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index d4df305..64dc80c 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -1650,6 +1651,68 @@ static struct soc_camera_host_ops
pxa_soc_camera_host_ops = {
.set_bus_param = pxa_camera_set_bus_param,
};
+static int pxa_camera_pdata_from_dt(struct device *dev,
+ struct pxa_camera_dev *pcdev)
+{
+ u32 mclk_rate;
+ struct device_node *np = dev->of_node;
+ struct v4l2_of_endpoint ep;
+ int err = of_property_read_u32(np, "clock-frequency",
+ &mclk_rate);
+ if (!err) {
+ pcdev->platform_flags |= PXA_CAMERA_MCLK_EN;
+ pcdev->mclk = mclk_rate;
+ }
+
+ np = of_graph_get_next_endpoint(np, NULL);
+ if (!np) {
+ dev_err(dev, "could not find endpoint\n");
+ return -EINVAL;
+ }
+
+ err = v4l2_of_parse_endpoint(np, &ep);
+ if (err) {
+ dev_err(dev, "could not parse endpoint\n");
+ goto out;
+ }
+
+ switch (ep.bus.parallel.bus_width) {
+ case 4:
+ pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_4;
+ break;
+ case 5:
+ pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_5;
+ break;
+ case 8:
+ pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_8;
+ break;
+ case 9:
+ pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_9;
+ break;
+ case 10:
+ pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_10;
+ break;
+ default:
+ break;
+ };
+
+ if (ep.bus.parallel.flags & V4L2_MBUS_MASTER)
+ pcdev->platform_flags |= PXA_CAMERA_MASTER;
+ if (ep.bus.parallel.flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ pcdev->platform_flags |= PXA_CAMERA_HSP;
+ if (ep.bus.parallel.flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ pcdev->platform_flags |= PXA_CAMERA_VSP;
+ if (ep.bus.parallel.flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pcdev->platform_flags |= PXA_CAMERA_PCLK_EN | PXA_CAMERA_PCP;
+ if (ep.bus.parallel.flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
+ pcdev->platform_flags |= PXA_CAMERA_PCLK_EN;
+
+out:
+ of_node_put(np);
+
+ return err;
+}
+
static int pxa_camera_probe(struct platform_device *pdev)
{
struct pxa_camera_dev *pcdev;
@@ -1676,7 +1739,15 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev->res = res;
pcdev->pdata = pdev->dev.platform_data;
- pcdev->platform_flags = pcdev->pdata->flags;
+ if (&pdev->dev.of_node && !pcdev->pdata) {
+ err = pxa_camera_pdata_from_dt(&pdev->dev, pcdev);
+ } else {
+ pcdev->platform_flags = pcdev->pdata->flags;
+ pcdev->mclk = pcdev->pdata->mclk_10khz * 1;
+ }
+ if (err < 0)
+ return err;
+
if (!(pcdev->platform_flags & (PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_DATAWIDTH_9 | PXA_CAMERA_DATAWIDTH_10))) {
/*
@@ -1693,7 +1764,6 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev->width_flags |= 1 << 8;
if (pcdev->platform_flags & PXA_CAMERA_DATAWIDTH_10)
pcdev->width_flags |= 1 << 9;
- pcdev->mclk = pcdev->pdata->mclk_10khz * 1;
if (!pcdev->mclk) {
dev_warn(&pdev->dev,
"mclk == 0! Please, fix your platform data. "
@@ -1799,10 +1869,17 @@ static const struct dev_pm_ops pxa_camera_pm = {
.resume = pxa_camera_resume,
};
+static const struct of_device_id pxa_camera_of_match[] = {
+ { .compatible = "marvell,pxa270-qci", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pxa_camera_of_match);
+
static struct platform_driver pxa_camera_driver = {
.driver = {
.name = PXA_CAM_DRV_NAME,
.pm = &pxa_camera_pm,
+ .of_match_table = of_match_ptr(pxa_camera_of_match),
},
.probe
Re: [PATCH v3 1/2] media: soc_camera: pxa_camera device-tree support
Hi Robert,
Thanks for an updated patch. One question:
On Sun, 29 Jun 2014, Robert Jarzmik wrote:
> Add device-tree support to pxa_camera host driver.
>
> Signed-off-by: Robert Jarzmik
>
> ---
> Since V1: Mark's review
> - tmp u32 to long conversion for clock rate
> - use device-tree clock binding for mclk output clock
> - wildcard pxa27x becomes pxa270
> ---
> drivers/media/platform/soc_camera/pxa_camera.c | 80
> +-
> 1 file changed, 78 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
> b/drivers/media/platform/soc_camera/pxa_camera.c
> index d4df305..e76c2ab 100644
> --- a/drivers/media/platform/soc_camera/pxa_camera.c
> +++ b/drivers/media/platform/soc_camera/pxa_camera.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -1650,6 +1651,67 @@ static struct soc_camera_host_ops
> pxa_soc_camera_host_ops = {
> .set_bus_param = pxa_camera_set_bus_param,
> };
>
> +static int pxa_camera_pdata_from_dt(struct device *dev,
> + struct pxa_camera_dev *pcdev)
> +{
> + int err = 0;
> + u32 mclk_rate = 0;
> + struct device_node *np = dev->of_node;
> + struct v4l2_of_endpoint ep;
> +
> + err = of_property_read_u32(np, "clock-frequency",
> +&mclk_rate);
> + if (!err) {
> + pcdev->platform_flags |= PXA_CAMERA_MCLK_EN;
> + pcdev->mclk = mclk_rate;
> + }
> +
> + np = of_graph_get_next_endpoint(np, NULL);
Isn't an of_node_put() required after this?
Thanks
Guennadi
> + if (!np) {
> + dev_err(dev, "could not find endpoint\n");
> + return -EINVAL;
> + }
> +
> + err = v4l2_of_parse_endpoint(np, &ep);
> + if (err) {
> + dev_err(dev, "could not parse endpoint\n");
> + return err;
> + }
> +
> + switch (ep.bus.parallel.bus_width) {
> + case 4:
> + pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_4;
> + break;
> + case 5:
> + pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_5;
> + break;
> + case 8:
> + pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_8;
> + break;
> + case 9:
> + pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_9;
> + break;
> + case 10:
> + pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_10;
> + break;
> + default:
> + break;
> + };
> +
> + if (ep.bus.parallel.flags & V4L2_MBUS_MASTER)
> + pcdev->platform_flags |= PXA_CAMERA_MASTER;
> + if (ep.bus.parallel.flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> + pcdev->platform_flags |= PXA_CAMERA_HSP;
> + if (ep.bus.parallel.flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
> + pcdev->platform_flags |= PXA_CAMERA_VSP;
> + if (ep.bus.parallel.flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
> + pcdev->platform_flags |= PXA_CAMERA_PCLK_EN | PXA_CAMERA_PCP;
> + if (ep.bus.parallel.flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
> + pcdev->platform_flags |= PXA_CAMERA_PCLK_EN;
> +
> + return 0;
> +}
> +
> static int pxa_camera_probe(struct platform_device *pdev)
> {
> struct pxa_camera_dev *pcdev;
> @@ -1676,7 +1738,15 @@ static int pxa_camera_probe(struct platform_device
> *pdev)
> pcdev->res = res;
>
> pcdev->pdata = pdev->dev.platform_data;
> - pcdev->platform_flags = pcdev->pdata->flags;
> + if (&pdev->dev.of_node && !pcdev->pdata) {
> + err = pxa_camera_pdata_from_dt(&pdev->dev, pcdev);
> + } else {
> + pcdev->platform_flags = pcdev->pdata->flags;
> + pcdev->mclk = pcdev->pdata->mclk_10khz * 1;
> + }
> + if (err < 0)
> + return err;
> +
> if (!(pcdev->platform_flags & (PXA_CAMERA_DATAWIDTH_8 |
> PXA_CAMERA_DATAWIDTH_9 | PXA_CAMERA_DATAWIDTH_10))) {
> /*
> @@ -1693,7 +1763,6 @@ static int pxa_camera_probe(struct platform_device
> *pdev)
> pcdev->width_flags |= 1 << 8;
> if (pcdev->platform_flags & PXA_CAMERA_DATAWIDTH_10)
> pcdev->width_flags |= 1 << 9;
> - pcdev->mclk = pcdev->pdata->mclk_10khz * 1;
> if (!pcdev->mclk) {
> dev_warn(&pdev->dev,
>"mclk == 0! Please, fix your platform data. "
> @@ -1799,10 +1868,17 @@ static const struct dev_pm_ops pxa_camera_pm = {
> .resume = pxa_camera_resume,
> };
>
> +static const struct of_device_id pxa_camera_of_match[] = {
> + { .compatible = "marvell,pxa270-qci", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, pxa_camera_of_match);
> +
> static struct platform_driver pxa_camera_driver = {
> .driver = {
> .name = PXA_CAM_DRV_NAME,
> .pm = &pxa_camera_pm,
> + .of_match_table = of_match_ptr(px
[PATCH v4 1/2] dmaengine: add device tree binding documentation for the nbpfaxi driver
The nbpfaxi dmaengine driver doesn't define any new bindings, it only
uses standard dmaengine bindings and defines 3 flags for the 3rd parameter
of the "dmas" property.
Signed-off-by: Guennadi Liakhovetski
Acked-by: Arnd Bergmann
---
v4: no change, added Arnd's ack - thanks!
Documentation/devicetree/bindings/dma/nbpfaxi.txt | 61 +++
include/dt-bindings/dma/nbpfaxi.h | 20
2 files changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/nbpfaxi.txt
create mode 100644 include/dt-bindings/dma/nbpfaxi.h
diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt
b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
new file mode 100644
index 000..d5e2522
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
@@ -0,0 +1,61 @@
+* Renesas "Type-AXI" NBPFAXI* DMA controllers
+
+* DMA controller
+
+Required properties
+
+- compatible: must be one of
+ "renesas,nbpfaxi64dmac1b4"
+ "renesas,nbpfaxi64dmac1b8"
+ "renesas,nbpfaxi64dmac1b16"
+ "renesas,nbpfaxi64dmac4b4"
+ "renesas,nbpfaxi64dmac4b8"
+ "renesas,nbpfaxi64dmac4b16"
+ "renesas,nbpfaxi64dmac8b4"
+ "renesas,nbpfaxi64dmac8b8"
+ "renesas,nbpfaxi64dmac8b16"
+- #dma-cells: must be 2: the first integer is a terminal number, to which this
+ slave is connected, the second one is flags. Flags is a bitmask
+ with the following bits defined:
+
+#define NBPF_SLAVE_RQ_HIGH 1
+#define NBPF_SLAVE_RQ_LOW 2
+#define NBPF_SLAVE_RQ_LEVEL4
+
+Optional properties:
+
+You can use dma-channels and dma-requests as described in dma.txt, although
they
+won't be used, this information is derived from the compatibility string.
+
+Example:
+
+ dma: dma-controller@4800 {
+ compatible = "renesas,nbpfaxi64dmac8b4";
+ reg = <0x4800 0x400>;
+ interrupts = <0 12 0x4
+ 0 13 0x4
+ 0 14 0x4
+ 0 15 0x4
+ 0 16 0x4
+ 0 17 0x4
+ 0 18 0x4
+ 0 19 0x4>;
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ dma-requests = <8>;
+ };
+
+* DMA client
+
+Required properties:
+
+dmas and dma-names are required, as described in dma.txt.
+
+Example:
+
+#include
+
+...
+ dmas = <&dma 0 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)
+ &dma 1 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)>;
+ dma-names = "rx", "tx";
diff --git a/include/dt-bindings/dma/nbpfaxi.h
b/include/dt-bindings/dma/nbpfaxi.h
new file mode 100644
index 000..c1a5b9e
--- /dev/null
+++ b/include/dt-bindings/dma/nbpfaxi.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef DT_BINDINGS_NBPFAXI_H
+#define DT_BINDINGS_NBPFAXI_H
+
+/**
+ * Use "#dma-cells = <2>;" with the second integer defining slave DMA flags:
+ */
+#define NBPF_SLAVE_RQ_HIGH 1
+#define NBPF_SLAVE_RQ_LOW 2
+#define NBPF_SLAVE_RQ_LEVEL4
+
+#endif
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
This patch adds a driver for NBPF DMAC IP cores from Renesas, designed for the AMBA AXI bus. Signed-off-by: Guennadi Liakhovetski --- v4: 1. comment from Arnd: use dma_get_any_slave_channel() instead of dma_request_channel() 2. fixed 64-bit compile printk format warnings drivers/dma/Kconfig |6 + drivers/dma/Makefile |1 + drivers/dma/nbpfaxi.c | 1511 + 3 files changed, 1518 insertions(+) create mode 100644 drivers/dma/nbpfaxi.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 8f6afbf..d63a4d8 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -393,6 +393,12 @@ config XILINX_VDMA channels, Memory Mapped to Stream (MM2S) and Stream to Memory Mapped (S2MM) for the data transfers. +config NBPFAXI_DMA + tristate "Renesas Type-AXI NBPF DMA support" + select DMA_ENGINE + help + Support for "Type-AXI" NBPF DMA IPs from Renesas + config DMA_ENGINE bool diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index ec1a051..3002f4b 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -48,3 +48,4 @@ obj-$(CONFIG_FSL_EDMA) += fsl-edma.o obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o obj-y += xilinx/ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o +obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c new file mode 100644 index 000..77c5a89 --- /dev/null +++ b/drivers/dma/nbpfaxi.c @@ -0,0 +1,1511 @@ +/* + * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd. + * Author: Guennadi Liakhovetski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "dmaengine.h" + +#define NBPF_REG_CHAN_OFFSET 0 +#define NBPF_REG_CHAN_SIZE 0x40 + +/* Channel Current Transaction Byte register */ +#define NBPF_CHAN_CUR_TR_BYTE 0x20 + +/* Channel Status register */ +#define NBPF_CHAN_STAT 0x24 +#define NBPF_CHAN_STAT_EN 1 +#define NBPF_CHAN_STAT_TACT4 +#define NBPF_CHAN_STAT_ERR 0x10 +#define NBPF_CHAN_STAT_END 0x20 +#define NBPF_CHAN_STAT_TC 0x40 +#define NBPF_CHAN_STAT_DER 0x400 + +/* Channel Control register */ +#define NBPF_CHAN_CTRL 0x28 +#define NBPF_CHAN_CTRL_SETEN 1 +#define NBPF_CHAN_CTRL_CLREN 2 +#define NBPF_CHAN_CTRL_STG 4 +#define NBPF_CHAN_CTRL_SWRST 8 +#define NBPF_CHAN_CTRL_CLRRQ 0x10 +#define NBPF_CHAN_CTRL_CLREND 0x20 +#define NBPF_CHAN_CTRL_CLRTC 0x40 +#define NBPF_CHAN_CTRL_SETSUS 0x100 +#define NBPF_CHAN_CTRL_CLRSUS 0x200 + +/* Channel Configuration register */ +#define NBPF_CHAN_CFG 0x2c +#define NBPF_CHAN_CFG_SEL 7 /* terminal SELect: 0..7 */ +#define NBPF_CHAN_CFG_REQD 8 /* REQuest Direction: DMAREQ is 0: input, 1: output */ +#define NBPF_CHAN_CFG_LOEN 0x10/* LOw ENable: low DMA request line is: 0: inactive, 1: active */ +#define NBPF_CHAN_CFG_HIEN 0x20/* HIgh ENable: high DMA request line is: 0: inactive, 1: active */ +#define NBPF_CHAN_CFG_LVL 0x40/* LeVeL: DMA request line is sensed as 0: edge, 1: level */ +#define NBPF_CHAN_CFG_AM 0x700 /* ACK Mode: 0: Pulse mode, 1: Level mode, b'1x: Bus Cycle */ +#define NBPF_CHAN_CFG_SDS 0xf000 /* Source Data Size: 0: 8 bits,... , 7: 1024 bits */ +#define NBPF_CHAN_CFG_DDS 0xf /* Destination Data Size: as above */ +#define NBPF_CHAN_CFG_SAD 0x10/* Source ADdress counting: 0: increment, 1: fixed */ +#define NBPF_CHAN_CFG_DAD 0x20/* Destination ADdress counting: 0: increment, 1: fixed */ +#define NBPF_CHAN_CFG_TM 0x40/* Transfer Mode: 0: single, 1: block TM */ +#define NBPF_CHAN_CFG_DEM 0x100 /* DMAEND interrupt Mask */ +#define NBPF_CHAN_CFG_TCM 0x200 /* DMATCO interrupt Mask */ +#define NBPF_CHAN_CFG_SBE 0x800 /* Sweep Buffer Enable */ +#define NBPF_CHAN_CFG_RSEL 0x1000 /* RM: Register Set sELect */ +#define NBPF_CHAN_CFG_RSW 0x2000 /* RM: Register Select sWitch */ +#define NBPF_CHAN_CFG_REN 0x4000 /* RM: Register Set Enable */ +#define NBPF_CHAN_CFG_DMS 0x8000 /* 0: register mode (RM), 1: link mode (LM) */ + +#define NBPF_CHAN_NXLA 0x38 +#define NBPF_CHAN_CRLA 0x3c + +/* Link Header field */ +#define NBPF_HEADER_LV 1 +#define NBPF_HEADER_LE 2 +#define NBPF_HEADER_WBD4 +#define NBPF_HEADER_DIM8 + +#define NBPF_CTRL 0x300 +#define NBPF_CTRL_PR 1 /* 0: fixed priority, 1: round robin */ +#define NBPF_CTRL_LVINT2
Re: [REQUEST] DT patch not reviewed for 2 months+
Hi Arnd, Thanks for the review! On Mon, 14 Jul 2014, Arnd Bergmann wrote: > On Sunday 13 July 2014 22:00:11 Guennadi Liakhovetski wrote: > > Hi all, > > > > On 10th of May I submitted 2 patches > > > > http://thread.gmane.org/gmane.linux.drivers.devicetree/73577 > > > > of which 1 adds documentation for DT bindings for a dmaengine driver. The > > driver doesn't add any new bindings, only standard bindings are used and > > the respective generic document is referenced in the patch. This makes me > > think, that a review of that patch should really be a matter of a couple > > of minutes. Unfortunateky this still hasn't happened. If the patch had > > been reviewed promptly, it still could make it into 3.16. We're at > > 3.16-rc4 in the meantime. Have I done anything wrong in the patch > > submission procedure? What do I have to do to get this patch reviewed soon > > to get it in 3.17? > > The fallback for device drivers is that if nobody finds the time to review > the binding, the subsystem maintainer can just take it anyway. > > I hadn't seen this driver so far, but looked at it now. The binding looks > good to me, so feel free to resend it with > > Acked-by: Arnd Bergmann > > The driver also looks good, but there is one part that can now be > done more efficiently: > > + dma_cap_zero(mask); > + dma_cap_set(DMA_SLAVE, mask); > + > + dchan = dma_request_channel(mask, nbpf_dma_filter, ofdma->of_node); > + if (!dchan) > + return NULL; > > > Here you can just call dma_get_any_slave_channel() and remove the filter > function. The way you do it is also correct, but we're trying to get > away from that, as it just adds pointless overhead. Ok, I'll have a look at it and make sure to send a rebased update asap (that is hopefully next weekend...)! Thanks Guennadi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REQUEST] DT patch not reviewed for 2 months+
Hi all, On 10th of May I submitted 2 patches http://thread.gmane.org/gmane.linux.drivers.devicetree/73577 of which 1 adds documentation for DT bindings for a dmaengine driver. The driver doesn't add any new bindings, only standard bindings are used and the respective generic document is referenced in the patch. This makes me think, that a review of that patch should really be a matter of a couple of minutes. Unfortunateky this still hasn't happened. If the patch had been reviewed promptly, it still could make it into 3.16. We're at 3.16-rc4 in the meantime. Have I done anything wrong in the patch submission procedure? What do I have to do to get this patch reviewed soon to get it in 3.17? Thanks Guennadi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] media: soc_camera: pxa_camera device-tree support
On Sun, 15 Jun 2014, Robert Jarzmik wrote:
> Add device-tree support to pxa_camera host driver.
>
> Signed-off-by: Robert Jarzmik
> ---
> drivers/media/platform/soc_camera/pxa_camera.c | 80
> ++
> 1 file changed, 80 insertions(+)
>
> diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
> b/drivers/media/platform/soc_camera/pxa_camera.c
> index d4df305..e48d821 100644
> --- a/drivers/media/platform/soc_camera/pxa_camera.c
> +++ b/drivers/media/platform/soc_camera/pxa_camera.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -1650,9 +1651,74 @@ static struct soc_camera_host_ops
> pxa_soc_camera_host_ops = {
> .set_bus_param = pxa_camera_set_bus_param,
> };
>
> +static const struct of_device_id pxacamera_dt_ids[] = {
> + { .compatible = "mrvl,pxa_camera", },
as Documentation/devicetree/bindings/vendor-prefixes.txt defines, it
should be "marvell."
> + { }
> +};
> +
> +static int pxa_camera_pdata_from_dt(struct device *dev,
> + struct pxacamera_platform_data *pdata)
> +{
> + int err = 0;
> + struct device_node *np = dev->of_node;
> + struct v4l2_of_endpoint ep;
> +
> + dev_info(dev, "RJK: %s()\n", __func__);
I have nothing against attributing work to respective authors, but I don't
think this makes a lot of sense in the long run in the above form :) Once
you've verified that your binding is working and this function is working,
either remove this or make it more informative - maybe at the end of this
function, also listing a couple of important parameters, that you obtained
from DT.
> + err = of_property_read_u32(np, "mclk_10khz",
> +(u32 *)&pdata->mclk_10khz);
I think we'll be frowned upon for this :) PXA270 doesn't support CCF, does
it? Even if it doesn't we probably should use the standard
"clock-frequency" property in any case. Actually, I missed to mention on
this in my comments to your bindings documentation.
> + if (!err)
> + pdata->flags |= PXA_CAMERA_MCLK_EN;
> +
> + np = of_graph_get_next_endpoint(np, NULL);
> + if (!np) {
> + dev_err(dev, "could not find endpoint\n");
> + return -EINVAL;
> + }
> +
> + err = v4l2_of_parse_endpoint(np, &ep);
> + if (err) {
> + dev_err(dev, "could not parse endpoint\n");
> + return err;
> + }
> +
> + switch (ep.bus.parallel.bus_width) {
> + case 4:
> + pdata->flags |= PXA_CAMERA_DATAWIDTH_4;
> + break;
> + case 5:
> + pdata->flags |= PXA_CAMERA_DATAWIDTH_5;
> + break;
> + case 8:
> + pdata->flags |= PXA_CAMERA_DATAWIDTH_8;
> + break;
> + case 9:
> + pdata->flags |= PXA_CAMERA_DATAWIDTH_9;
> + break;
> + case 10:
> + pdata->flags |= PXA_CAMERA_DATAWIDTH_10;
> + break;
> + default:
> + break;
> + };
> +
> + if (ep.bus.parallel.flags & V4L2_MBUS_MASTER)
> + pdata->flags |= PXA_CAMERA_MASTER;
> + if (ep.bus.parallel.flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> + pdata->flags |= PXA_CAMERA_HSP;
> + if (ep.bus.parallel.flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
> + pdata->flags |= PXA_CAMERA_VSP;
> + if (ep.bus.parallel.flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
> + pdata->flags |= PXA_CAMERA_PCLK_EN | PXA_CAMERA_PCP;
> + if (ep.bus.parallel.flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
> + pdata->flags |= PXA_CAMERA_PCLK_EN;
> +
> + return 0;
> +}
> +
> static int pxa_camera_probe(struct platform_device *pdev)
> {
> struct pxa_camera_dev *pcdev;
> + struct pxacamera_platform_data pdata_dt;
> struct resource *res;
> void __iomem *base;
> int irq;
> @@ -1676,6 +1742,13 @@ static int pxa_camera_probe(struct platform_device
> *pdev)
> pcdev->res = res;
>
> pcdev->pdata = pdev->dev.platform_data;
> + if (&pdev->dev.of_node && !pcdev->pdata)
> + err = pxa_camera_pdata_from_dt(&pdev->dev, &pdata_dt);
> + if (err < 0)
> + return err;
> + else
> + pcdev->pdata = &pdata_dt;
This will Oops, if someone decides to dereference pcdev->pdata outside of
this function. pdata_dt is on stack and you store a pointer to it in your
device data... But since ->pdata doesn't seem to be used anywhere else in
this driver, maybe remove that struct member completely?
> +
> pcdev->platform_flags = pcdev->pdata->flags;
> if (!(pcdev->platform_flags & (PXA_CAMERA_DATAWIDTH_8 |
> PXA_CAMERA_DATAWIDTH_9 | PXA_CAMERA_DATAWIDTH_10))) {
> @@ -1799,10 +1872,17 @@ static const struct dev_pm_ops pxa_camera_pm = {
> .resume = pxa_camera_resume,
> };
>
> +static const struct of_device_id pxa_camera_of_match[] = {
> + { .compatible = "mrvl,pxa_camera", },
Ano
Re: [PATCH 1/2] media: soc_camera: pxa_camera documentation device-tree support
On Sun, 15 Jun 2014, Robert Jarzmik wrote:
> Add documentation for pxa_camera host interface.
As mentioned in another comment: this is driver DT bindings description,
not interface documentation.
Thanks
Guennadi
>
> Signed-off-by: Robert Jarzmik
> ---
> .../devicetree/bindings/media/pxa-camera.txt | 40
> ++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/pxa-camera.txt
>
> diff --git a/Documentation/devicetree/bindings/media/pxa-camera.txt
> b/Documentation/devicetree/bindings/media/pxa-camera.txt
> new file mode 100644
> index 000..568b63b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/pxa-camera.txt
> @@ -0,0 +1,40 @@
> +Marvell PXA camera host interface
> +
> +Required properties:
> + - compatible: Should be "mrvl,pxa_camera"
> + - reg: register base and size
> + - interrupts: the interrupt number
> + - any required generic properties defined in video-interfaces.txt
> +
> +Optional properties:
> + - mclk_10khz: host interface is driving MCLK, and MCLK rate is mclk_10khz *
> + 1 Hz.
> +
> +Example:
> +
> + pxa_camera: pxa_camera@5000 {
> + compatible = "mrvl,pxa_camera";
> + reg = <0x5000 0x1000>;
> + interrupts = <33>;
> +
> + clocks = <&pxa2xx_clks 24>;
> + clock-names = "camera";
> + status = "okay";
> +
> + mclk_10khz = <5000>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Parallel bus endpoint */
> + qci: endpoint@0 {
> + reg = <0>; /* Local endpoint # */
> + remote-endpoint = <&mt9m111_1>;
> + bus-width = <8>;/* Used data lines */
> + hsync-active = <0>; /* Active low */
> + vsync-active = <0>; /* Active low */
> + pclk-sample = <1>; /* Rising */
> + };
> + };
> + };
> --
> 2.0.0.rc2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] media: mt9m111: add device-tree documentation
Hi Robert,
On Sun, 15 Jun 2014, Robert Jarzmik wrote:
> Add documentation for the Micron mt9m111 image sensor.
A nitpick: this isn't documentation for the sensor:) This is driver DT
bindings' documentation.
Thanks
Guennadi
>
> Signed-off-by: Robert Jarzmik
> ---
> .../devicetree/bindings/media/i2c/mt9m111.txt | 28
> ++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9m111.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/mt9m111.txt
> b/Documentation/devicetree/bindings/media/i2c/mt9m111.txt
> new file mode 100644
> index 000..ed5a334
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/mt9m111.txt
> @@ -0,0 +1,28 @@
> +Micron 1.3Mp CMOS Digital Image Sensor
> +
> +The Micron MT9M111 is a CMOS active pixel digital image sensor with an active
> +array size of 1280H x 1024V. It is programmable through a simple two-wire
> serial
> +interface.
> +
> +Required Properties:
> +- compatible: value should be "micron,mt9m111"
> +
> +For further reading on port node refer to
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> + i2c_master {
> + mt9m111@5d {
> + compatible = "micron,mt9m111";
> + reg = <0x5d>;
> +
> + remote = <&pxa_camera>;
> + port {
> + mt9m111_1: endpoint {
> + bus-width = <8>;
> + remote-endpoint = <&pxa_camera>;
> + };
> + };
> + };
> + };
> --
> 2.0.0.rc2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: mt9m111: add device-tree suppport
Hi Robert,
Thanks for the patch.
On Sun, 15 Jun 2014, Robert Jarzmik wrote:
> Add device-tree support for mt9m111 camera sensor.
>
> Signed-off-by: Robert Jarzmik
> ---
> drivers/media/i2c/soc_camera/mt9m111.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/media/i2c/soc_camera/mt9m111.c
> b/drivers/media/i2c/soc_camera/mt9m111.c
> index ccf5940..7d283ea 100644
> --- a/drivers/media/i2c/soc_camera/mt9m111.c
> +++ b/drivers/media/i2c/soc_camera/mt9m111.c
> @@ -923,6 +923,12 @@ done:
> return ret;
> }
>
> +static int of_get_mt9m111_platform_data(struct device *dev,
> + struct soc_camera_subdev_desc *desc)
> +{
> + return 0;
> +}
Why do you need this function? I would just drop it.
> +
> static int mt9m111_probe(struct i2c_client *client,
>const struct i2c_device_id *did)
> {
> @@ -931,6 +937,15 @@ static int mt9m111_probe(struct i2c_client *client,
> struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> int ret;
>
> + if (client->dev.of_node) {
> + ssdd = devm_kzalloc(&client->dev, sizeof(*ssdd), GFP_KERNEL);
> + if (!ssdd)
> + return -ENOMEM;
> + client->dev.platform_data = ssdd;
> + ret = of_get_mt9m111_platform_data(&client->dev, ssdd);
> + if (ret < 0)
> + return ret;
> + }
> if (!ssdd) {
> dev_err(&client->dev, "mt9m111: driver needs platform data\n");
> return -EINVAL;
> @@ -1015,6 +1030,11 @@ static int mt9m111_remove(struct i2c_client *client)
>
> return 0;
> }
> +static const struct of_device_id mt9m111_of_match[] = {
> + { .compatible = "micron,mt9m111", },
Not a flaw in this patch, but someone might want to add "micron" to
Documentation/devicetree/bindings/vendor-prefixes.txt
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mt9m111_of_match);
>
> static const struct i2c_device_id mt9m111_id[] = {
> { "mt9m111", 0 },
> @@ -1025,6 +1045,7 @@ MODULE_DEVICE_TABLE(i2c, mt9m111_id);
> static struct i2c_driver mt9m111_i2c_driver = {
> .driver = {
> .name = "mt9m111",
> + .of_match_table = of_match_ptr(mt9m111_of_match),
> },
> .probe = mt9m111_probe,
> .remove = mt9m111_remove,
> --
> 2.0.0.rc2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
On Wed, 11 Jun 2014, Chris Ball wrote: > Hi Guennadi, > > On Sat, May 31 2014, Guennadi Liakhovetski wrote: > > This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller > > in both PIO and DMA modes. > > > > Signed-off-by: Guennadi Liakhovetski > > --- > > > > v4: replaced several numerical values with macros > > Please send fixes for the compiler warnings, potential-null mrq, Sure, it's on my todo for Saturday, is this ok? > and > perhaps add an ARCH_ dependency to stop this building on x86_64. Is there a specific reason to only build it on ARM? It can be used with various architectures, but we can make it depend on COMPILE_TEST (or whatever that option is called), but I'm not sure that's required. Thanks Guennadi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
in both PIO and DMA modes.
Signed-off-by: Guennadi Liakhovetski
---
v4: replaced several numerical values with macros
.../devicetree/bindings/mmc/usdhi6rol0.txt | 33 +
drivers/mmc/host/Kconfig |6 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/usdhi6rol0.c | 1847
4 files changed, 1887 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
create mode 100644 drivers/mmc/host/usdhi6rol0.c
diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
new file mode 100644
index 000..8babdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
@@ -0,0 +1,33 @@
+* Renesas usdhi6rol0 SD/SDIO host controller
+
+Required properties:
+
+- compatible: must be
+ "renesas,usdhi6rol0"
+- interrupts: 3 interrupts, named "card detect", "data" and "SDIO" must be
+ specified
+- clocks: a clock binding for the IMCLK input
+
+Optional properties:
+
+- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply:a phandle of a regulator, supplying VccQ to the card
+
+Additionally any standard mmc bindings from mmc.txt can be used.
+
+Example:
+
+sd0: sd@ab00 {
+ compatible = "renesas,usdhi6rol0";
+ reg = <0xab00 0x200>;
+ interrupts = <0 23 0x4
+ 0 24 0x4
+ 0 25 0x4>;
+ interrupt-names = "card detect", "data", "SDIO";
+ bus-width = <4>;
+ max-frequency = <5000>;
+ cap-power-off-card;
+ clocks = <&imclk>;
+ vmmc-supply = <&vcc_sd0>;
+ vqmmc-supply = <&vccq_sd0>;
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index b675882..924f973 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -688,6 +688,12 @@ config MMC_WMT
To compile this driver as a module, choose M here: the
module will be called wmt-sdmmc.
+config MMC_USDHI6ROL0
+ tristate "Renesas USDHI6ROL0 SD/SDIO Host Controller support"
+ help
+ This selects support for the Renesas USDHI6ROL0 SD/SDIO
+ Host Controller
+
config MMC_REALTEK_PCI
tristate "Realtek PCI-E SD/MMC Card Interface Driver"
depends on MFD_RTSX_PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 3eb48b656..793a0d6 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
+obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o
obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
new file mode 100644
index 000..eb2bbbe
--- /dev/null
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -0,0 +1,1847 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define USDHI6_SD_CMD 0x
+#define USDHI6_SD_PORT_SEL 0x0004
+#define USDHI6_SD_ARG 0x0008
+#define USDHI6_SD_STOP 0x0010
+#define USDHI6_SD_SECCNT 0x0014
+#define USDHI6_SD_RSP100x0018
+#define USDHI6_SD_RSP320x0020
+#define USDHI6_SD_RSP540x0028
+#define USDHI6_SD_RSP760x0030
+#define USDHI6_SD_INFO10x0038
+#define USDHI6_SD_INFO20x003c
+#define USDHI6_SD_INFO1_MASK 0x0040
+#define USDHI6_SD_INFO2_MASK 0x0044
+#define USDHI6_SD_CLK_CTRL 0x0048
+#define USDHI6_SD_SIZE 0x004c
+#define USDHI6_SD_OPTION 0x0050
+#define USDHI6_SD_ERR_STS1 0x0058
+#define USDHI6_SD_ERR_STS2 0x005c
+#define USDHI6_SD_BUF0 0x0060
+#define USDHI6_SDIO_MODE 0x0068
+#define USDHI6_SDIO_INFO1 0x006c
+#define USDHI6_SDIO_INFO1_MASK 0x0070
+#define USDHI6_CC_EXT_MODE 0x01b0
+#define USDHI6_SOFT_RST0x01c0
+#define USDHI6_VERSION 0x01c4
+#define USDHI6_HOST_MODE 0x01c8
+#define USDHI6_SDIF_MODE 0x01
Re: [PATCH v3 2/2] dmaengine: add device tree binding documentation for the nbpfaxi driver
Grant, Rob,
Could you, guys, have a look at this, please? No new bindings are added,
so, it should be a matter of 5 minutes looking over the patch. Would be a
pity if because of these 5 minutes a new driver gets delayed until the new
kernel version.
Thanks
Guennadi
On Sat, 10 May 2014, Guennadi Liakhovetski wrote:
> The nbpfaxi dmaengine driver doesn't define any new bindings, it only
> uses standard dmaengine bindings and defines 3 flags for the 3rd parameter
> of the "dmas" property.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> v3: split out from v2, no changes otherwise
>
> Documentation/devicetree/bindings/dma/nbpfaxi.txt | 61
> +++
> include/dt-bindings/dma/nbpfaxi.h | 20
> 2 files changed, 81 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/nbpfaxi.txt
> create mode 100644 include/dt-bindings/dma/nbpfaxi.h
>
> diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt
> b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
> new file mode 100644
> index 000..d5e2522
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
> @@ -0,0 +1,61 @@
> +* Renesas "Type-AXI" NBPFAXI* DMA controllers
> +
> +* DMA controller
> +
> +Required properties
> +
> +- compatible:must be one of
> + "renesas,nbpfaxi64dmac1b4"
> + "renesas,nbpfaxi64dmac1b8"
> + "renesas,nbpfaxi64dmac1b16"
> + "renesas,nbpfaxi64dmac4b4"
> + "renesas,nbpfaxi64dmac4b8"
> + "renesas,nbpfaxi64dmac4b16"
> + "renesas,nbpfaxi64dmac8b4"
> + "renesas,nbpfaxi64dmac8b8"
> + "renesas,nbpfaxi64dmac8b16"
> +- #dma-cells:must be 2: the first integer is a terminal number, to
> which this
> + slave is connected, the second one is flags. Flags is a bitmask
> + with the following bits defined:
> +
> +#define NBPF_SLAVE_RQ_HIGH 1
> +#define NBPF_SLAVE_RQ_LOW2
> +#define NBPF_SLAVE_RQ_LEVEL 4
> +
> +Optional properties:
> +
> +You can use dma-channels and dma-requests as described in dma.txt, although
> they
> +won't be used, this information is derived from the compatibility string.
> +
> +Example:
> +
> + dma: dma-controller@4800 {
> + compatible = "renesas,nbpfaxi64dmac8b4";
> + reg = <0x4800 0x400>;
> + interrupts = <0 12 0x4
> + 0 13 0x4
> + 0 14 0x4
> + 0 15 0x4
> + 0 16 0x4
> + 0 17 0x4
> + 0 18 0x4
> + 0 19 0x4>;
> + #dma-cells = <2>;
> + dma-channels = <8>;
> + dma-requests = <8>;
> + };
> +
> +* DMA client
> +
> +Required properties:
> +
> +dmas and dma-names are required, as described in dma.txt.
> +
> +Example:
> +
> +#include
> +
> +...
> + dmas = <&dma 0 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)
> + &dma 1 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)>;
> + dma-names = "rx", "tx";
> diff --git a/include/dt-bindings/dma/nbpfaxi.h
> b/include/dt-bindings/dma/nbpfaxi.h
> new file mode 100644
> index 000..c1a5b9e
> --- /dev/null
> +++ b/include/dt-bindings/dma/nbpfaxi.h
> @@ -0,0 +1,20 @@
> +/*
> + * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
> + * Author: Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef DT_BINDINGS_NBPFAXI_H
> +#define DT_BINDINGS_NBPFAXI_H
> +
> +/**
> + * Use "#dma-cells = <2>;" with the second integer defining slave DMA flags:
> + */
> +#define NBPF_SLAVE_RQ_HIGH 1
> +#define NBPF_SLAVE_RQ_LOW2
> +#define NBPF_SLAVE_RQ_LEVEL 4
> +
> +#endif
> --
> 2.0.0.rc0
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
Hi Chris,
What's the status of this patch? Would be great to get it in for 3.16.
Thanks
Guennadi
On Sat, 26 Apr 2014, Guennadi Liakhovetski wrote:
> This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
> in both PIO and DMA modes.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> v2: copyright and Sob email changed
>
> .../devicetree/bindings/mmc/usdhi6rol0.txt | 33 +
> drivers/mmc/host/Kconfig |6 +
> drivers/mmc/host/Makefile |1 +
> drivers/mmc/host/usdhi6rol0.c | 1834
>
> 4 files changed, 1874 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
> create mode 100644 drivers/mmc/host/usdhi6rol0.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
> b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
> new file mode 100644
> index 000..8babdaa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
> @@ -0,0 +1,33 @@
> +* Renesas usdhi6rol0 SD/SDIO host controller
> +
> +Required properties:
> +
> +- compatible:must be
> + "renesas,usdhi6rol0"
> +- interrupts:3 interrupts, named "card detect", "data" and "SDIO"
> must be
> + specified
> +- clocks:a clock binding for the IMCLK input
> +
> +Optional properties:
> +
> +- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
> +- vqmmc-supply: a phandle of a regulator, supplying VccQ to the card
> +
> +Additionally any standard mmc bindings from mmc.txt can be used.
> +
> +Example:
> +
> +sd0: sd@ab00 {
> + compatible = "renesas,usdhi6rol0";
> + reg = <0xab00 0x200>;
> + interrupts = <0 23 0x4
> + 0 24 0x4
> + 0 25 0x4>;
> + interrupt-names = "card detect", "data", "SDIO";
> + bus-width = <4>;
> + max-frequency = <5000>;
> + cap-power-off-card;
> + clocks = <&imclk>;
> + vmmc-supply = <&vcc_sd0>;
> + vqmmc-supply = <&vccq_sd0>;
> +};
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 8aaf8c1..a21d8b5 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -688,6 +688,12 @@ config MMC_WMT
> To compile this driver as a module, choose M here: the
> module will be called wmt-sdmmc.
>
> +config MMC_USDHI6ROL0
> + tristate "Renesas USDHI6ROL0 SD/SDIO Host Controller support"
> + help
> + This selects support for the Renesas USDHI6ROL0 SD/SDIO
> + Host Controller
> +
> config MMC_REALTEK_PCI
> tristate "Realtek PCI-E SD/MMC Card Interface Driver"
> depends on MFD_RTSX_PCI
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 0c8aa5e..28d1fa0 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740)+= jz4740_mmc.o
> obj-$(CONFIG_MMC_VUB300) += vub300.o
> obj-$(CONFIG_MMC_USHC) += ushc.o
> obj-$(CONFIG_MMC_WMT)+= wmt-sdmmc.o
> +obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o
>
> obj-$(CONFIG_MMC_REALTEK_PCI)+= rtsx_pci_sdmmc.o
>
> diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
> new file mode 100644
> index 000..261b245
> --- /dev/null
> +++ b/drivers/mmc/host/usdhi6rol0.c
> @@ -0,0 +1,1834 @@
> +/*
> + * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
> + * Author: Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define USDHI6_SD_CMD0x
> +#define USDHI6_SD_PORT_SEL 0x0004
> +#define USDHI6_SD_ARG0x0008
> +#define USDHI6_SD_STOP 0x0010
> +#define USDHI6_SD_SECCNT 0x0014
> +#define USDHI6_SD_RSP10 0x0018
> +#define USDHI6_SD_RSP32 0x0020
> +#define USDHI6_SD_RSP54 0x0028
> +#define USDHI6_SD_RSP76 0x0030
Re: [PATCH v2] DMA: add a driver for AMBA AXI NBPF DMAC IP cores
Hi Vinod,
As you've seen, I've submitted a v3 of this patch with all your comments
addressed - except one - macros vs. numbers. Would that version be
acceptable or would you like a v4? Also see a couple of comments below.
On Wed, 21 May 2014, Vinod Koul wrote:
> On Sat, May 10, 2014 at 11:15:28AM +0200, Guennadi Liakhovetski wrote:
> > Hi Vinod,
> >
> > Thanks for a review.
> >
> > On Wed, 7 May 2014, Vinod Koul wrote:
> >
> > > On Sat, Apr 26, 2014 at 02:03:44PM +0200, Guennadi Liakhovetski wrote:
> > > > This patch adds a driver for NBPF DMAC IP cores from Renesas, designed
> > > > for
> > > > the AMBA AXI bus.
> > > >
> > >
> > > > diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt
> > > > b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
> > > > new file mode 100644
> > > > index 000..d5e2522
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
[snip]
> > > Pls split the DT bindings to seprate patch. This part needs ack from DT
> > > folks
> >
> > I thaught it would be preferable for both to go into the tree
> > simultaneously, i.e. as a single patch, they can review and ack this patch
> > too, but ok, can do, np.
> That helps in getting that part acked by DT folks and track independent of DMA
> changes. Ofocurse both will be applied togther or DT first :)
Done. As for applying after the DT part is in - can it also not be helped
by the fact, that I'm not adding any own bindings, only using standard
dmaengine ones?
> > > > +static size_t nbpf_xfer_size(struct nbpf_device *nbpf,
> > > > +enum dma_slave_buswidth width, u32 burst)
> > > > +{
> > > > + size_t size;
> > > > +
> > > > + if (!burst)
> > > > + burst = 1;
> > > > +
> > > > + switch (width) {
> > > > + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> > > > + size = 8 * burst;
> > > > + break;
> > > > + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> > > > + size = 4 * burst;
> > > > + break;
> > > > + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> > > > + size = 2 * burst;
> > > why not
> > > size = width * burst;
> > > for all these three cases?
> >
> > because width is an enum, that "accidentally" coincides with the
> > respective numerical value. I find this confusing - if it's an enum, you
> > shouldn't use it in calculations. If it's a numerical value, just use it
> > explicitly, but mixing both...
> ah, i dont agree with the reasoning. We have fair examples of using enums for
> these calculations to covert dmaengine values to driver type. This is juts a
> conversion and saves code space and simplfies the routine...
I'm fine with using the width for calculations, but then
DMA_SLAVE_BUSWIDTH_*_BYTES should be killed! Looking through grep results,
personally I would find
.src_info.data_width = 1,
in drivers/dma/ste_dma40.c at least as understandable as the present
.src_info.data_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
or even more. And if someone doesn't find this clear enough, you can
always add comments. Then all calculations are jastified, including those,
using the BIT() macro.
[snip]
> > > > +static enum dma_status nbpf_tx_status(struct dma_chan *dchan,
> > > > + dma_cookie_t cookie, struct dma_tx_state *state)
> > > > +{
> > > > + struct nbpf_channel *chan = nbpf_to_chan(dchan);
> > > > + enum dma_status status = dma_cookie_status(dchan, cookie,
> > > > state);
> > > > + dma_cookie_t running = chan->running ?
> > > > chan->running->async_tx.cookie : -EINVAL;
> > > > +
> > > > + if (chan->paused)
> > > > + status = DMA_PAUSED;
> > > > +
> > > > + /* Note: we cannot return residues for old cookies */
> > > ??? If cookie is completed then reside is 0. So how is this comment valid?
> >
> > For completed ones it's 0, sure.
> so what does comment mean here about "old" cookies?
Think about the amba-pl011.c serial driver. The way it handles Rx is it
submits a 4k buffer, but then waits for an Rx timeout IRQ and pauses,
reads out status / residue and terminates that transfer. So, Rx transfers
are routinely incomplete. Their residue was != 0, but ones they are
terminated you cannot retrieve that residue any longer.
Thanks
Guennadi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] [media] atmel-isi: add primary DT support
On Tue, 25 Mar 2014, Josh Wu wrote:
> This patch add the DT support for Atmel ISI driver.
> It use the same v4l2 DT interface that defined in video-interfaces.txt.
>
> Signed-off-by: Josh Wu
> Cc: devicetree@vger.kernel.org
> ---
> v1 --> v2:
> refine the binding document.
> add port node description.
> removed the optional property.
>
> .../devicetree/bindings/media/atmel-isi.txt| 50
>
> drivers/media/platform/soc_camera/atmel-isi.c | 31 +++-
> 2 files changed, 79 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt
[snip]
> diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
> b/drivers/media/platform/soc_camera/atmel-isi.c
> index f4add0a..d6a1f7b 100644
> --- a/drivers/media/platform/soc_camera/atmel-isi.c
> +++ b/drivers/media/platform/soc_camera/atmel-isi.c
[snip]
> @@ -885,6 +887,20 @@ static int atmel_isi_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int atmel_isi_probe_dt(struct atmel_isi *isi,
> + struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> +
> + /* Default settings for ISI */
> + isi->pdata.full_mode = 1;
> + isi->pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
> + isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
The above flags eventually should probably partially be added as new
driver-specific DT properties, partially derived from DT clock bindings.
But I'm ok to have them fixed like this in the initial version.
> + isi->pdata.data_width_flags = ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10;
Whereas these flags, I think, should already now be derived from the
bus-width standard property? v4l2_of_parse_parallel_bus() will extract
them for you and I just asked Ben to add a call to
v4l2_of_parse_endpoint() to his patch. Consequently you'll have to
rearrange bus-width interpretation in isi_camera_try_bus_param() a bit and
use OF parsing results there directly if available? Or maybe you find a
better way. It would certainly be better to extend your probing code and
just use OF results to initialise isi->width_flags, but that might be
impossible, because OF parsing would be performed inside
soc_camera_host_register() and your isi_camera_try_bus_param() can also be
called immediately from it if all required I2C devices are already
available? If your I2C subdevice drivers defer probing until the host has
probed, then you could initialise .width_flags after
soc_camera_host_register(), but you cannot rely on that.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
in both PIO and DMA modes.
Signed-off-by: Guennadi Liakhovetski
---
v3:
1. remove a redundant TODO
2. update the timeout to 4 seconds
.../devicetree/bindings/mmc/usdhi6rol0.txt | 33 +
drivers/mmc/host/Kconfig |6 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/usdhi6rol0.c | 1833
4 files changed, 1873 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
create mode 100644 drivers/mmc/host/usdhi6rol0.c
diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
new file mode 100644
index 000..8babdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
@@ -0,0 +1,33 @@
+* Renesas usdhi6rol0 SD/SDIO host controller
+
+Required properties:
+
+- compatible: must be
+ "renesas,usdhi6rol0"
+- interrupts: 3 interrupts, named "card detect", "data" and "SDIO" must be
+ specified
+- clocks: a clock binding for the IMCLK input
+
+Optional properties:
+
+- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply:a phandle of a regulator, supplying VccQ to the card
+
+Additionally any standard mmc bindings from mmc.txt can be used.
+
+Example:
+
+sd0: sd@ab00 {
+ compatible = "renesas,usdhi6rol0";
+ reg = <0xab00 0x200>;
+ interrupts = <0 23 0x4
+ 0 24 0x4
+ 0 25 0x4>;
+ interrupt-names = "card detect", "data", "SDIO";
+ bus-width = <4>;
+ max-frequency = <5000>;
+ cap-power-off-card;
+ clocks = <&imclk>;
+ vmmc-supply = <&vcc_sd0>;
+ vqmmc-supply = <&vccq_sd0>;
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index b675882..924f973 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -688,6 +688,12 @@ config MMC_WMT
To compile this driver as a module, choose M here: the
module will be called wmt-sdmmc.
+config MMC_USDHI6ROL0
+ tristate "Renesas USDHI6ROL0 SD/SDIO Host Controller support"
+ help
+ This selects support for the Renesas USDHI6ROL0 SD/SDIO
+ Host Controller
+
config MMC_REALTEK_PCI
tristate "Realtek PCI-E SD/MMC Card Interface Driver"
depends on MFD_RTSX_PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 3eb48b656..793a0d6 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
+obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o
obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
new file mode 100644
index 000..ea2d968
--- /dev/null
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -0,0 +1,1833 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define USDHI6_SD_CMD 0x
+#define USDHI6_SD_PORT_SEL 0x0004
+#define USDHI6_SD_ARG 0x0008
+#define USDHI6_SD_STOP 0x0010
+#define USDHI6_SD_SECCNT 0x0014
+#define USDHI6_SD_RSP100x0018
+#define USDHI6_SD_RSP320x0020
+#define USDHI6_SD_RSP540x0028
+#define USDHI6_SD_RSP760x0030
+#define USDHI6_SD_INFO10x0038
+#define USDHI6_SD_INFO20x003c
+#define USDHI6_SD_INFO1_MASK 0x0040
+#define USDHI6_SD_INFO2_MASK 0x0044
+#define USDHI6_SD_CLK_CTRL 0x0048
+#define USDHI6_SD_SIZE 0x004c
+#define USDHI6_SD_OPTION 0x0050
+#define USDHI6_SD_ERR_STS1 0x0058
+#define USDHI6_SD_ERR_STS2 0x005c
+#define USDHI6_SD_BUF0 0x0060
+#define USDHI6_SDIO_MODE 0x0068
+#define USDHI6_SDIO_INFO1 0x006c
+#define USDHI6_SDIO_INFO1_MASK 0x0070
+#define USDHI6_CC_EXT_MODE 0x01b0
+#define USDHI6_SOFT_RST0x01c0
+#define USDHI6_VERSION 0x01c4
+#define USDHI6_HOST_MODE 0x01c8
+#define USDHI6_SDIF_MODE 0x01
[PATCH v3 1/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores
This patch adds a driver for NBPF DMAC IP cores from Renesas, designed for the AMBA AXI bus. Signed-off-by: Guennadi Liakhovetski --- v3: addressed iddues, pointed out by Vinod, thanks 1. remove superfluous cookie caching 2. add residue calculation for queued transfers 3. store noth source and destination parameters in DMA_SLAVE_CONFIG 4. extract DR bindings in a separate patch 5. remove unimplemented DMA_RESUME case drivers/dma/Kconfig |6 + drivers/dma/Makefile |1 + drivers/dma/nbpfaxi.c | 1524 + 3 files changed, 1531 insertions(+) create mode 100644 drivers/dma/nbpfaxi.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 5c58638..935b6e9 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -361,6 +361,12 @@ config FSL_EDMA multiplexing capability for DMA request sources(slot). This module can be found on Freescale Vybrid and LS-1 SoCs. +config NBPFAXI_DMA + tristate "Renesas Type-AXI NBPF DMA support" + select DMA_ENGINE + help + Support for "Type-AXI" NBPF DMA IPs from Renesas + config DMA_ENGINE bool diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index 5150c82..9589ebb 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -46,3 +46,4 @@ obj-$(CONFIG_K3_DMA) += k3dma.o obj-$(CONFIG_MOXART_DMA) += moxart-dma.o obj-$(CONFIG_FSL_EDMA) += fsl-edma.o obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o +obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c new file mode 100644 index 000..5dbcce9 --- /dev/null +++ b/drivers/dma/nbpfaxi.c @@ -0,0 +1,1524 @@ +/* + * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd. + * Author: Guennadi Liakhovetski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "dmaengine.h" + +#define NBPF_REG_CHAN_OFFSET 0 +#define NBPF_REG_CHAN_SIZE 0x40 + +/* Channel Current Transaction Byte register */ +#define NBPF_CHAN_CUR_TR_BYTE 0x20 + +/* Channel Status register */ +#define NBPF_CHAN_STAT 0x24 +#define NBPF_CHAN_STAT_EN 1 +#define NBPF_CHAN_STAT_TACT4 +#define NBPF_CHAN_STAT_ERR 0x10 +#define NBPF_CHAN_STAT_END 0x20 +#define NBPF_CHAN_STAT_TC 0x40 +#define NBPF_CHAN_STAT_DER 0x400 + +/* Channel Control register */ +#define NBPF_CHAN_CTRL 0x28 +#define NBPF_CHAN_CTRL_SETEN 1 +#define NBPF_CHAN_CTRL_CLREN 2 +#define NBPF_CHAN_CTRL_STG 4 +#define NBPF_CHAN_CTRL_SWRST 8 +#define NBPF_CHAN_CTRL_CLRRQ 0x10 +#define NBPF_CHAN_CTRL_CLREND 0x20 +#define NBPF_CHAN_CTRL_CLRTC 0x40 +#define NBPF_CHAN_CTRL_SETSUS 0x100 +#define NBPF_CHAN_CTRL_CLRSUS 0x200 + +/* Channel Configuration register */ +#define NBPF_CHAN_CFG 0x2c +#define NBPF_CHAN_CFG_SEL 7 /* terminal SELect: 0..7 */ +#define NBPF_CHAN_CFG_REQD 8 /* REQuest Direction: DMAREQ is 0: input, 1: output */ +#define NBPF_CHAN_CFG_LOEN 0x10/* LOw ENable: low DMA request line is: 0: inactive, 1: active */ +#define NBPF_CHAN_CFG_HIEN 0x20/* HIgh ENable: high DMA request line is: 0: inactive, 1: active */ +#define NBPF_CHAN_CFG_LVL 0x40/* LeVeL: DMA request line is sensed as 0: edge, 1: level */ +#define NBPF_CHAN_CFG_AM 0x700 /* ACK Mode: 0: Pulse mode, 1: Level mode, b'1x: Bus Cycle */ +#define NBPF_CHAN_CFG_SDS 0xf000 /* Source Data Size: 0: 8 bits,... , 7: 1024 bits */ +#define NBPF_CHAN_CFG_DDS 0xf /* Destination Data Size: as above */ +#define NBPF_CHAN_CFG_SAD 0x10/* Source ADdress counting: 0: increment, 1: fixed */ +#define NBPF_CHAN_CFG_DAD 0x20/* Destination ADdress counting: 0: increment, 1: fixed */ +#define NBPF_CHAN_CFG_TM 0x40/* Transfer Mode: 0: single, 1: block TM */ +#define NBPF_CHAN_CFG_DEM 0x100 /* DMAEND interrupt Mask */ +#define NBPF_CHAN_CFG_TCM 0x200 /* DMATCO interrupt Mask */ +#define NBPF_CHAN_CFG_SBE 0x800 /* Sweep Buffer Enable */ +#define NBPF_CHAN_CFG_RSEL 0x1000 /* RM: Register Set sELect */ +#define NBPF_CHAN_CFG_RSW 0x2000 /* RM: Register Select sWitch */ +#define NBPF_CHAN_CFG_REN 0x4000 /* RM: Register Set Enable */ +#define NBPF_CHAN_CFG_DMS 0x8000 /* 0: register mode (RM), 1: link mode (LM) */ + +#define NBPF_CHAN_NXLA 0x38 +#define NBPF_CHAN_CRLA 0x3c + +/* Link Header field */ +#define NBPF_HEADER_LV 1 +#define NBPF_HEADER_LE 2 +#define NBPF_HEADER_WBD4 +#define
[PATCH v3 2/2] dmaengine: add device tree binding documentation for the nbpfaxi driver
The nbpfaxi dmaengine driver doesn't define any new bindings, it only
uses standard dmaengine bindings and defines 3 flags for the 3rd parameter
of the "dmas" property.
Signed-off-by: Guennadi Liakhovetski
---
v3: split out from v2, no changes otherwise
Documentation/devicetree/bindings/dma/nbpfaxi.txt | 61 +++
include/dt-bindings/dma/nbpfaxi.h | 20
2 files changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/nbpfaxi.txt
create mode 100644 include/dt-bindings/dma/nbpfaxi.h
diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt
b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
new file mode 100644
index 000..d5e2522
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
@@ -0,0 +1,61 @@
+* Renesas "Type-AXI" NBPFAXI* DMA controllers
+
+* DMA controller
+
+Required properties
+
+- compatible: must be one of
+ "renesas,nbpfaxi64dmac1b4"
+ "renesas,nbpfaxi64dmac1b8"
+ "renesas,nbpfaxi64dmac1b16"
+ "renesas,nbpfaxi64dmac4b4"
+ "renesas,nbpfaxi64dmac4b8"
+ "renesas,nbpfaxi64dmac4b16"
+ "renesas,nbpfaxi64dmac8b4"
+ "renesas,nbpfaxi64dmac8b8"
+ "renesas,nbpfaxi64dmac8b16"
+- #dma-cells: must be 2: the first integer is a terminal number, to which this
+ slave is connected, the second one is flags. Flags is a bitmask
+ with the following bits defined:
+
+#define NBPF_SLAVE_RQ_HIGH 1
+#define NBPF_SLAVE_RQ_LOW 2
+#define NBPF_SLAVE_RQ_LEVEL4
+
+Optional properties:
+
+You can use dma-channels and dma-requests as described in dma.txt, although
they
+won't be used, this information is derived from the compatibility string.
+
+Example:
+
+ dma: dma-controller@4800 {
+ compatible = "renesas,nbpfaxi64dmac8b4";
+ reg = <0x4800 0x400>;
+ interrupts = <0 12 0x4
+ 0 13 0x4
+ 0 14 0x4
+ 0 15 0x4
+ 0 16 0x4
+ 0 17 0x4
+ 0 18 0x4
+ 0 19 0x4>;
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ dma-requests = <8>;
+ };
+
+* DMA client
+
+Required properties:
+
+dmas and dma-names are required, as described in dma.txt.
+
+Example:
+
+#include
+
+...
+ dmas = <&dma 0 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)
+ &dma 1 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)>;
+ dma-names = "rx", "tx";
diff --git a/include/dt-bindings/dma/nbpfaxi.h
b/include/dt-bindings/dma/nbpfaxi.h
new file mode 100644
index 000..c1a5b9e
--- /dev/null
+++ b/include/dt-bindings/dma/nbpfaxi.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef DT_BINDINGS_NBPFAXI_H
+#define DT_BINDINGS_NBPFAXI_H
+
+/**
+ * Use "#dma-cells = <2>;" with the second integer defining slave DMA flags:
+ */
+#define NBPF_SLAVE_RQ_HIGH 1
+#define NBPF_SLAVE_RQ_LOW 2
+#define NBPF_SLAVE_RQ_LEVEL4
+
+#endif
--
2.0.0.rc0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] DMA: add a driver for AMBA AXI NBPF DMAC IP cores
On Sat, 10 May 2014, Guennadi Liakhovetski wrote: [snip] > > > + nbpf = devm_kzalloc(dev, sizeof(*nbpf) + num_channels * > > > + sizeof(nbpf->chan[0]), GFP_KERNEL); > > I think we have devm_kcalloc for these things? > > Ah, ok, missed this, thanks, will update! Sorry, don't think it's suitable here. The allocation size is "y + x * n" and not just "x * n." Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] DMA: add a driver for AMBA AXI NBPF DMAC IP cores
Hi Vinod,
Thanks for a review.
On Wed, 7 May 2014, Vinod Koul wrote:
> On Sat, Apr 26, 2014 at 02:03:44PM +0200, Guennadi Liakhovetski wrote:
> > This patch adds a driver for NBPF DMAC IP cores from Renesas, designed for
> > the AMBA AXI bus.
> >
>
> > diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt
> > b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
> > new file mode 100644
> > index 000..d5e2522
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
> > @@ -0,0 +1,61 @@
> > +* Renesas "Type-AXI" NBPFAXI* DMA controllers
> > +
> > +* DMA controller
> > +
> > +Required properties
> > +
> > +- compatible: must be one of
> > + "renesas,nbpfaxi64dmac1b4"
> > + "renesas,nbpfaxi64dmac1b8"
> > + "renesas,nbpfaxi64dmac1b16"
> > + "renesas,nbpfaxi64dmac4b4"
> > + "renesas,nbpfaxi64dmac4b8"
> > + "renesas,nbpfaxi64dmac4b16"
> > + "renesas,nbpfaxi64dmac8b4"
> > + "renesas,nbpfaxi64dmac8b8"
> > + "renesas,nbpfaxi64dmac8b16"
> > +- #dma-cells: must be 2: the first integer is a terminal number, to
> > which this
> > + slave is connected, the second one is flags. Flags is a bitmask
> > + with the following bits defined:
> > +
> > +#define NBPF_SLAVE_RQ_HIGH 1
> > +#define NBPF_SLAVE_RQ_LOW 2
> > +#define NBPF_SLAVE_RQ_LEVEL4
> > +
> > +Optional properties:
> > +
> > +You can use dma-channels and dma-requests as described in dma.txt,
> > although they
> > +won't be used, this information is derived from the compatibility string.
> > +
> > +Example:
> > +
> > + dma: dma-controller@4800 {
> > + compatible = "renesas,nbpfaxi64dmac8b4";
> > + reg = <0x4800 0x400>;
> > + interrupts = <0 12 0x4
> > + 0 13 0x4
> > + 0 14 0x4
> > + 0 15 0x4
> > + 0 16 0x4
> > + 0 17 0x4
> > + 0 18 0x4
> > + 0 19 0x4>;
> > + #dma-cells = <2>;
> > + dma-channels = <8>;
> > + dma-requests = <8>;
> > + };
> > +
> > +* DMA client
> > +
> > +Required properties:
> > +
> > +dmas and dma-names are required, as described in dma.txt.
> > +
> > +Example:
> > +
> > +#include
> > +
> > +...
> > + dmas = <&dma 0 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)
> > + &dma 1 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)>;
> > + dma-names = "rx", "tx";
>
> Pls split the DT bindings to seprate patch. This part needs ack from DT folks
I thaught it would be preferable for both to go into the tree
simultaneously, i.e. as a single patch, they can review and ack this patch
too, but ok, can do, np.
> > +static size_t nbpf_xfer_size(struct nbpf_device *nbpf,
> > +enum dma_slave_buswidth width, u32 burst)
> > +{
> > + size_t size;
> > +
> > + if (!burst)
> > + burst = 1;
> > +
> > + switch (width) {
> > + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> > + size = 8 * burst;
> > + break;
> > + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> > + size = 4 * burst;
> > + break;
> > + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> > + size = 2 * burst;
> why not
> size = width * burst;
> for all these three cases?
because width is an enum, that "accidentally" coincides with the
respective numerical value. I find this confusing - if it's an enum, you
shouldn't use it in calculations. If it's a numerical value, just use it
explicitly, but mixing both...
> > + break;
> > + default:
> > + pr_warn("%s(): invalid bus width %u\n", __func__, width);
> > + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> > + size = burst;
> this would fit too in above :)
>
> > +static void nbpf_cookie_update(struct nbpf_channel *chan, dma_cookie_t
> > cookie)
> > +{
> > + dma_cookie_t forgotten = cookie - NBPF_STATUS_KEEP;
> > +
> > + if (cookie < NBPF_STATUS_KEEP && !chan->cookie_forgotten)
> &
RE: [PATCH v2] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
Hi Phil,
Thanks for the comments.
On Mon, 28 Apr 2014, Phil Edworthy wrote:
> Hi Guennadi,
>
> On 26 April 2014 13:06, Guennadi wrote:
> > Subject: [PATCH v2] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO
> > host controller
> >
> > This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
> > in both PIO and DMA modes.
>
> ...
> > +static void usdhi6_dma_stop_unmap(struct usdhi6_host *host)
> > +{
> > + struct mmc_data *data = host->mrq->data;
> > +
> > + if (!host->dma_active)
> > + return;
> > +
> > + usdhi6_write(host, USDHI6_CC_EXT_MODE, 0);
> > + host->dma_active = false;
> > +
> > + if (data->flags & MMC_DATA_READ)
> > + /* TODO: do we have to synchronise? */
> > + dma_unmap_sg(host->chan_rx->device->dev, data->sg,
> > +data->sg_len, DMA_FROM_DEVICE);
> Yes, you have to sync, so you can remove this TODO comment.
Why do you think so? If we really do, we'd have to add it. And I did think
synchronisation was needed, that's why I posted this patch series:
http://thread.gmane.org/gmane.linux.kernel.mmc/24969
but it never got applied, even though it got 2 acks. And actually now I
think that synchronisation isn't needed. I think dma_map_sg() /
dma_unmap_sg() do that for us already. E.g.
dma_map_sg_attrs()
arm_dma_map_page()
__dma_page_cpu_to_dev()
dmac_map_area()
cpu_cache.dma_map_area()
v7_dma_inv_range()
v7_dma_clean_range()
Similar for unmapping. So, I think it would be best to remove the comment
without adding synchronisation.
Let me do this: I'll prepare a separate patch for adding dma syncs, but I
won't submit it for now, or I can just provide it for reference.
> ...
> > +static int usdhi6_probe(struct platform_device *pdev)
> > +{
> ...
> > + host= mmc_priv(mmc);
> > + host->mmc = mmc;
> > + host->wait = USDHI6_WAIT_FOR_REQUEST;
> > + host->timeout = msecs_to_jiffies(1000);
> In all places you use host->timeout, the code uses host->timeout * 4.
> Wouldn't it better to just set it here to 4 seconds?
ok, I'll do that for v3.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] DMA: add a driver for AMBA AXI NBPF DMAC IP cores
This patch adds a driver for NBPF DMAC IP cores from Renesas, designed for
the AMBA AXI bus.
Signed-off-by: Guennadi Liakhovetski
---
v2:
1. corrected copyright and a Renesas email for proper attribution
2. use %pad for dma_addr_t
3. use devm_request_irq() instead of the threaded version
4. replaces pr_debug() with dev_dbg()
5. more precise types for variables, used directly with the hardware
6. call of_dma_controller_register() after dma_async_device_register()
7. cosmetic: improved comments and simplified a loop
Thanks to all for comments
Documentation/devicetree/bindings/dma/nbpfaxi.txt | 61 +
drivers/dma/Kconfig |6 +
drivers/dma/Makefile |1 +
drivers/dma/nbpfaxi.c | 1551 +
include/dt-bindings/dma/nbpfaxi.h | 20 +
5 files changed, 1639 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/nbpfaxi.txt
create mode 100644 drivers/dma/nbpfaxi.c
create mode 100644 include/dt-bindings/dma/nbpfaxi.h
diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt
b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
new file mode 100644
index 000..d5e2522
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
@@ -0,0 +1,61 @@
+* Renesas "Type-AXI" NBPFAXI* DMA controllers
+
+* DMA controller
+
+Required properties
+
+- compatible: must be one of
+ "renesas,nbpfaxi64dmac1b4"
+ "renesas,nbpfaxi64dmac1b8"
+ "renesas,nbpfaxi64dmac1b16"
+ "renesas,nbpfaxi64dmac4b4"
+ "renesas,nbpfaxi64dmac4b8"
+ "renesas,nbpfaxi64dmac4b16"
+ "renesas,nbpfaxi64dmac8b4"
+ "renesas,nbpfaxi64dmac8b8"
+ "renesas,nbpfaxi64dmac8b16"
+- #dma-cells: must be 2: the first integer is a terminal number, to which this
+ slave is connected, the second one is flags. Flags is a bitmask
+ with the following bits defined:
+
+#define NBPF_SLAVE_RQ_HIGH 1
+#define NBPF_SLAVE_RQ_LOW 2
+#define NBPF_SLAVE_RQ_LEVEL4
+
+Optional properties:
+
+You can use dma-channels and dma-requests as described in dma.txt, although
they
+won't be used, this information is derived from the compatibility string.
+
+Example:
+
+ dma: dma-controller@4800 {
+ compatible = "renesas,nbpfaxi64dmac8b4";
+ reg = <0x4800 0x400>;
+ interrupts = <0 12 0x4
+ 0 13 0x4
+ 0 14 0x4
+ 0 15 0x4
+ 0 16 0x4
+ 0 17 0x4
+ 0 18 0x4
+ 0 19 0x4>;
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ dma-requests = <8>;
+ };
+
+* DMA client
+
+Required properties:
+
+dmas and dma-names are required, as described in dma.txt.
+
+Example:
+
+#include
+
+...
+ dmas = <&dma 0 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)
+ &dma 1 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)>;
+ dma-names = "rx", "tx";
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index ba06d1d..513207a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -361,6 +361,12 @@ config FSL_EDMA
multiplexing capability for DMA request sources(slot).
This module can be found on Freescale Vybrid and LS-1 SoCs.
+config NBPFAXI_DMA
+ tristate "Renesas Type-AXI NBPF DMA support"
+ select DMA_ENGINE
+ help
+ Support for "Type-AXI" NBPF DMA IPs from Renesas
+
config DMA_ENGINE
bool
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 5150c82..9589ebb 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -46,3 +46,4 @@ obj-$(CONFIG_K3_DMA) += k3dma.o
obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
+obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c
new file mode 100644
index 000..b0d6676
--- /dev/null
+++ b/drivers/dma/nbpfaxi.c
@@ -0,0 +1,1551 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "dmaengine.h
[PATCH v2] mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller
This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
in both PIO and DMA modes.
Signed-off-by: Guennadi Liakhovetski
---
v2: copyright and Sob email changed
.../devicetree/bindings/mmc/usdhi6rol0.txt | 33 +
drivers/mmc/host/Kconfig |6 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/usdhi6rol0.c | 1834
4 files changed, 1874 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
create mode 100644 drivers/mmc/host/usdhi6rol0.c
diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
new file mode 100644
index 000..8babdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
@@ -0,0 +1,33 @@
+* Renesas usdhi6rol0 SD/SDIO host controller
+
+Required properties:
+
+- compatible: must be
+ "renesas,usdhi6rol0"
+- interrupts: 3 interrupts, named "card detect", "data" and "SDIO" must be
+ specified
+- clocks: a clock binding for the IMCLK input
+
+Optional properties:
+
+- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply:a phandle of a regulator, supplying VccQ to the card
+
+Additionally any standard mmc bindings from mmc.txt can be used.
+
+Example:
+
+sd0: sd@ab00 {
+ compatible = "renesas,usdhi6rol0";
+ reg = <0xab00 0x200>;
+ interrupts = <0 23 0x4
+ 0 24 0x4
+ 0 25 0x4>;
+ interrupt-names = "card detect", "data", "SDIO";
+ bus-width = <4>;
+ max-frequency = <5000>;
+ cap-power-off-card;
+ clocks = <&imclk>;
+ vmmc-supply = <&vcc_sd0>;
+ vqmmc-supply = <&vccq_sd0>;
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8aaf8c1..a21d8b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -688,6 +688,12 @@ config MMC_WMT
To compile this driver as a module, choose M here: the
module will be called wmt-sdmmc.
+config MMC_USDHI6ROL0
+ tristate "Renesas USDHI6ROL0 SD/SDIO Host Controller support"
+ help
+ This selects support for the Renesas USDHI6ROL0 SD/SDIO
+ Host Controller
+
config MMC_REALTEK_PCI
tristate "Realtek PCI-E SD/MMC Card Interface Driver"
depends on MFD_RTSX_PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 0c8aa5e..28d1fa0 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
+obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o
obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
diff --git a/drivers/mmc/host/usdhi6rol0.c b/drivers/mmc/host/usdhi6rol0.c
new file mode 100644
index 000..261b245
--- /dev/null
+++ b/drivers/mmc/host/usdhi6rol0.c
@@ -0,0 +1,1834 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Electronics Europe Ltd.
+ * Author: Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define USDHI6_SD_CMD 0x
+#define USDHI6_SD_PORT_SEL 0x0004
+#define USDHI6_SD_ARG 0x0008
+#define USDHI6_SD_STOP 0x0010
+#define USDHI6_SD_SECCNT 0x0014
+#define USDHI6_SD_RSP100x0018
+#define USDHI6_SD_RSP320x0020
+#define USDHI6_SD_RSP540x0028
+#define USDHI6_SD_RSP760x0030
+#define USDHI6_SD_INFO10x0038
+#define USDHI6_SD_INFO20x003c
+#define USDHI6_SD_INFO1_MASK 0x0040
+#define USDHI6_SD_INFO2_MASK 0x0044
+#define USDHI6_SD_CLK_CTRL 0x0048
+#define USDHI6_SD_SIZE 0x004c
+#define USDHI6_SD_OPTION 0x0050
+#define USDHI6_SD_ERR_STS1 0x0058
+#define USDHI6_SD_ERR_STS2 0x005c
+#define USDHI6_SD_BUF0 0x0060
+#define USDHI6_SDIO_MODE 0x0068
+#define USDHI6_SDIO_INFO1 0x006c
+#define USDHI6_SDIO_INFO1_MASK 0x0070
+#define USDHI6_CC_EXT_MODE 0x01b0
+#define USDHI6_SOFT_RST0x01c0
+#define USDHI6_VERSION 0x01c4
+#define USDHI6_HOST_MODE 0x01c8
+#define USDHI6_SDIF_MODE 0x01cc
+
+#define USDHI6_SD_CMD_APP 0x0040
+#define USDHI6_SD
[PATCH] mmc: add a driver for the Renesas v08r07s01e SD/SDIO host controller
This patch adds a driver for the Renesas v08r07s01e SD/SDIO host controller
in both PIO and DMA modes.
Signed-off-by: Guennadi Liakhovetski
---
Tested on a Xilinx zc706-based board with SD, MMC and SDIO cards.
.../devicetree/bindings/mmc/v08r07s01e.txt | 33 +
drivers/mmc/host/Kconfig |6 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/v08r07s01e.c | 1835
4 files changed, 1875 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/v08r07s01e.txt
create mode 100644 drivers/mmc/host/v08r07s01e.c
diff --git a/Documentation/devicetree/bindings/mmc/v08r07s01e.txt
b/Documentation/devicetree/bindings/mmc/v08r07s01e.txt
new file mode 100644
index 000..60e6cb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/v08r07s01e.txt
@@ -0,0 +1,33 @@
+* Renesas v08r07s01e SD/SDIO host controller
+
+Required properties:
+
+- compatible: must be
+ "renesas,v08r07s01e"
+- interrupts: 3 interrupts, named "card detect", "data" and "SDIO" must be
+ specified
+- clocks: a clock binding for the IMCLK input
+
+Optional properties:
+
+- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply:a phandle of a regulator, supplying VccQ to the card
+
+Additionally any standard mmc bindings from mmc.txt can be used.
+
+Example:
+
+sd0: sd@ab00 {
+ compatible = "renesas,v08r07s01e";
+ reg = <0xab00 0x200>;
+ interrupts = <0 23 0x4
+ 0 24 0x4
+ 0 25 0x4>;
+ interrupt-names = "card detect", "data", "SDIO";
+ bus-width = <4>;
+ max-frequency = <5000>;
+ cap-power-off-card;
+ clocks = <&imclk>;
+ vmmc-supply = <&vcc_sd0>;
+ vqmmc-supply = <&vccq_sd0>;
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8aaf8c1..0feccd5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -688,6 +688,12 @@ config MMC_WMT
To compile this driver as a module, choose M here: the
module will be called wmt-sdmmc.
+config MMC_V08R07S01E
+ tristate "Renesas V08R07S01E SD/SDIO Host Controller support"
+ help
+ This selects support for the Renesas V08R07S01E SD/SDIO
+ Host Controller
+
config MMC_REALTEK_PCI
tristate "Realtek PCI-E SD/MMC Card Interface Driver"
depends on MFD_RTSX_PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 0c8aa5e..d7d3ee9 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
+obj-$(CONFIG_MMC_V08R07S01E) += v08r07s01e.o
obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
diff --git a/drivers/mmc/host/v08r07s01e.c b/drivers/mmc/host/v08r07s01e.c
new file mode 100644
index 000..4eb9ce1
--- /dev/null
+++ b/drivers/mmc/host/v08r07s01e.c
@@ -0,0 +1,1835 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Europe Ltd.
+ * Author: Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define V08R07_SD_CMD 0x
+#define V08R07_SD_PORT_SEL 0x0004
+#define V08R07_SD_ARG 0x0008
+#define V08R07_SD_STOP 0x0010
+#define V08R07_SD_SECCNT 0x0014
+#define V08R07_SD_RSP100x0018
+#define V08R07_SD_RSP320x0020
+#define V08R07_SD_RSP540x0028
+#define V08R07_SD_RSP760x0030
+#define V08R07_SD_INFO10x0038
+#define V08R07_SD_INFO20x003c
+#define V08R07_SD_INFO1_MASK 0x0040
+#define V08R07_SD_INFO2_MASK 0x0044
+#define V08R07_SD_CLK_CTRL 0x0048
+#define V08R07_SD_SIZE 0x004c
+#define V08R07_SD_OPTION 0x0050
+#define V08R07_SD_ERR_STS1 0x0058
+#define V08R07_SD_ERR_STS2 0x005c
+#define V08R07_SD_BUF0 0x0060
+#define V08R07_SDIO_MODE 0x0068
+#define V08R07_SDIO_INFO1 0x006c
+#define V08R07_SDIO_INFO1_MASK 0x0070
+#define V08R07_CC_EXT_MODE 0x01b0
+#define V08R07_SOFT_RST0x01c0
+#define V08R07_VERSION 0x01c4
+#define V08R07_HOST_MODE 0x01c8
+#define V08R07_SDIF_MODE 0x01cc
+
+#define V08R07_SD_CMD_APP 0x0040
+#defi
[PATCH] DMA: add a driver for AMBA AXI NBPF DMAC IP cores
This patch adds a driver for NBPF DMAC IP cores from Renesas, designed for
the AMBA AXI bus.
Signed-off-by: Guennadi Liakhovetski
---
Tested on a Xilinx zc706-based board with an SD-host (driver will be
submitted shortly) and a PL011 UART.
Documentation/devicetree/bindings/dma/nbpfaxi.txt | 61 +
drivers/dma/Kconfig |6 +
drivers/dma/Makefile |1 +
drivers/dma/nbpfaxi.c | 1554 +
include/dt-bindings/dma/nbpfaxi.h | 20 +
5 files changed, 1642 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/nbpfaxi.txt
create mode 100644 drivers/dma/nbpfaxi.c
create mode 100644 include/dt-bindings/dma/nbpfaxi.h
diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt
b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
new file mode 100644
index 000..d5e2522
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt
@@ -0,0 +1,61 @@
+* Renesas "Type-AXI" NBPFAXI* DMA controllers
+
+* DMA controller
+
+Required properties
+
+- compatible: must be one of
+ "renesas,nbpfaxi64dmac1b4"
+ "renesas,nbpfaxi64dmac1b8"
+ "renesas,nbpfaxi64dmac1b16"
+ "renesas,nbpfaxi64dmac4b4"
+ "renesas,nbpfaxi64dmac4b8"
+ "renesas,nbpfaxi64dmac4b16"
+ "renesas,nbpfaxi64dmac8b4"
+ "renesas,nbpfaxi64dmac8b8"
+ "renesas,nbpfaxi64dmac8b16"
+- #dma-cells: must be 2: the first integer is a terminal number, to which this
+ slave is connected, the second one is flags. Flags is a bitmask
+ with the following bits defined:
+
+#define NBPF_SLAVE_RQ_HIGH 1
+#define NBPF_SLAVE_RQ_LOW 2
+#define NBPF_SLAVE_RQ_LEVEL4
+
+Optional properties:
+
+You can use dma-channels and dma-requests as described in dma.txt, although
they
+won't be used, this information is derived from the compatibility string.
+
+Example:
+
+ dma: dma-controller@4800 {
+ compatible = "renesas,nbpfaxi64dmac8b4";
+ reg = <0x4800 0x400>;
+ interrupts = <0 12 0x4
+ 0 13 0x4
+ 0 14 0x4
+ 0 15 0x4
+ 0 16 0x4
+ 0 17 0x4
+ 0 18 0x4
+ 0 19 0x4>;
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ dma-requests = <8>;
+ };
+
+* DMA client
+
+Required properties:
+
+dmas and dma-names are required, as described in dma.txt.
+
+Example:
+
+#include
+
+...
+ dmas = <&dma 0 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)
+ &dma 1 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)>;
+ dma-names = "rx", "tx";
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index ba06d1d..513207a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -361,6 +361,12 @@ config FSL_EDMA
multiplexing capability for DMA request sources(slot).
This module can be found on Freescale Vybrid and LS-1 SoCs.
+config NBPFAXI_DMA
+ tristate "Renesas Type-AXI NBPF DMA support"
+ select DMA_ENGINE
+ help
+ Support for "Type-AXI" NBPF DMA IPs from Renesas
+
config DMA_ENGINE
bool
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 5150c82..9589ebb 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -46,3 +46,4 @@ obj-$(CONFIG_K3_DMA) += k3dma.o
obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
+obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c
new file mode 100644
index 000..152bb13
--- /dev/null
+++ b/drivers/dma/nbpfaxi.c
@@ -0,0 +1,1554 @@
+/*
+ * Copyright (C) 2013-2014 Renesas Europe Ltd.
+ * Author: Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "dmaengine.h"
+
+#define NBPF_REG_CHAN_OFFSET 0
+#define NBPF_REG_CHAN_SIZE 0x40
+
+/* Channel Current Transaction Byte register */
+#define NBPF_CHAN_CUR_TR_BYTE 0x20
+
+/* Channel Status register */
+#define NBPF_CHAN_STAT 0x24
+#define NBPF_CHAN_STAT_EN 1
+#define NBPF_CHAN_STAT_TACT4
+#define NB
Re: [PATCH v2 3/3] [media] atmel-isi: add primary DT support
,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
> struct isi_platform_data *pdata;
>
> pdata = dev->platform_data;
> - if (!pdata || !pdata->data_width_flags) {
> + if ((!pdata || !pdata->data_width_flags) && !pdev->dev.of_node) {
> dev_err(&pdev->dev,
> "No config available for Atmel ISI\n");
> return -EINVAL;
> @@ -912,7 +928,11 @@ static int atmel_isi_probe(struct platform_device *pdev)
> if (IS_ERR(isi->pclk))
> return PTR_ERR(isi->pclk);
>
> - memcpy(&isi->pdata, pdata, sizeof(struct isi_platform_data));
> + if (pdata)
> + memcpy(&isi->pdata, pdata, sizeof(struct isi_platform_data));
> + else/* dt probe */
> + atmel_isi_probe_dt(isi, pdev);
> +
> isi->active = NULL;
> spin_lock_init(&isi->lock);
> INIT_LIST_HEAD(&isi->video_buffer_list);
> @@ -1014,11 +1034,18 @@ err_alloc_ctx:
> return ret;
> }
>
> +static const struct of_device_id atmel_isi_of_match[] = {
> + { .compatible = "atmel,at91sam9g45-isi" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, atmel_isi_of_match);
> +
> static struct platform_driver atmel_isi_driver = {
> .remove = atmel_isi_remove,
> .driver = {
> .name = "atmel_isi",
> .owner = THIS_MODULE,
> + .of_match_table = atmel_isi_of_match,
> },
> };
>
> --
> 1.7.9.5
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Wed, 12 Feb 2014, Mauro Carvalho Chehab wrote:
> Em Tue, 11 Feb 2014 18:22:34 +0100
> Sylwester Nawrocki 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
Cannot see any problems with this
Acked-by: Guennadi Liakhovetski
Thanks
Guennadi
> > 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
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
