From: Sascha Hauer <s.hauer@pengutronix.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/8] Add a mfd IPUv3 driver
Date: Tue, 01 Mar 2011 11:31:55 +0000 [thread overview]
Message-ID: <20110301113155.GO29521@pengutronix.de> (raw)
In-Reply-To: <alpine.LFD.2.00.1103011054440.2701@localhost6.localdomain6>
On Tue, Mar 01, 2011 at 11:00:09AM +0100, Thomas Gleixner wrote:
> On Tue, 1 Mar 2011, Sascha Hauer wrote:
> > On Mon, Feb 28, 2011 at 07:33:05PM +0100, Thomas Gleixner wrote:
> > > > +void ipu_idmac_put(struct ipu_channel *channel)
> > > > +{
> > > > + dev_dbg(ipu_dev, "%s %d\n", __func__, channel->num);
> > >
> > > Do we really need this debug stuff in all these functions ?
> >
> > Reading this comment I expected tons of dev_dbg in the driver. The one
> > you mentioned above (plus the corresponding one in ipu_idmac_get) are
> > indeed not particularly useful, but do you think there is still too much
> > debug code left?
>
> Well, I don't see a point in having useless debug stuff around.
> > > > + DECLARE_IPU_IRQ_BITMAP(irqs);
> > >
> > > Why the hell do we need this? It's a bog standard bitmap, right ?
> >
> > It's defined as:
> >
> > #define DECLARE_IPU_IRQ_BITMAP(name) DECLARE_BITMAP(name, IPU_IRQ_COUNT)
> >
> > So yes, it's a standard bitmask. It can be used in client drivers
> > aswell. Where's the problem of adding a define for this so that client
> > drivers do not have to care about the size of the bitmap?
>
> That's nonsense. You have to know about the size of the bitmap for any
> operation on it. Or are you going to provide wrappers around
> bitmap_zero() and all other possible bitmap_* functions as well?
Ok, you're right.
>
> > >
> > > > + bitmap_zero(irqs, IPU_IRQ_COUNT);
> > > > + ret = ipu_submodules_init(pdev, ipu_base, ipu_clk);
> > > > + if (ret)
> > > > + goto failed_submodules_init;
> > > > +
> > > > + /* Set sync refresh channels as high priority */
> > > > + ipu_idmac_write(0x18800000, IDMAC_CHA_PRI(0));
> > >
> > > Hmm, this random prio setting here is odd.
> >
> > This is 1:1 from the Freescale Kernel and I never thought about it. We
> > can remove it and see what happens. Maybe then some day we'll learn
> > *why* this is done.
>
> Well, the point is to move that to the init function which deals with
> IDMAC and not have it at some random place in the code.
Ok, will move it there.
>
> > > > + /* Wait for DC triple buffer to empty */
> > > > + if (dc_channels[dc_chan].di = 0)
> > > > + while ((__raw_readl(DC_STAT) & 0x00000002)
> > > > + != 0x00000002) {
> > > > + msleep(2);
> > > > + timeout -= 2;
> > > > + if (timeout <= 0)
> > > > + break;
> > >
> > > So we poll stuff which is updated from some other function ?
> >
> > We poll the DC_STAT register here which is updated from the hardware.
>
> And there is no interrupt for this ?
Given the sheer amount of interrupt bits it's a bit surprising, but no,
I haven't found an interrupt for this (This of course doesn't mean it
doesn't exist...)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/8] Add a mfd IPUv3 driver
Date: Tue, 1 Mar 2011 12:31:55 +0100 [thread overview]
Message-ID: <20110301113155.GO29521@pengutronix.de> (raw)
In-Reply-To: <alpine.LFD.2.00.1103011054440.2701@localhost6.localdomain6>
On Tue, Mar 01, 2011 at 11:00:09AM +0100, Thomas Gleixner wrote:
> On Tue, 1 Mar 2011, Sascha Hauer wrote:
> > On Mon, Feb 28, 2011 at 07:33:05PM +0100, Thomas Gleixner wrote:
> > > > +void ipu_idmac_put(struct ipu_channel *channel)
> > > > +{
> > > > + dev_dbg(ipu_dev, "%s %d\n", __func__, channel->num);
> > >
> > > Do we really need this debug stuff in all these functions ?
> >
> > Reading this comment I expected tons of dev_dbg in the driver. The one
> > you mentioned above (plus the corresponding one in ipu_idmac_get) are
> > indeed not particularly useful, but do you think there is still too much
> > debug code left?
>
> Well, I don't see a point in having useless debug stuff around.
> > > > + DECLARE_IPU_IRQ_BITMAP(irqs);
> > >
> > > Why the hell do we need this? It's a bog standard bitmap, right ?
> >
> > It's defined as:
> >
> > #define DECLARE_IPU_IRQ_BITMAP(name) DECLARE_BITMAP(name, IPU_IRQ_COUNT)
> >
> > So yes, it's a standard bitmask. It can be used in client drivers
> > aswell. Where's the problem of adding a define for this so that client
> > drivers do not have to care about the size of the bitmap?
>
> That's nonsense. You have to know about the size of the bitmap for any
> operation on it. Or are you going to provide wrappers around
> bitmap_zero() and all other possible bitmap_* functions as well?
Ok, you're right.
>
> > >
> > > > + bitmap_zero(irqs, IPU_IRQ_COUNT);
> > > > + ret = ipu_submodules_init(pdev, ipu_base, ipu_clk);
> > > > + if (ret)
> > > > + goto failed_submodules_init;
> > > > +
> > > > + /* Set sync refresh channels as high priority */
> > > > + ipu_idmac_write(0x18800000, IDMAC_CHA_PRI(0));
> > >
> > > Hmm, this random prio setting here is odd.
> >
> > This is 1:1 from the Freescale Kernel and I never thought about it. We
> > can remove it and see what happens. Maybe then some day we'll learn
> > *why* this is done.
>
> Well, the point is to move that to the init function which deals with
> IDMAC and not have it at some random place in the code.
Ok, will move it there.
>
> > > > + /* Wait for DC triple buffer to empty */
> > > > + if (dc_channels[dc_chan].di == 0)
> > > > + while ((__raw_readl(DC_STAT) & 0x00000002)
> > > > + != 0x00000002) {
> > > > + msleep(2);
> > > > + timeout -= 2;
> > > > + if (timeout <= 0)
> > > > + break;
> > >
> > > So we poll stuff which is updated from some other function ?
> >
> > We poll the DC_STAT register here which is updated from the hardware.
>
> And there is no interrupt for this ?
Given the sheer amount of interrupt bits it's a bit surprising, but no,
I haven't found an interrupt for this (This of course doesn't mean it
doesn't exist...)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
Paul Mundt <lethal@linux-sh.org>,
Samuel Ortiz <sameo@linux.intel.com>
Subject: Re: [PATCH 3/8] Add a mfd IPUv3 driver
Date: Tue, 1 Mar 2011 12:31:55 +0100 [thread overview]
Message-ID: <20110301113155.GO29521@pengutronix.de> (raw)
In-Reply-To: <alpine.LFD.2.00.1103011054440.2701@localhost6.localdomain6>
On Tue, Mar 01, 2011 at 11:00:09AM +0100, Thomas Gleixner wrote:
> On Tue, 1 Mar 2011, Sascha Hauer wrote:
> > On Mon, Feb 28, 2011 at 07:33:05PM +0100, Thomas Gleixner wrote:
> > > > +void ipu_idmac_put(struct ipu_channel *channel)
> > > > +{
> > > > + dev_dbg(ipu_dev, "%s %d\n", __func__, channel->num);
> > >
> > > Do we really need this debug stuff in all these functions ?
> >
> > Reading this comment I expected tons of dev_dbg in the driver. The one
> > you mentioned above (plus the corresponding one in ipu_idmac_get) are
> > indeed not particularly useful, but do you think there is still too much
> > debug code left?
>
> Well, I don't see a point in having useless debug stuff around.
> > > > + DECLARE_IPU_IRQ_BITMAP(irqs);
> > >
> > > Why the hell do we need this? It's a bog standard bitmap, right ?
> >
> > It's defined as:
> >
> > #define DECLARE_IPU_IRQ_BITMAP(name) DECLARE_BITMAP(name, IPU_IRQ_COUNT)
> >
> > So yes, it's a standard bitmask. It can be used in client drivers
> > aswell. Where's the problem of adding a define for this so that client
> > drivers do not have to care about the size of the bitmap?
>
> That's nonsense. You have to know about the size of the bitmap for any
> operation on it. Or are you going to provide wrappers around
> bitmap_zero() and all other possible bitmap_* functions as well?
Ok, you're right.
>
> > >
> > > > + bitmap_zero(irqs, IPU_IRQ_COUNT);
> > > > + ret = ipu_submodules_init(pdev, ipu_base, ipu_clk);
> > > > + if (ret)
> > > > + goto failed_submodules_init;
> > > > +
> > > > + /* Set sync refresh channels as high priority */
> > > > + ipu_idmac_write(0x18800000, IDMAC_CHA_PRI(0));
> > >
> > > Hmm, this random prio setting here is odd.
> >
> > This is 1:1 from the Freescale Kernel and I never thought about it. We
> > can remove it and see what happens. Maybe then some day we'll learn
> > *why* this is done.
>
> Well, the point is to move that to the init function which deals with
> IDMAC and not have it at some random place in the code.
Ok, will move it there.
>
> > > > + /* Wait for DC triple buffer to empty */
> > > > + if (dc_channels[dc_chan].di == 0)
> > > > + while ((__raw_readl(DC_STAT) & 0x00000002)
> > > > + != 0x00000002) {
> > > > + msleep(2);
> > > > + timeout -= 2;
> > > > + if (timeout <= 0)
> > > > + break;
> > >
> > > So we poll stuff which is updated from some other function ?
> >
> > We poll the DC_STAT register here which is updated from the hardware.
>
> And there is no interrupt for this ?
Given the sheer amount of interrupt bits it's a bit surprising, but no,
I haven't found an interrupt for this (This of course doesn't mean it
doesn't exist...)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2011-03-01 11:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 10:00 [PATCH] i.MX51 Framebuffer support Sascha Hauer
2011-02-28 10:00 ` [PATCH 1/8] fb: export fb mode db table Sascha Hauer
2011-02-28 10:00 ` Sascha Hauer
2011-02-28 10:00 ` Sascha Hauer
2011-02-28 10:00 ` [PATCH 2/8] ARM i.MX51: setup mipi Sascha Hauer
2011-02-28 10:00 ` [PATCH 3/8] Add a mfd IPUv3 driver Sascha Hauer
2011-02-28 10:00 ` Sascha Hauer
2011-02-28 17:11 ` Arnd Bergmann
2011-02-28 17:11 ` Arnd Bergmann
2011-02-28 17:11 ` Arnd Bergmann
2011-03-01 9:15 ` Sascha Hauer
2011-03-01 9:15 ` Sascha Hauer
2011-03-01 9:15 ` Sascha Hauer
2011-03-01 10:27 ` Arnd Bergmann
2011-03-01 10:27 ` Arnd Bergmann
2011-03-01 10:27 ` Arnd Bergmann
2011-03-01 11:12 ` Sascha Hauer
2011-03-01 11:12 ` Sascha Hauer
2011-03-01 11:12 ` Sascha Hauer
2011-03-01 11:43 ` Arnd Bergmann
2011-03-01 11:43 ` Arnd Bergmann
2011-03-01 11:43 ` Arnd Bergmann
2011-03-01 14:09 ` Thomas Gleixner
2011-03-01 14:09 ` Thomas Gleixner
2011-03-01 14:09 ` Thomas Gleixner
2011-02-28 18:33 ` Thomas Gleixner
2011-02-28 18:33 ` Thomas Gleixner
2011-02-28 18:33 ` Thomas Gleixner
2011-03-01 9:39 ` Sascha Hauer
2011-03-01 9:39 ` Sascha Hauer
2011-03-01 9:39 ` Sascha Hauer
2011-03-01 10:00 ` Thomas Gleixner
2011-03-01 10:00 ` Thomas Gleixner
2011-03-01 10:00 ` Thomas Gleixner
2011-03-01 11:31 ` Sascha Hauer [this message]
2011-03-01 11:31 ` Sascha Hauer
2011-03-01 11:31 ` Sascha Hauer
2011-02-28 10:00 ` [PATCH 4/8] Add i.MX5 framebuffer driver Sascha Hauer
2011-02-28 10:00 ` Sascha Hauer
2011-02-28 10:00 ` Sascha Hauer
2011-02-28 10:00 ` [PATCH 5/8] ARM i.MX51: Add IPU device support Sascha Hauer
2011-02-28 10:00 ` [PATCH 6/8] ARM i.MX5: Allow to increase max zone order Sascha Hauer
2011-02-28 10:04 ` Russell King - ARM Linux
2011-02-28 10:18 ` Sascha Hauer
2011-02-28 10:00 ` [PATCH 7/8] ARM i.MX5: increase dma consistent size for IPU support Sascha Hauer
2011-02-28 10:00 ` [PATCH 8/8] ARM i.MX51 babbage: Add framebuffer support Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110301113155.GO29521@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.