The macros ReadMReg and WriteMReg are really just private versions of
the kernel's readl and writel functions. Use the kernel's functions
instead. And since ioremap returns a (void __iomem *) not a (u8 *),
change all the uses of dt3155_lbase to reflect this.
While here, make dt3155_lbase static since it is only used in the
dt3155_drv.c file. Also, remove the global variable dt3155_bbase
since it is not used anywhere in the code.
Where is makes sense, create a local 'mmio' variable instead of using
dt3155_lbase[minor] to make the code more readable.
This change also affects the {Read|Write}I2C functions so they are
also modified as needed.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Scott Smedley <ss@aao.gov.au>
---
diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index 40ef97f..4bbfbee 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -64,8 +64,8 @@ extern void printques(int);
#include <linux/poll.h>
#include <linux/sched.h>
#include <linux/smp_lock.h>
+#include <linux/io.h>
-#include <asm/io.h>
#include <asm/uaccess.h>
#include "dt3155.h"
@@ -115,14 +115,12 @@ int dt3155_major = 0;
struct dt3155_status dt3155_status[MAXBOARDS];
/* kernel logical address of the board */
-u8 *dt3155_lbase[MAXBOARDS] = { NULL
+static void __iomem *dt3155_lbase[MAXBOARDS] = { NULL
#if MAXBOARDS == 2
, NULL
#endif
};
-/* DT3155 registers */
-u8 *dt3155_bbase = NULL; /* kernel logical address of the *
- * buffer region */
+
u32 dt3155_dev_open[MAXBOARDS] = {0
#if MAXBOARDS == 2
, 0
@@ -142,11 +140,13 @@ static void quick_stop (int minor)
{
// TODO: scott was here
#if 1
- ReadMReg((dt3155_lbase[minor] + INT_CSR), int_csr_r.reg);
+ void ...This doesn't apply at all against the latest linux-next tree. Care to redo it and resend it (not in base64 please.) thanks, greg k-h --
Hmm... Strange, I just rechecked the patch against next-20100430. It applied with no issues. Regards, Hartley --
The macros ReadMReg and WriteMReg are really just private versions of
the kernel's readl and writel functions. Use the kernel's functions
instead. And since ioremap returns a (void __iomem *) not a (u8 *),
change all the uses of dt3155_lbase to reflect this.
While here, make dt3155_lbase static since it is only used in the
dt3155_drv.c file. Also, remove the global variable dt3155_bbase
since it is not used anywhere in the code.
Where is makes sense, create a local 'mmio' variable instead of using
dt3155_lbase[minor] to make the code more readable.
This change also affects the {Read|Write}I2C functions so they are
also modified as needed.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Scott Smedley <ss@aao.gov.au>
---
Greg,
This is a resend. Hopefully the merge issue is fixed.
diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index 40ef97f..4bbfbee 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -64,8 +64,8 @@ extern void printques(int);
#include <linux/poll.h>
#include <linux/sched.h>
#include <linux/smp_lock.h>
+#include <linux/io.h>
-#include <asm/io.h>
#include <asm/uaccess.h>
#include "dt3155.h"
@@ -115,14 +115,12 @@ int dt3155_major = 0;
struct dt3155_status dt3155_status[MAXBOARDS];
/* kernel logical address of the board */
-u8 *dt3155_lbase[MAXBOARDS] = { NULL
+static void __iomem *dt3155_lbase[MAXBOARDS] = { NULL
#if MAXBOARDS == 2
, NULL
#endif
};
-/* DT3155 registers */
-u8 *dt3155_bbase = NULL; /* kernel logical address of the *
- * buffer region */
+
u32 dt3155_dev_open[MAXBOARDS] = {0
#if MAXBOARDS == 2
, 0
@@ -142,11 +140,13 @@ static void quick_stop (int minor)
{
// TODO: scott was here
#if 1
- ...Odd, but no, this still does not apply. I get the following errors: patching file drivers/staging/dt3155/dt3155_drv.c Hunk #1 succeeded at 75 (offset 11 lines). Hunk #2 FAILED at 115. Hunk #3 succeeded at 150 (offset 8 lines). Hunk #4 succeeded at 184 (offset 8 lines). Hunk #5 succeeded at 201 (offset 8 lines). Hunk #6 succeeded at 216 (offset 8 lines). Hunk #7 succeeded at 227 with fuzz 2 (offset 8 lines). Hunk #8 succeeded at 247 with fuzz 2 (offset 8 lines). Hunk #9 FAILED at 257. Hunk #10 succeeded at 273 with fuzz 2 (offset 8 lines). Hunk #11 succeeded at 290 (offset 8 lines). Hunk #12 succeeded at 326 with fuzz 2 (offset 8 lines). Hunk #13 FAILED at 395. Hunk #14 succeeded at 418 with fuzz 2 (offset 8 lines). Hunk #15 succeeded at 435 (offset 8 lines). Hunk #16 FAILED at 438. Hunk #17 FAILED at 456. Hunk #18 FAILED at 471. Hunk #19 succeeded at 501 (offset 8 lines). Hunk #20 succeeded at 510 (offset 8 lines). Hunk #21 succeeded at 699 (offset 8 lines). Hunk #22 succeeded at 727 (offset 8 lines). Hunk #23 succeeded at 929 with fuzz 1 (offset 8 lines). Hunk #24 succeeded at 1054 with fuzz 2 (offset 8 lines). 6 out of 24 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_drv.c.rej patching file drivers/staging/dt3155/dt3155_drv.h patching file drivers/staging/dt3155/dt3155_io.c Hunk #2 FAILED at 77. Hunk #3 FAILED at 103. Hunk #4 FAILED at 119. Hunk #5 FAILED at 134. Hunk #6 FAILED at 151. 5 out of 6 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_io.c.rej patching file drivers/staging/dt3155/dt3155_io.h Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file drivers/staging/dt3155/dt3155_io.h.rej Did you rebase this on the latest linux-next tree? thanks, greg k-h --
I did. And I just re-did is again against next-20100503 and it generated the same patch.
But, I just noticed this:
$ git log drivers/staging/dt3155
commit 3c59b4691587b8977cc77ecf07985758a2ba0d97
Merge: 7f1e428 bed46a8
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon May 3 14:17:49 2010 +1000
Merge remote branch 'staging-next/staging-next'
Conflicts:
drivers/staging/arlan/arlan-main.c
drivers/staging/comedi/drivers/cb_das16_cs.c
drivers/staging/cx25821/cx25821-alsa.c
drivers/staging/dt3155/dt3155_drv.c
drivers/staging/netwave/netwave_cs.c
Could the next tree be out of sync with your tree?
Regards,
Hartley--
Hm, some other tree might be doing something in those files. But the fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought it was a revert, makes me suspect that you did it against something else. If you make this against my staging-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git using the staging-next branch, does that make the patch different? Let me know if you need help doing that. thanks, greg k-h --
Ok. Pulled your staging-next (thanks Joe). It's way different from linux-next and matches Linus' tree exactly. It's missing all of your "Drop the "_s"..." and "The typedef is not needed." patches. Of course I could be on the wrong branch for your staging-next tree. The only branches listed are: $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master Regards, Hartley--
It appears these are the patches missing in your staging-next tree that do exist in the linux-next tree: Staging: dt3155: remove "inline" usage Staging: dt3155: rename dt3155_fbuffer_s Staging: dt3155: rename dt3155_config_s Staging: dt3155: rename dt3155_read_t Staging: dt3155: rename dt3155_status_t Staging: dt3155: remove frame_info_t Staging: dt3155: remove TRUE/FALSE Staging: dt3155: remove #ifdef Staging: dt3155: allocator.c: sparse cleanups Staging: dt3155: fix parentheses and bracket spacing style issues Staging: dt3155: fix coding style issue in dt3155_isr.c Staging: dt3155: fix wait_ibsyclr function Staging: remove unused #include <linux/version.h> The first one that exists in both is: Staging: dt3155: fix 50Hz configuration Could the others be in a staging-stable branch? Regards, Hartley--
I do not know, they don't look to be something I've seen. thanks, greg k-h --
No, wait, I see these in my staging-next tree here. Some of them I wrote :) Are you sure you are cloning my tree properly? confused, greg k-h --
OK. I cloned your tree a different way this time. This time I did: $ git clone --reference ../linux-2.6 staging-2.6 Initialized empty Git repository in /home/bigguiness/src/git/z/staging-2.6/.git/ warning: You appear to have cloned an empty repository. $ cd staging-2.6 $ git remote add staging-2.6 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git $ git fetch staging-2.6 remote: Counting objects: 1541325, done. remote: Compressing objects: 100% (249801/249801), done. remote: Total 1541325 (delta 1283336), reused 1536966 (delta 1279192) Receiving objects: 100% (1541325/1541325), 342.86 MiB | 330 KiB/s, done. Resolving deltas: 100% (1283336/1283336), done. From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6 * [new branch] master -> staging-2.6/master * [new branch] staging-next -> staging-2.6/staging-next ... $ git branch -a remotes/staging-2.6/master remotes/staging-2.6/staging-next $ git checkout remotes/staging-2.6/staging-next Checking out files: 100% (32340/32340), done. Note: checking out 'remotes/staging-2.6/staging-next'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at e595eea... Staging: comedi: __user markup on comedi_fops.c Now it's different. Your staging-next tree appears to be missing these patches: Staging: dt3155: fix 50Hz configuration staging: fix dt3155 build Both of which change dt3155_drv.c and both of which are in Linus' tree and the next tree. I think this explains why you had issues with trying to merge my patch with the dt3155_drv.c file. But it still doesn't explain the problem with dt3155_io.c. All ...
I have, and they look to be there to me: http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-next-2.6.git;a=commit;h=4f923... So something must be odd on your side. thanks, greg k-h --
Yup, sorry, my mistake. staging-next is the name of your repository as well as a branch within your repository and git after git clone doesn't by default show all remote branches. $ git clone --reference=linux-2.6 \ git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git $ git branch -r origin/HEAD -> origin/master origin/master origin/staging-next I needed to add a git checkout origin/staging-next --
Yes, if you look, the staging-next branch starts on Linus's tree as of April 8 (just after 2.6.34-rc3). I don't merge back to Linus's tree a bunch, because that is not how it should be done. When I am going to That doesn't explain how you aren't seeing the correct stuff to base your patches off of though. Are you _sure_ you have the 'staging-next' branch of the tree checked out? thanks, greg k-h --
I may be seeing the correct stuff now in your staging-next tree just not Am I _sure_... No... Do I _think_ so... Yes... ;-) Would you like me to rebase the patch to staging-next to see? But, will this run into a similar problem with the two commits already in Linus' tree? If so I can just hold off again until everything catches up. Regards, Hartley--
Ah, ok, the issue is the merge is causing your patch to not apply to my No, I can handle that merge when it happens, quite fine. thanks, greg k-h --
The macros ReadMReg and WriteMReg are really just private versions of
the kernel's readl and writel functions. Use the kernel's functions
instead. And since ioremap returns a (void __iomem *) not a (u8 *),
change all the uses of dt3155_lbase to reflect this.
While here, make dt3155_lbase static since it is only used in the
dt3155_drv.c file. Also, remove the global variable dt3155_bbase
since it is not used anywhere in the code.
Where is makes sense, create a local 'mmio' variable instead of using
dt3155_lbase[minor] to make the code more readable.
This change also affects the {Read|Write}I2C functions so they are
also modified as needed.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Scott Smedley <ss@aao.gov.au>
---
Greg, here is the patch rebased to your staging-next tree.
The main issue I can see is a conflict with:
commit 6536560cabab170ed2969b005bf69a496e9c45bf
Staging: dt3155: fix 50Hz configuration
This patch modifies the same two lines that were changed by that patch.
diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index 993ed2f..8ebfe14 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -75,8 +75,8 @@ MODULE_LICENSE("GPL");
#include <linux/poll.h>
#include <linux/sched.h>
#include <linux/smp_lock.h>
+#include <linux/io.h>
-#include <asm/io.h>
#include <asm/uaccess.h>
#include "dt3155.h"
@@ -123,14 +123,12 @@ int dt3155_major = 0;
struct dt3155_status dt3155_status[MAXBOARDS];
/* kernel logical address of the board */
-u8 *dt3155_lbase[MAXBOARDS] = { NULL
+static void __iomem *dt3155_lbase[MAXBOARDS] = { NULL
#if MAXBOARDS == 2
, NULL
#endif
};
-/* DT3155 registers */
-u8 *dt3155_bbase = NULL; /* kernel logical address of the *
- * buffer region */
+
...Greg, Did this patch fair any better when trying to merge it? If there is still an issue I will wait until Linus' tree, linux-next, and your staging-next branch appear to be more in sync. Regards, Hartley--
Yes, please wait a bit, I really don't know what is going on here, sorry. greg k-h --
The macros ReadMReg and WriteMReg are really just private versions of
the kernel's readl and writel functions. Use the kernel's functions
instead. And since ioremap returns a (void __iomem *) not a (u8 *),
change all the uses of dt3155_lbase to reflect this.
While here, make dt3155_lbase static since it is only used in the
dt3155_drv.c file. Also, remove the global variable dt3155_bbase
since it is not used anywhere in the code.
Where is makes sense, create a local 'mmio' variable instead of using
dt3155_lbase[minor] to make the code more readable.
This change also affects the {Read|Write}I2C functions so they are
also modified as needed.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Scott Smedley <ss@aao.gov.au>
---
V2 - rebased to next-20100621
diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index dcd3849..88c9e59 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -64,8 +64,8 @@ extern void printques(int);
#include <linux/poll.h>
#include <linux/sched.h>
#include <linux/smp_lock.h>
+#include <linux/io.h>
-#include <asm/io.h>
#include <asm/uaccess.h>
#include "dt3155.h"
@@ -112,14 +112,12 @@ int dt3155_major = 0;
struct dt3155_status dt3155_status[MAXBOARDS];
/* kernel logical address of the board */
-u8 *dt3155_lbase[MAXBOARDS] = { NULL
+static void __iomem *dt3155_lbase[MAXBOARDS] = { NULL
#if MAXBOARDS == 2
, NULL
#endif
};
-/* DT3155 registers */
-u8 *dt3155_bbase = NULL; /* kernel logical address of the *
- * buffer region */
+
u32 dt3155_dev_open[MAXBOARDS] = {0
#if MAXBOARDS == 2
, 0
@@ -139,11 +137,11 @@ static void quick_stop (int minor)
{
// TODO: scott was here
#if 1
- ReadMReg((dt3155_lbase[minor] + ...You are still doing something odd, this one doesn't apply either. Is your email client messing something up? strange. greg k-h --
Hmm. I thought I had that worked out since I haven't had any problems lately.
Can you please try this one?
---
The macros ReadMReg and WriteMReg are really just private versions of
the kernel's readl and writel functions. Use the kernel's functions
instead. And since ioremap returns a (void __iomem *) not a (u8 *),
change all the uses of dt3155_lbase to reflect this.
While here, make dt3155_lbase static since it is only used in the
dt3155_drv.c file. Also, remove the global variable dt3155_bbase
since it is not used anywhere in the code.
Where is makes sense, create a local 'mmio' variable instead of using
dt3155_lbase[minor] to make the code more readable.
This change also affects the {Read|Write}I2C functions so they are
also modified as needed.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Scott Smedley <ss@aao.gov.au>
---
V2 - rebased to next-20100621
diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index dcd3849..88c9e59 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -64,8 +64,8 @@ extern void printques(int);
#include <linux/poll.h>
#include <linux/sched.h>
#include <linux/smp_lock.h>
+#include <linux/io.h>
-#include <asm/io.h>
#include <asm/uaccess.h>
#include "dt3155.h"
@@ -112,14 +112,12 @@ int dt3155_major = 0;
struct dt3155_status dt3155_status[MAXBOARDS];
/* kernel logical address of the board */
-u8 *dt3155_lbase[MAXBOARDS] = { NULL
+static void __iomem *dt3155_lbase[MAXBOARDS] = { NULL
#if MAXBOARDS == 2
, NULL
#endif
};
-/* DT3155 registers */
-u8 *dt3155_bbase = NULL; /* kernel logical address of the *
- * buffer region */
+
u32 dt3155_dev_open[MAXBOARDS] = {0
#if MAXBOARDS == 2
, 0
@@ -139,11 +137,11 ...Hunk #2 FAILED at 112. Hunk #7 succeeded at 214 with fuzz 2. Hunk #8 succeeded at 234 with fuzz 2. Hunk #9 FAILED at 252. Hunk #10 succeeded at 260 with fuzz 2. Hunk #12 succeeded at 313 with fuzz 2. Hunk #13 FAILED at 390. Hunk #14 succeeded at 405 with fuzz 2. Hunk #16 FAILED at 433. Hunk #17 FAILED at 451. Hunk #22 succeeded at 915 with fuzz 1. Hunk #23 succeeded at 1040 with fuzz 2. 5 out of 23 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_drv.c.rej patching file drivers/staging/dt3155/dt3155_drv.h patching file drivers/staging/dt3155/dt3155_io.c Hunk #2 FAILED at 77. Hunk #3 FAILED at 103. Hunk #4 FAILED at 119. Hunk #5 FAILED at 134. Hunk #6 FAILED at 151. 5 out of 6 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_io.c.rej patching file drivers/staging/dt3155/dt3155_io.h Reversed (or previously applied) patch detected! Assume -R? [n] not good... thanks, greg k-h --
Now I'm really confused.
~/src/git/linux-next $ patch --dry-run -p1 -i ../patches/dt3155_mmio_v2.patch
patching file drivers/staging/dt3155/dt3155_drv.c
patching file drivers/staging/dt3155/dt3155_drv.h
patching file drivers/staging/dt3155/dt3155_io.c
patching file drivers/staging/dt3155/dt3155_io.h
~/src/git/staging-next-2.6 $ patch --dry-run -p1 -i ../patches/dt3155_mmio_v2.patch
patching file drivers/staging/dt3155/dt3155_drv.c
Hunk #2 succeeded at 115 (offset 3 lines).
Hunk #3 succeeded at 140 (offset 3 lines).
Hunk #4 succeeded at 172 (offset 3 lines).
Hunk #5 succeeded at 189 (offset 3 lines).
Hunk #6 succeeded at 204 (offset 3 lines).
Hunk #7 succeeded at 215 (offset 3 lines).
Hunk #8 succeeded at 235 (offset 3 lines).
Hunk #9 succeeded at 253 (offset 3 lines).
Hunk #10 succeeded at 261 (offset 3 lines).
Hunk #11 succeeded at 278 (offset 3 lines).
Hunk #12 succeeded at 314 (offset 3 lines).
Hunk #13 succeeded at 391 (offset 3 lines).
Hunk #14 succeeded at 406 (offset 3 lines).
Hunk #15 succeeded at 423 (offset 3 lines).
Hunk #16 succeeded at 434 (offset 3 lines).
Hunk #17 succeeded at 449 (offset 3 lines).
Hunk #18 succeeded at 460 (offset 3 lines).
Hunk #19 succeeded at 482 (offset 3 lines).
Hunk #20 succeeded at 491 (offset 3 lines).
Hunk #21 succeeded at 706 (offset 2 lines).
Hunk #22 succeeded at 908 (offset 2 lines).
Hunk #23 succeeded at 1033 (offset 2 lines).
patching file drivers/staging/dt3155/dt3155_drv.h
patching file drivers/staging/dt3155/dt3155_io.c
patching file drivers/staging/dt3155/dt3155_io.h
Locally the patch applies fine against linux-next (next-20100622). And it applies
against your staging-next tree with some fuzz due to the following commits not in
that tree.
commit a46f9087e634224b3d0a6560e223425816846dff
Author: H Hartley Sweeten <hartleys@visionengravers.com>
Date: Tue Jun 8 10:36:57 2010 -0500
Staging: dt3155: remove DT_3155_* errno defines
commit 0f3ff30b9384ffa1b435f263234531582080b100
Author: H Hartley Sweeten ...