On Fri, 21 Mar 2008 11:12:30 -0500 Timur Tabi [off-list ref] wrote:
Andrew Morton wrote:
quoted
quoted
+static struct diu_hw dr = {
+ .mode = MFB_MODE1,
+ .reg_lock = __SPIN_LOCK_UNLOCKED(old_style_spin_init),
+};
I'm not clear on what's supposed to happen with __SPIN_LOCK_UNLOCKED(). I
do know that its documentation is crap.
Yes, "__SPIN_LOCK_UNLOCKED(old_style_spin_init)" is wrong. We'll fix it.
quoted
static struct diu_hw dr = {
.mode = MFB_MODE1,
- .reg_lock = __SPIN_LOCK_UNLOCKED(old_style_spin_init),
+ .reg_lock = __SPIN_LOCK_UNLOCKED(diu_hw.reg_lock),
};
Yes, this is better. Did you already make this change when you applied it to
your -mm repo?
I did:
--- a/drivers/video/fsl-diu-fb.c~fbdev-driver-for-freescale-8610-and-5121-diu-fix
+++ a/drivers/video/fsl-diu-fb.c
@@ -274,7 +274,7 @@ static struct mfb_info mfb_template[] =
static struct diu_hw dr = {
.mode = MFB_MODE1,
- .reg_lock = __SPIN_LOCK_UNLOCKED(old_style_spin_init),
+ .reg_lock = __SPIN_LOCK_UNLOCKED(dr.reg_lock),
};
static struct diu_pool pool;
quoted
GFP_DMA implies GFP_ATOMIC, but it's appropriate for documentation purposes.
So does that mean that "GFP_DMA | GFP_KERNEL" is always wrong?
No, that's OK too. It's just that GFP_DMA|GFP_ATOMIC is a bit redundant
and misleading. GFP_DMA is already atomic; the only effect of adding
GFP_ATOMIC to GFP_DMA is to add __GFP_HIGH.
Don't wory about it ;)
If so, this
combination is used a lot in the kernel today.
quoted
quoted
+ if (virt) {
+ *phys = virt_to_phys(virt);
+ pr_debug("virt %p, phys=%llx\n", virt, (uint64_t) *phys);
+ memset(virt, 0, size);
Could have used __GFP_ZERO, I guess.
I had completely forgotten about __GFP_ZERO. Thanks.
quoted
quoted
+ virt = (void *) rh_alloc(&diu_ops.diu_rh_info, size, "DIU");
hm, I'd have expected checkpatch to whine about the space after the cast
there. Whatever.
I thought a space after a cast is the right thing to do?
Last time I grepped, no-space is a lot more common.
quoted
please take a look, and please use checkpatch on all future patches.
Sorry, we forgot to run it again after our second version of the patch.
quoted
quoted
+static void free_irq_local(int irq)
+{
+ struct diu *hw = dr.diu_reg;
+
+ /* Disable all LCDC interrupt */
+ out_be32(&(hw->int_mask), 0x1f);
+
+ free_irq(irq, 0);
+}
and the free_irq() will go splat?
Sorry, but I don't understand what's wrong with this code.
You snipped a bit. Earlier, request_irq() failures were ignored. So I
think there's a code path where free_irq_local() can free an IRQ which this
driver never owned.
We'll make the other changes you've suggested and repost.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/