RE: [PATCH V8 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core InterfaceLayer
[Marri] If u32 is 8bytes isn't pointer type would be 8bytes as well. If u32 is 8bytes 'char' would only be 4 bits! (IIRC the X code has a fubar that requires a type with 32 in its name to be 64 bits!) David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] ftrace, powerpc: Implement raw syscall tracepoints on PowerPC
On Mon, 2011-02-07 at 21:10 -0500, Steven Rostedt wrote:
Ben,
How do you want to work this? Do you want to ack it and I take this
patch with the others through the tracing tree, or do you want to wait
till the tracing tree gets updated into mainline and then pull this in
though the ppc tree. As this touches a bit of the ppc side.
I was waiting to see what you were up to vs. the rest of the series :-)
I still need to review that one closely, at which point I'm happy for
you to take it.
Cheers,
Ben.
-- Steve
On Thu, 2011-02-03 at 14:27 +1100, Ian Munsie wrote:
From: Ian Munsie imun...@au.ibm.com
This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within the 16 bits of the andi. instruction's UI field. The instructions
in question are in /arch/powerpc/kernel/entry_{32,64}.S to and the
_TIF_SYSCALL_T_OR_A with the thread flags to see if system call tracing
is enabled.
In the case of 64bit PowerPC, arch_syscall_addr and
arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
work given the unusual system call table structure and symbol names that
start with a period.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
---
arch/powerpc/Kconfig |1 +
arch/powerpc/include/asm/ftrace.h | 14 ++
arch/powerpc/include/asm/syscall.h |5 +
arch/powerpc/include/asm/thread_info.h |7 +--
arch/powerpc/kernel/Makefile |1 +
arch/powerpc/kernel/ftrace.c |8
arch/powerpc/kernel/ptrace.c | 10 ++
7 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7d69e9b..a0e8e02 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -134,6 +134,7 @@ config PPC
select HAVE_GENERIC_HARDIRQS
select HAVE_SPARSE_IRQ
select IRQ_PER_CPU
+ select HAVE_SYSCALL_TRACEPOINTS
config EARLY_PRINTK
bool
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index dde1296..169d039 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -60,4 +60,18 @@ struct dyn_arch_ftrace {
#endif
+#if defined(CONFIG_FTRACE_SYSCALLS) defined(CONFIG_PPC64)
!defined(__ASSEMBLY__)
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+static inline bool arch_syscall_match_sym_name(const char *sym, const char
*name)
+{
+ /*
+* Compare the symbol name with the system call name. Skip the .sys or
.SyS
+* prefix from the symbol name and the sys prefix from the system call
name and
+* just match the rest. This is only needed on ppc64 since symbol names
on
+* 32bit do not start with a period so the generic function will work.
+*/
+ return !strcmp(sym + 4, name + 3);
+}
+#endif /* CONFIG_FTRACE_SYSCALLS CONFIG_PPC64 !__ASSEMBLY__ */
+
#endif /* _ASM_POWERPC_FTRACE */
diff --git a/arch/powerpc/include/asm/syscall.h
b/arch/powerpc/include/asm/syscall.h
index 23913e9..b54b2ad 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -15,6 +15,11 @@
#include linux/sched.h
+/* ftrace syscalls requires exporting the sys_call_table */
+#ifdef CONFIG_FTRACE_SYSCALLS
+extern const unsigned long *sys_call_table;
+#endif /* CONFIG_FTRACE_SYSCALLS */
+
static inline long syscall_get_nr(struct task_struct *task,
struct pt_regs *regs)
{
diff --git a/arch/powerpc/include/asm/thread_info.h
b/arch/powerpc/include/asm/thread_info.h
index 65eb859..4403f09 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -110,7 +110,8 @@ static inline struct thread_info
*current_thread_info(void)
#define TIF_NOERROR12 /* Force successful syscall
return */
#define TIF_NOTIFY_RESUME 13 /* callback before returning to user */
#define TIF_FREEZE 14 /* Freezing for suspend */
-#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
+#define TIF_SYSCALL_TRACEPOINT 15 /* syscall tracepoint
instrumentation */
+#define TIF_RUNLATCH 16 /* Is the runlatch enabled? */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1TIF_SYSCALL_TRACE)
@@ -127,8 +128,10 @@ static inline struct thread_info
*current_thread_info(void)
#define _TIF_NOERROR (1TIF_NOERROR)
#define _TIF_NOTIFY_RESUME (1TIF_NOTIFY_RESUME)
#define _TIF_FREEZE(1TIF_FREEZE)
+#define _TIF_SYSCALL_TRACEPOINT(1TIF_SYSCALL_TRACEPOINT)
#define _TIF_RUNLATCH
Re: [PATCH] PM: Hide CONFIG_PM from users
On Mon, Feb 07, 2011 at 05:17:59PM -0800, Ray Lee wrote: On Mon, Feb 7, 2011 at 7:49 AM, Mark Brown I'm rather hoping that they'll notice the mailing list thread or that someone else who knows what's going on with them does Surely you're joking. I mean, do _you_ scan every message that comes through lkml and its various sister lists? Actually I do at least scan most of the lists. Do a git blame and add them to the CC:. It's the polite thing to do. It's also going to result in the mail not going to the mailing lists as there's a limit on the number of people you can CC enforced by vger which probably isn't constructive. It's moot now but as I said in the text you've helpfully cut I'd have suggested contacting them after the thread had come to a conclusion. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V9 09/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
Hello. On 08.02.2011 1:54, tma...@apm.com wrote: From: Tirumala Marritma...@apm.com Enable gadget support Signed-off-by: Tirumala R Marritma...@apm.com Signed-off-by: Fushen Chenfc...@apm.com Signed-off-by: Mark Miesfeldmmiesf...@apm.com --- drivers/usb/gadget/Kconfig| 22 ++ drivers/usb/gadget/gadget_chips.h |9 + 2 files changed, 31 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 5df8a8d..de7c10b 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -365,6 +365,28 @@ config USB_GADGET_MUSB_HDRC This OTG-capable silicon IP is used in dual designs including the TI DaVinci, OMAP 243x, OMAP 343x, TUSB 6010, and ADI Blackfin +# dwc_otg builds in ../dwc_otg along with host support +config USB_GADGET_DWC_HDRC + boolean DesignWare USB Peripheral + depends on DWC_OTG_MODE || DWC_DEVICE_ONLY Patch 10 should precede this one as it defines DWC_OTG_MODE and DWC_DEVICE_ONLY. + select USB_GADGET_DUALSPEED + select USB_GADGET_SELECTED + select USB_GADGET_DWC_OTG + help + This OTG-capable Designware USB IP + +config USB_GADGET_DWC_OTG + boolean OTG Support + depends on USB_GADGET_DWC_HDRC What's the point of this option if it gets auto-selected by USB_GADGET_DWC_HDRC anyway? WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc: Add IO event interrupt support
On Tue, 2011-02-08 at 08:46 +1100, Benjamin Herrenschmidt wrote: On Mon, 2011-02-07 at 15:40 -0600, Tseng-Hui (Frank) Lin wrote: We are -really- re-inventing interrupts and/or notifiers here, which I find a tad annoying.. Agree. This is ugly. We could have just used the regular interrupt mechanism if the firmware didn't use shared rtas call and interrupt to report multiple types of events. A notifier wouldn't have worked ? Yes. A notifier should have worked. Will change to use a notifier for the chain. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc: Removing support for 'protected-sources'
-Original Message- From: devicetree-discuss- bounces+stuart.yoder=freescale@lists.ozlabs.org [mailto:devicetree- discuss-bounces+stuart.yoder=freescale@lists.ozlabs.org] On Behalf Of Benjamin Herrenschmidt Sent: Monday, February 07, 2011 3:46 PM To: Meador Inge Cc: Hollis Blanchard; devicetree-disc...@lists.ozlabs.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v3 1/4] powerpc: Removing support for 'protected- sources' In my previous reply I said that it is not so much as a need as it is a potential simplification. After further reflection, I don't think that is completely true. As we get into AMP systems with higher core counts, then implementing this functionality using the existing protected-sources implementation versus the new pic-no-reset work is going to be harder to maintain. I'm not arguing that your approach isn't more suitable for AMP systems, I just want to leave the existing protected-sources mechanism alone. I'm not opposing adding a new, better, mechanism for newer platforms. However, I'd name it differently. pic-no-reset doesn't carry enough meaning in that case. What we want to point out here is that the PIC has been pre-initialized. Another option, which may be cleaner, is to stick to no-reset (no need for pic- prefix) and make it do just that (prevent the reset), and then use a positive variant of protected-sources, call it allowed-sources. Maybe even make it a series of ranges. Then have the MPIC only access these. I think this is more robust as it would also prevent accidental use of the wrong sources (bad device-tree, drivers that let you muck around with irq numbers, etc...). What is the use case for allowed-sources? For AMP the only device nodes in your device tree should be your AMP partition's devices, thus any interrupt specifiers in your dev tree are allowed. The MPIC is a shared device and thus the need for no-reset. So, all newer platforms should need is no-reset. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] watchdog: booke_wdt: clean up status messages
Benjamin Herrenschmidt wrote: If you're going to cleanup the messages, then I think displaying: PowerPC Book-E Watchdog Timer Loaded booke_wdt: watchdog enabled (timeout = xxx sec) Isn't very nice. Lacks consistency ... you can prefix both lines the same way, or maybe better print only one line with all the necessary info. Yeah, I see your point. I'll post a v2. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] ftrace, powerpc: Implement raw syscall tracepoints on PowerPC
On Tue, 2011-02-08 at 21:07 +1100, Benjamin Herrenschmidt wrote: On Mon, 2011-02-07 at 21:10 -0500, Steven Rostedt wrote: Ben, How do you want to work this? Do you want to ack it and I take this patch with the others through the tracing tree, or do you want to wait till the tracing tree gets updated into mainline and then pull this in though the ppc tree. As this touches a bit of the ppc side. I was waiting to see what you were up to vs. the rest of the series :-) I still need to review that one closely, at which point I'm happy for you to take it. It survived my tests, I'm continuing with other patches for 39 and I have no problem with Ian's patches. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Question on supporting multiple HW versions with a single driver (warning: long post)
Ah, okay. Taking a look at that it makes sense now. Thanks to both of you for the help. Bruce From: Bill Gatliff b...@billgatliff.com To: bruce_leon...@selinc.com Cc: David Gibson da...@gibson.dropbear.id.au, linuxppc-dev@lists.ozlabs.org Date: 02/07/2011 09:13 PM Subject: Re: Question on supporting multiple HW versions with a single driver (warning: long post) Guys: I think the Silicon Motion SM501 driver might provide a useful example, since the chip comes in both memory-mapped and PCI versions. Unfortunately the chip is implemented as a multi-function driver (mfd), so the code is not un-complicated. Still fairly straightforward and well-written once you learn your way around it, though. Basically, it implements a core set of functionality to talk to the actual chip registers, which is bus-agnostic. Then the bus-specific drivers use these functions when they actually want to touch the chip itself. In other words, exactly what David suggested. b.g. On Mon, Feb 7, 2011 at 8:37 PM, bruce_leon...@selinc.com wrote: There are a number of drivers which already have this sort of dual bus binding. Thanks for the feedback David, I appreciate it. Could you point me to one of those drivers that has this sort of dual bus binding so can see an example of what I'm trying to do? Bruce ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] misc: add CARMA DATA-FPGA Access Driver
On Mon, Feb 07, 2011 at 11:33:10PM -0800, Dmitry Torokhov wrote: Hi Ira, On Mon, Feb 07, 2011 at 03:23:40PM -0800, Ira W. Snyder wrote: This driver allows userspace to access the data processing FPGAs on the OVRO CARMA board. It has two modes of operation: 1) random access This allows users to poke any DATA-FPGA registers by using mmap to map the address region directly into their memory map. 2) correlation dumping When correlating, the DATA-FPGA's have special requirements for getting the data out of their memory before the next correlation. This nominally happens at 64Hz (every 15.625ms). If the data is not dumped before the next correlation, data is lost. The data dumping driver handles buffering up to 1 second worth of correlation data from the FPGAs. This lowers the realtime scheduling requirements for the userspace process reading the device. Kind of a fly-by review but it looks like the locking in the driver needs work. Hi Dmitry, Thanks for the review. I have a few comments inline below. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu --- drivers/misc/Kconfig|1 + drivers/misc/Makefile |1 + drivers/misc/carma/Kconfig |9 + drivers/misc/carma/Makefile |1 + drivers/misc/carma/carma-fpga.c | 1446 +++ 5 files changed, 1458 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/carma/Kconfig create mode 100644 drivers/misc/carma/Makefile create mode 100644 drivers/misc/carma/carma-fpga.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 4d073f1..f457f14 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -457,5 +457,6 @@ source drivers/misc/eeprom/Kconfig source drivers/misc/cb710/Kconfig source drivers/misc/iwmc3200top/Kconfig source drivers/misc/ti-st/Kconfig +source drivers/misc/carma/Kconfig endif # MISC_DEVICES diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 98009cc..2c1610e 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -42,3 +42,4 @@ obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o obj-$(CONFIG_PCH_PHUB) += pch_phub.o obj-y += ti-st/ obj-$(CONFIG_AB8500_PWM) += ab8500-pwm.o +obj-y += carma/ diff --git a/drivers/misc/carma/Kconfig b/drivers/misc/carma/Kconfig new file mode 100644 index 000..4be183f --- /dev/null +++ b/drivers/misc/carma/Kconfig @@ -0,0 +1,9 @@ +config CARMA_FPGA + tristate CARMA DATA-FPGA Access Driver + depends on FSL_SOC PPC_83xx MEDIA_SUPPORT HAS_DMA FSL_DMA + select VIDEOBUF_DMA_SG + default n + help + Say Y here to include support for communicating with the data + processing FPGAs on the OVRO CARMA board. + diff --git a/drivers/misc/carma/Makefile b/drivers/misc/carma/Makefile new file mode 100644 index 000..0b69fa7 --- /dev/null +++ b/drivers/misc/carma/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CARMA_FPGA) += carma-fpga.o diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c new file mode 100644 index 000..52620b3 --- /dev/null +++ b/drivers/misc/carma/carma-fpga.c @@ -0,0 +1,1446 @@ +/* + * CARMA DATA-FPGA Access Driver + * + * Copyright (c) 2009-2010 Ira W. Snyder i...@ovro.caltech.edu + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +/* + * FPGA Memory Dump Format + * + * FPGA #0 control registers (32 x 32-bit words) + * FPGA #1 control registers (32 x 32-bit words) + * FPGA #2 control registers (32 x 32-bit words) + * FPGA #3 control registers (32 x 32-bit words) + * SYSFPGA control registers (32 x 32-bit words) + * FPGA #0 correlation array (NUM_CORL0 correlation blocks) + * FPGA #1 correlation array (NUM_CORL1 correlation blocks) + * FPGA #2 correlation array (NUM_CORL2 correlation blocks) + * FPGA #3 correlation array (NUM_CORL3 correlation blocks) + * + * Each correlation array consists of: + * + * Correlation Data (2 x NUM_LAGSn x 32-bit words) + * Pipeline Metadata (2 x NUM_METAn x 32-bit words) + * Quantization Counters (2 x NUM_QCNTn x 32-bit words) + * + * The NUM_CORLn, NUM_LAGSn, NUM_METAn, and NUM_QCNTn values come from + * the FPGA configuration registers. They do not change once the FPGA's + * have been programmed, they only change on re-programming. + */ + +/* + * Basic Description: + * + * This driver is used to capture correlation spectra off of the four data + * processing FPGAs. The FPGAs are often reprogrammed at runtime, therefore + * this driver supports dynamic
Re: [PATCH 1/2] misc: add CARMA DATA-FPGA Access Driver
On Tue, Feb 08, 2011 at 09:20:46AM -0800, Ira W. Snyder wrote: +static DEVICE_ATTR(enable, S_IWUGO | S_IRUGO, data_en_show, data_en_set); Are all of these really needed or most of them are for debug? Most are for debugging. They have proved useful a few times in production to track down bugs. File mode should probably not be world writable. (checkpatch.pl should warn you about this now btw) Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] misc: add CARMA DATA-FPGA Access Driver
On Tue, Feb 08, 2011 at 09:20:46AM -0800, Ira W. Snyder wrote:
On Mon, Feb 07, 2011 at 11:33:10PM -0800, Dmitry Torokhov wrote:
+static void data_free_buffer(struct device *dev, struct data_buf *buf)
+{
+ /* It is ok to free a NULL buffer */
+ if (!buf)
+ return;
+
+ /* Make sure the buffer is not on any list */
+ list_del_init(buf-entry);
And what happens if it is? Should it be WARN_ON(!list_empty()) instead?
This was only defensive programming. Everywhere this function is called,
the buffer has already been removed from the list.
I am concerned as sometimes defencive programming is the sign that we
arenot quite sure how the code works. I believe defensive programming
should be used when providing library-like code, not in local cases.
+
+ list_for_each_entry_safe(buf, tmp, priv-free, entry) {
+ list_del_init(buf-entry);
+ spin_unlock_irq(priv-lock);
+ data_free_buffer(priv-dev, buf);
+ spin_lock_irq(priv-lock);
+ }
This is messed up. If there is concurrent access to the free list then
it is not safe to continue iterating list after releasing the lock, you
need to do:
spin_lock_irq(priv-lock);
while (!list_empty(priv-free)) {
buf = list_first_entry(priv-free, struct data_buf, entry);
list_del_init(buf-entry);
spin_unlock_irq(priv-lock);
data_free_buffer(priv-dev, buf);
spin_lock_irq(priv-lock);
}
BUT, the function is only called when you disable (or fail to enable) device
which, at this point, should be quiesced, thus all this locking is not
really needed.
Correct.
I thought it would be clearer to reviewers if I always used the lock to
protect a data structure, even when it isn't technically needed.
No, locks should protect wehat needs to be protected. The rest just
muddles water.
+
+ spin_lock_irq(priv-lock);
+ while (!list_empty(list)) {
+ spin_unlock_irq(priv-lock);
+
+ ret = wait_event_interruptible(priv-wait, list_empty(list));
+ if (ret)
+ return -ERESTARTSYS;
+
+ spin_lock_irq(priv-lock);
+ }
+ spin_unlock_irq(priv-lock);
Locking is not needed - if you disable interrupyts what would put more
stuff on the list?
The locking is definitely needed.
You've missed a critical piece of information. There are *two* devices
we are interacting with here, and BOTH generate interrupts.
No, I did not miss this fact. The point is that when we get to this code
the device _putting_ items on wauiting list is stopped and we only need
to wait for the list to drain. Nobody puts more stuff on it. You can
check fir list_empty() condition without locking.
And if someone _is_ putting more stuff on the list - you are screwed
since list may become non-empty the moment you release the lock.
+
+static ssize_t data_num_buffers_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct fpga_device *priv = dev_get_drvdata(dev);
+ unsigned int num;
+
+ spin_lock_irq(priv-lock);
+ num = priv-num_buffers;
+ spin_unlock_irq(priv-lock);
This spin lock is pointless, priv-num_buffers might be already changed
here, you can't guarantee that you show accurate data.
Correct, I know this. I just wanted to protect the data structure at all
points of use in the driver.
Protect from what? integer reads are guaranteed to be complete and you
are not concerned with missing updates as information is obsolete the
moment you release trhe lock.
Would an atomic_t be better for this, or
should I just remove the locking completely?
Just remove the locking.
+
+ if (mutex_lock_interruptible(priv-mutex))
+ return -ERESTARTSYS;
Why don't
error = mutex_lock_interruptible(priv-mutex);
if (error)
return error;
- do not clobber perfectly valid error codes.
That's what the Linux Device Drivers 3rd Edition book does. See page
112. I will change it to fix the return code.
LDD3 is quite old by now...
+
+static struct attribute *data_sysfs_attrs[] = {
+ dev_attr_num_buffers.attr,
+ dev_attr_buffer_size.attr,
+ dev_attr_num_inflight.attr,
+ dev_attr_num_free.attr,
+ dev_attr_num_used.attr,
+ dev_attr_num_dropped.attr,
+ dev_attr_enable.attr,
+ NULL,
+};
Are all of these really needed or most of them are for debug?
Most are for debugging. They have proved useful a few times in
production to track down bugs.
Consider switching over to debugfs then. Or, if you believe the device
is sufficiently bug-free just cut the code.
+
+static ssize_t data_read(struct file *filp, char __user *ubuf, size_t
count,
+ loff_t *f_pos)
+{
+ struct fpga_reader *reader = filp-private_data;
+ struct fpga_device *priv =
Re: [PATCH V9 10/10] USB ppc4xx: Add Synopsys DWC OTG driver kernel configuration and Makefile
Hello. tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com Add Synopsys DesignWare HS USB OTG driver kernel configuration. Synopsys OTG driver may operate in host only, device only, or OTG mode. The driver also allows user configure the core to use its internal DMA or Slave (PIO) mode. Signed-off-by: Tirumala R Marri tma...@apm.com Signed-off-by: Fushen Chen fc...@apm.com Signed-off-by: Mark Miesfeld mmiesf...@apm.com [...] diff --git a/drivers/Makefile b/drivers/Makefile index 2cbb4b7..3bfc728 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_PARIDE) += block/paride/ obj-$(CONFIG_TC) += tc/ obj-$(CONFIG_UWB) += uwb/ obj-$(CONFIG_USB_OTG_UTILS)+= usb/otg/ +obj-$(CONFIG_USB_DWC_OTG) += usb/otg/dwc/ Hardly a good place for this... obj-$(CONFIG_USB) += usb/ obj-$(CONFIG_USB_MUSB_HDRC)+= usb/musb/ obj-$(CONFIG_PCI) += usb/ @@ -105,6 +106,7 @@ obj-$(CONFIG_ARCH_SHMOBILE) += sh/ ifndef CONFIG_ARCH_USES_GETTIMEOFFSET obj-y += clocksource/ endif +obj-$(CONFIG_DMA_ENGINE) += dma/ How is this change related? Moreover, it's already present several lines ago in this file... diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 41b6e51..887f702 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -55,7 +55,6 @@ config USB_ARCH_HAS_OHCI config USB_ARCH_HAS_EHCI boolean default y if PPC_83xx - default y if PPC_MPC512x How is this change related? diff --git a/drivers/usb/otg/dwc/Kconfig b/drivers/usb/otg/dwc/Kconfig new file mode 100644 index 000..4d33d72 --- /dev/null +++ b/drivers/usb/otg/dwc/Kconfig @@ -0,0 +1,96 @@ +# +# USB Dual Role (OTG-ready) Controller Drivers +# for silicon based on Synopsys DesignWare IP +# + +comment Enable Host or Gadget support for DesignWare OTG controller + depends on !USB USB_GADGET=n + +config USB_DWC_OTG + depends on (USB || USB_GADGET) Parens not necessary. + select NOP_USB_XCEIV + select USB_OTG_UTILS + tristate Synopsys DWC OTG Controller tristate should come before depends I think -- at least that's how everybody does... + default USB_GADGET + help + This driver provides USB Device Controller support for the + Synopsys DesignWare USB OTG Core used on the AppliedMicro PowerPC SoC. [...] +choice + prompt DWC Mode Selection + depends on USB_DWC_OTG + default DWC_HOST_ONLY + help + Select the DWC Core in OTG, Host only, or Device only mode. + +config DWC_HOST_ONLY + bool DWC Host Only Mode + +config DWC_OTG_MODE + bool DWC OTG Mode + select USB_GADGET_SELECTED + +config DWC_DEVICE_ONLY + bool DWC Device Only Mode + select USB_GADGET_SELECTED + +endchoice So this is tri-modal driver after all... how come we place it in drivers/usb/otg/dwc/, while the same tri-modal MUSB driver was placed in drivers/usb/musb/? +config USB_OTG_WHITELIST + bool Rely on OTG Targeted Peripherals List + depends on !USB_SUSPEND USB_DWC_OTG + default n + help + This is the same flag as in ../core/Kconfig. + It is here for easy deselect. What?! Option duplication isn't allowed, I think. +config DWC_OTG_REG_LE + depends on USB_DWC_OTG + bool DWC Little Endian Register bool should come before depends, I think. + default y + help + OTG core register access is Little-Endian. + +config DWC_OTG_FIFO_LE + depends on USB_DWC_OTG + bool DWC FIFO Little Endian Same here. + default n + help + OTG core FIFO access is Little-Endian. + +config DWC_LIMITED_XFER_SIZE + depends on USB_GADGET_DWC_HDRC + bool DWC Endpoint Limited Xfer Size ... and here. + default n + help + Bit fields in the Device EP Transfer Size Register is 11 bits. s/is/are/ Also, such things should better be passed via the platform data, I think. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] misc: add CARMA DATA-FPGA Access Driver
On Tue, Feb 08, 2011 at 09:50:29AM -0800, Dmitry Torokhov wrote:
On Tue, Feb 08, 2011 at 09:20:46AM -0800, Ira W. Snyder wrote:
On Mon, Feb 07, 2011 at 11:33:10PM -0800, Dmitry Torokhov wrote:
+static void data_free_buffer(struct device *dev, struct data_buf *buf)
+{
+ /* It is ok to free a NULL buffer */
+ if (!buf)
+ return;
+
+ /* Make sure the buffer is not on any list */
+ list_del_init(buf-entry);
And what happens if it is? Should it be WARN_ON(!list_empty()) instead?
This was only defensive programming. Everywhere this function is called,
the buffer has already been removed from the list.
I am concerned as sometimes defencive programming is the sign that we
arenot quite sure how the code works. I believe defensive programming
should be used when providing library-like code, not in local cases.
Ok.
+
+ list_for_each_entry_safe(buf, tmp, priv-free, entry) {
+ list_del_init(buf-entry);
+ spin_unlock_irq(priv-lock);
+ data_free_buffer(priv-dev, buf);
+ spin_lock_irq(priv-lock);
+ }
This is messed up. If there is concurrent access to the free list then
it is not safe to continue iterating list after releasing the lock, you
need to do:
spin_lock_irq(priv-lock);
while (!list_empty(priv-free)) {
buf = list_first_entry(priv-free, struct data_buf, entry);
list_del_init(buf-entry);
spin_unlock_irq(priv-lock);
data_free_buffer(priv-dev, buf);
spin_lock_irq(priv-lock);
}
BUT, the function is only called when you disable (or fail to enable)
device
which, at this point, should be quiesced, thus all this locking is not
really needed.
Correct.
I thought it would be clearer to reviewers if I always used the lock to
protect a data structure, even when it isn't technically needed.
No, locks should protect wehat needs to be protected. The rest just
muddles water.
Ok.
+
+ spin_lock_irq(priv-lock);
+ while (!list_empty(list)) {
+ spin_unlock_irq(priv-lock);
+
+ ret = wait_event_interruptible(priv-wait,
list_empty(list));
+ if (ret)
+ return -ERESTARTSYS;
+
+ spin_lock_irq(priv-lock);
+ }
+ spin_unlock_irq(priv-lock);
Locking is not needed - if you disable interrupyts what would put more
stuff on the list?
The locking is definitely needed.
You've missed a critical piece of information. There are *two* devices
we are interacting with here, and BOTH generate interrupts.
No, I did not miss this fact. The point is that when we get to this code
the device _putting_ items on wauiting list is stopped and we only need
to wait for the list to drain. Nobody puts more stuff on it. You can
check fir list_empty() condition without locking.
And if someone _is_ putting more stuff on the list - you are screwed
since list may become non-empty the moment you release the lock.
Ok, I understand what you mean now. You are correct, nothing else can
add things to the list. Thanks for clarifying this for me. :)
+
+static ssize_t data_num_buffers_show(struct device *dev,
+struct device_attribute *attr,
char *buf)
+{
+ struct fpga_device *priv = dev_get_drvdata(dev);
+ unsigned int num;
+
+ spin_lock_irq(priv-lock);
+ num = priv-num_buffers;
+ spin_unlock_irq(priv-lock);
This spin lock is pointless, priv-num_buffers might be already changed
here, you can't guarantee that you show accurate data.
Correct, I know this. I just wanted to protect the data structure at all
points of use in the driver.
Protect from what? integer reads are guaranteed to be complete and you
are not concerned with missing updates as information is obsolete the
moment you release trhe lock.
Would an atomic_t be better for this, or
should I just remove the locking completely?
Just remove the locking.
Ok.
+
+ if (mutex_lock_interruptible(priv-mutex))
+ return -ERESTARTSYS;
Why don't
error = mutex_lock_interruptible(priv-mutex);
if (error)
return error;
- do not clobber perfectly valid error codes.
That's what the Linux Device Drivers 3rd Edition book does. See page
112. I will change it to fix the return code.
LDD3 is quite old by now...
I know, but it is still the best written reference I have. Reviewers
like yourself are better, but I can't look up your advice in a book. :)
I'll return the error code.
+
+static struct attribute *data_sysfs_attrs[] = {
+ dev_attr_num_buffers.attr,
+
help debugging linux setting PLX Gen2 PCIe switches to gen1 speed
I've got a custom 460SX board with PLX gen2 (8616) switches. When u-boot comes up everything is fine and my switches are indicating they are in Gen2 PCIe mode. If I let it boot my linux kernel (denx 2.6.36.1), boot almost immediately, the LEDs on my switches start to blink indicating they have are now at Gen1 speed. I've turned on debug in ppc4xx_pci.c but don't see anything obvious. As far as when it happens, it looks like the last message to the console is uncompressing kernel and then the LEDs start blinking. seems that it indicates it is very early. I've also tried removing all the PCIe from the device tree, but that did not matter. In the data sheet it indicates that PEDSRn_RCEI can change the advertised rate. I've disabled that in the code, but it did not make any difference. I am just not sure where things are getting switched over. Any help would be appreciated. best ayman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] misc: add CARMA DATA-FPGA Access Driver
On Tue, Feb 08, 2011 at 11:11:44AM -0800, Ira W. Snyder wrote: On Tue, Feb 08, 2011 at 09:50:29AM -0800, Dmitry Torokhov wrote: On Tue, Feb 08, 2011 at 09:20:46AM -0800, Ira W. Snyder wrote: Go back and re-think my loop. This is a common idiom straight of out LDD3 pages 153-154. You should note that it is only possible to exit the loop with the lock held AND !list_empty(used). The lock protects the used list, and therefore, there must be a buffer on the list. No, because you are woken up while not holding the lock so another reader is free to take it off the list. Correct. But then I go around the loop and check list_empty() again before exiting the loop. The list MUST NOT be empty before the loop will terminate. Yes, you are right, I competely missed the fact that we'd loop around and check the condition again. I'll go grab another coffee now. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFCv5 0/2] CARMA Board Support
Hello everyone, This is the fifth posting of these drivers, taking into account comments from earlier postings. I would appreciate as much review as you can offer. RFCv4 - RFCv5: - remove unecessary locking per review comments - do not clobber return values from *_interruptible() - explicitly track buffer DMA mapping - use #defines instead of raw hex addresses - change enable sysfs attribute to root-writeable only RFCv3 - RFCv4: - updates for DATA-FPGA version 2 RFCv2 - RFCv3: - use miscdevice framework (removing the carma class) - add bitfile readback capability to the programmer RFCv1 - RFCv2: - change comments to kerneldoc format - Kconfig improvements - use the videobuf_dma_sg API in the programmer - updates for Freescale DMAEngine DMA_SLAVE API changes Information about the CARMA board: The CARMA board is essentially an MPC8349EA MDS reference design with a 1GHz ADC and 4 high powered data processing FPGAs connected to the local bus. It is all packed into a compact PCI form factor. It is used at the Owens Valley Radio Observatory as the main component in the correlator system. For board information, see: http://www.mmarray.org/~dwh/carma_board/index.html For DATA-FPGA register layout, see: http://www.mmarray.org/memos/carma_memo46.pdf These drivers are the necessary pieces to get the data processing FPGAs working and producing data. Despite the fact that the hardware is custom and we are the only users, I'd still like to get the drivers upstream. Several people have suggested that this is possible. Some further patches will be forthcoming. I have a driver for the LED subsystem and the PPS subsystem. The LED register layout is expected to change soon, so I won't post the driver until that is finished. The PPS driver will be posted seperately from this patch series; it is very generic. Thanks to everyone who has provided comments on earlier versions! Ira W. Snyder (2): misc: add CARMA DATA-FPGA Access Driver misc: add CARMA DATA-FPGA Programmer support drivers/misc/Kconfig|1 + drivers/misc/Makefile |1 + drivers/misc/carma/Kconfig | 18 + drivers/misc/carma/Makefile |2 + drivers/misc/carma/carma-fpga-program.c | 1084 drivers/misc/carma/carma-fpga.c | 1396 +++ 6 files changed, 2502 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/carma/Kconfig create mode 100644 drivers/misc/carma/Makefile create mode 100644 drivers/misc/carma/carma-fpga-program.c create mode 100644 drivers/misc/carma/carma-fpga.c -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] misc: add CARMA DATA-FPGA Access Driver
This driver allows userspace to access the data processing FPGAs on the OVRO CARMA board. It has two modes of operation: 1) random access This allows users to poke any DATA-FPGA registers by using mmap to map the address region directly into their memory map. 2) correlation dumping When correlating, the DATA-FPGA's have special requirements for getting the data out of their memory before the next correlation. This nominally happens at 64Hz (every 15.625ms). If the data is not dumped before the next correlation, data is lost. The data dumping driver handles buffering up to 1 second worth of correlation data from the FPGAs. This lowers the realtime scheduling requirements for the userspace process reading the device. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu --- drivers/misc/Kconfig|1 + drivers/misc/Makefile |1 + drivers/misc/carma/Kconfig |9 + drivers/misc/carma/Makefile |1 + drivers/misc/carma/carma-fpga.c | 1396 +++ 5 files changed, 1408 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/carma/Kconfig create mode 100644 drivers/misc/carma/Makefile create mode 100644 drivers/misc/carma/carma-fpga.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index cc8e49d..93cf1e6 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -457,5 +457,6 @@ source drivers/misc/eeprom/Kconfig source drivers/misc/cb710/Kconfig source drivers/misc/iwmc3200top/Kconfig source drivers/misc/ti-st/Kconfig +source drivers/misc/carma/Kconfig endif # MISC_DEVICES diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 98009cc..2c1610e 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -42,3 +42,4 @@ obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o obj-$(CONFIG_PCH_PHUB) += pch_phub.o obj-y += ti-st/ obj-$(CONFIG_AB8500_PWM) += ab8500-pwm.o +obj-y += carma/ diff --git a/drivers/misc/carma/Kconfig b/drivers/misc/carma/Kconfig new file mode 100644 index 000..4be183f --- /dev/null +++ b/drivers/misc/carma/Kconfig @@ -0,0 +1,9 @@ +config CARMA_FPGA + tristate CARMA DATA-FPGA Access Driver + depends on FSL_SOC PPC_83xx MEDIA_SUPPORT HAS_DMA FSL_DMA + select VIDEOBUF_DMA_SG + default n + help + Say Y here to include support for communicating with the data + processing FPGAs on the OVRO CARMA board. + diff --git a/drivers/misc/carma/Makefile b/drivers/misc/carma/Makefile new file mode 100644 index 000..0b69fa7 --- /dev/null +++ b/drivers/misc/carma/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CARMA_FPGA) += carma-fpga.o diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c new file mode 100644 index 000..4ea473a --- /dev/null +++ b/drivers/misc/carma/carma-fpga.c @@ -0,0 +1,1396 @@ +/* + * CARMA DATA-FPGA Access Driver + * + * Copyright (c) 2009-2011 Ira W. Snyder i...@ovro.caltech.edu + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +/* + * FPGA Memory Dump Format + * + * FPGA #0 control registers (32 x 32-bit words) + * FPGA #1 control registers (32 x 32-bit words) + * FPGA #2 control registers (32 x 32-bit words) + * FPGA #3 control registers (32 x 32-bit words) + * SYSFPGA control registers (32 x 32-bit words) + * FPGA #0 correlation array (NUM_CORL0 correlation blocks) + * FPGA #1 correlation array (NUM_CORL1 correlation blocks) + * FPGA #2 correlation array (NUM_CORL2 correlation blocks) + * FPGA #3 correlation array (NUM_CORL3 correlation blocks) + * + * Each correlation array consists of: + * + * Correlation Data (2 x NUM_LAGSn x 32-bit words) + * Pipeline Metadata (2 x NUM_METAn x 32-bit words) + * Quantization Counters (2 x NUM_QCNTn x 32-bit words) + * + * The NUM_CORLn, NUM_LAGSn, NUM_METAn, and NUM_QCNTn values come from + * the FPGA configuration registers. They do not change once the FPGA's + * have been programmed, they only change on re-programming. + */ + +/* + * Basic Description: + * + * This driver is used to capture correlation spectra off of the four data + * processing FPGAs. The FPGAs are often reprogrammed at runtime, therefore + * this driver supports dynamic enable/disable of capture while the device + * remains open. + * + * The nominal capture rate is 64Hz (every 15.625ms). To facilitate this fast + * capture rate, all buffers are pre-allocated to avoid any potentially long + * running memory allocations while capturing. + * + * There are three lists which are used to keep track of the different states + * of data buffers. + * + * 1) free list + * This list holds all empty data buffers which are ready to receive data. + * + * 2) inflight list + * This list holds data
[PATCH 2/2] misc: add CARMA DATA-FPGA Programmer support
This adds support for programming the data processing FPGAs on the OVRO
CARMA board. These FPGAs have a special programming sequence that
requires that we program the Freescale DMA engine, which is only
available inside the kernel.
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
drivers/misc/carma/Kconfig |9 +
drivers/misc/carma/Makefile |1 +
drivers/misc/carma/carma-fpga-program.c | 1084 +++
3 files changed, 1094 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/carma/carma-fpga-program.c
diff --git a/drivers/misc/carma/Kconfig b/drivers/misc/carma/Kconfig
index 4be183f..e57a9d3 100644
--- a/drivers/misc/carma/Kconfig
+++ b/drivers/misc/carma/Kconfig
@@ -7,3 +7,12 @@ config CARMA_FPGA
Say Y here to include support for communicating with the data
processing FPGAs on the OVRO CARMA board.
+config CARMA_FPGA_PROGRAM
+ tristate CARMA DATA-FPGA Programmer
+ depends on FSL_SOC PPC_83xx MEDIA_SUPPORT HAS_DMA FSL_DMA
+ select VIDEOBUF_DMA_SG
+ default n
+ help
+ Say Y here to include support for programming the data processing
+ FPGAs on the OVRO CARMA board.
+
diff --git a/drivers/misc/carma/Makefile b/drivers/misc/carma/Makefile
index 0b69fa7..ff36ac2 100644
--- a/drivers/misc/carma/Makefile
+++ b/drivers/misc/carma/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_CARMA_FPGA) += carma-fpga.o
+obj-$(CONFIG_CARMA_FPGA_PROGRAM) += carma-fpga-program.o
diff --git a/drivers/misc/carma/carma-fpga-program.c
b/drivers/misc/carma/carma-fpga-program.c
new file mode 100644
index 000..ef16cb3
--- /dev/null
+++ b/drivers/misc/carma/carma-fpga-program.c
@@ -0,0 +1,1084 @@
+/*
+ * CARMA Board DATA-FPGA Programmer
+ *
+ * Copyright (c) 2009-2010 Ira W. Snyder i...@ovro.caltech.edu
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/dma-mapping.h
+#include linux/of_platform.h
+#include linux/completion.h
+#include linux/miscdevice.h
+#include linux/dmaengine.h
+#include linux/interrupt.h
+#include linux/highmem.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/leds.h
+#include linux/slab.h
+#include linux/fs.h
+#include linux/io.h
+
+#include media/videobuf-dma-sg.h
+
+/* MPC8349EMDS specific get_immrbase() */
+#include sysdev/fsl_soc.h
+
+static const char drv_name[] = carma-fpga-program;
+
+/*
+ * Maximum firmware size
+ *
+ * 12849552 bytes for a CARMA Digitizer Board
+ * 18662880 bytes for a CARMA Correlator Board
+ */
+#define FW_SIZE_EP2S90 12849552
+#define FW_SIZE_EP2S13018662880
+
+struct fpga_dev {
+ struct miscdevice miscdev;
+
+ /* Device Registers */
+ struct device *dev;
+ void __iomem *regs;
+ void __iomem *immr;
+
+ /* Freescale DMA Device */
+ struct dma_chan *chan;
+
+ /* Interrupts */
+ int irq, status;
+ struct completion completion;
+
+ /* FPGA Bitfile */
+ struct mutex lock;
+
+ struct videobuf_dmabuf vb;
+ bool vb_allocated;
+
+ /* max size and written bytes */
+ size_t fw_size;
+ size_t bytes;
+};
+
+/*
+ * FPGA Bitfile Helpers
+ */
+
+/**
+ * fpga_drop_firmware_data() - drop the bitfile image from memory
+ * @priv: the driver's private data structure
+ *
+ * LOCKING: must hold priv-lock
+ */
+static void fpga_drop_firmware_data(struct fpga_dev *priv)
+{
+ videobuf_dma_free(priv-vb);
+ priv-vb_allocated = false;
+ priv-bytes = 0;
+}
+
+/*
+ * LED Trigger (could be a seperate module)
+ */
+
+/*
+ * NOTE: this whole thing does have the problem that whenever the led's are
+ * NOTE: first set to use the fpga trigger, they could be in the wrong state
+ */
+
+DEFINE_LED_TRIGGER(ledtrig_fpga);
+
+static void ledtrig_fpga_programmed(bool enabled)
+{
+ if (enabled)
+ led_trigger_event(ledtrig_fpga, LED_FULL);
+ else
+ led_trigger_event(ledtrig_fpga, LED_OFF);
+}
+
+/*
+ * FPGA Register Helpers
+ */
+
+/* Register Definitions */
+#define FPGA_CONFIG_CONTROL0x40
+#define FPGA_CONFIG_STATUS 0x44
+#define FPGA_CONFIG_FIFO_SIZE 0x48
+#define FPGA_CONFIG_FIFO_USED 0x4C
+#define FPGA_CONFIG_TOTAL_BYTE_COUNT 0x50
+#define FPGA_CONFIG_CUR_BYTE_COUNT 0x54
+
+#define FPGA_FIFO_ADDRESS 0x3000
+
+static int fpga_fifo_size(void __iomem *regs)
+{
+ return ioread32be(regs + FPGA_CONFIG_FIFO_SIZE);
+}
+
+static int fpga_config_error(void __iomem *regs)
+{
+ return ioread32be(regs + FPGA_CONFIG_STATUS) 0xFFFE;
+}
+
+static int fpga_fifo_empty(void __iomem *regs)
+{
+ return
[PATCH] [v2] watchdog: booke_wdt: clean up status messages
Improve the status messages that are displayed during some operations of the
PowerPC watchdog timer driver. When the watchdog is enabled, the timeout is
displayed as a number of seconds, instead of an obscure period. The period
is the position of a bit in a 64-bit timer register. The higher the value,
the quicker the watchdog timeout occurs. Some people chose a high period
value for the timer and get confused as to why the board resets within a
few seconds.
Messages displayed during open and close are now debug messages, so that they
don't clutter the console by default. Finally, printk() is replaced with the
pr_xxx() equivalent.
Signed-off-by: Timur Tabi ti...@freescale.com
---
drivers/watchdog/booke_wdt.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 7e7ec9c..337265b 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -4,7 +4,7 @@
* Author: Matthew McClintock
* Maintainer: Kumar Gala ga...@kernel.crashing.org
*
- * Copyright 2005, 2008, 2010 Freescale Semiconductor Inc.
+ * Copyright 2005, 2008, 2010-2011 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -221,9 +221,8 @@ static int booke_wdt_open(struct inode *inode, struct file
*file)
if (booke_wdt_enabled == 0) {
booke_wdt_enabled = 1;
on_each_cpu(__booke_wdt_enable, NULL, 0);
- printk(KERN_INFO
- PowerPC Book-E Watchdog Timer Enabled (wdt_period=%d)\n,
- booke_wdt_period);
+ pr_debug(booke_wdt: watchdog enabled (timeout = %llu sec)\n,
+ period_to_sec(booke_wdt_period));
}
spin_unlock(booke_wdt_lock);
@@ -240,6 +239,7 @@ static int booke_wdt_release(struct inode *inode, struct
file *file)
*/
on_each_cpu(__booke_wdt_disable, NULL, 0);
booke_wdt_enabled = 0;
+ pr_debug(booke_wdt: watchdog disabled\n);
#endif
clear_bit(0, wdt_is_active);
@@ -271,21 +271,20 @@ static int __init booke_wdt_init(void)
{
int ret = 0;
- printk(KERN_INFO PowerPC Book-E Watchdog Timer Loaded\n);
+ pr_info(booke_wdt: powerpc book-e watchdog driver loaded\n);
ident.firmware_version = cur_cpu_spec-pvr_value;
ret = misc_register(booke_wdt_miscdev);
if (ret) {
- printk(KERN_CRIT Cannot register miscdev on minor=%d: %d\n,
- WATCHDOG_MINOR, ret);
+ pr_err(booke_wdt: cannot register device (minor=%u, ret=%i)\n,
+ WATCHDOG_MINOR, ret);
return ret;
}
spin_lock(booke_wdt_lock);
if (booke_wdt_enabled == 1) {
- printk(KERN_INFO
- PowerPC Book-E Watchdog Timer Enabled (wdt_period=%d)\n,
- booke_wdt_period);
+ pr_info(booke_wdt: watchdog enabled (timeout = %llu sec)\n,
+ period_to_sec(booke_wdt_period));
on_each_cpu(__booke_wdt_enable, NULL, 0);
}
spin_unlock(booke_wdt_lock);
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
