Re: [PATCH] comedi: Humusoft MF634 and MF624 DAQ cards driver
Hello Dan; On Wed, 2014-01-08 at 10:47 +0300, Dan Carpenter wrote: On Tue, Jan 07, 2014 at 11:24:57PM +0100, Rostislav Lisovy wrote: This patch adds Comedi driver for Humusoft MF634 (PCIe) and MF624 (PCI) data acquisition cards. The legacy card Humusoft MF614 is not supported. More info about the cards may be found at http://humusoft.cz/produkty/datacq/ The driver was tested with both cards. Everything seems to work properly. Just the basic functionality of the card (DIO, ADC, DAC) is supported by this driver. Signed-off-by: Rostislav Lisovy lis...@gmail.com create mode 100644 drivers/staging/comedi/drivers/mf6x4.c There should be a --- after the Signed-off-by line and before the diffstat create mode 100644 drivers/staging/comedi/drivers/mf6x4.c line. Otherwise, the diffstat gets included in the changelog. Signed-off-by: Rostislav Lisovy lis...@gmail.com --- create mode 100644 drivers/staging/comedi/drivers/mf6x4.c You are right, my mistake. But even though there should be v3 patch because I just realized there is an unnecessary comment in mf6x4_detach() and MF6X4_DAC_CHANN_CNT constant is no more used. Regards; Rostislav Lisovy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/3] staging: comedi: report success/failure of autoconfig
On 2014-01-07 21:42, Bernd Porr wrote:
Added success message to the driver autoconfig and error
message in case it fails. A success message is required
so that the user can find out which comedi driver has been
associated with which udev device. This also makes troubleshooting
much easier when more than one card is in the computer or
there is a mix of USB and PCI devices.
As Ian suggested we should report both the driver and the board
which might have different names, especially if one driver covers a
range of different boards.
Signed-off-by: Bernd Porr m...@berndporr.me.uk
---
drivers/staging/comedi/drivers.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c
index 9d71b4d..950f544 100644
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -603,8 +603,12 @@ int comedi_auto_config(struct device *hardware_device,
}
dev = comedi_alloc_board_minor(hardware_device);
- if (IS_ERR(dev))
+ if (IS_ERR(dev)) {
+ dev_warn(hardware_device,
+driver '%s' could not create device.\n,
+driver-driver_name);
return PTR_ERR(dev);
+ }
/* Note: comedi_alloc_board_minor() locked dev-mutex. */
dev-driver = driver;
@@ -616,8 +620,20 @@ int comedi_auto_config(struct device *hardware_device,
comedi_device_detach(dev);
mutex_unlock(dev-mutex);
- if (ret 0)
+ if (ret 0) {
+ dev_warn(hardware_device,
+driver '%s' failed to auto-configure device.\n,
+driver-driver_name);
comedi_release_hardware_device(hardware_device);
+ } else {
+ /*
+* class_dev should be set properly here
+* after a successful auto config
+*/
+ dev_info(dev-class_dev,
+driver '%s' has successfully auto-configured '%s'.\n,
+driver-driver_name, dev-board_name);
+ }
return ret;
}
EXPORT_SYMBOL_GPL(comedi_auto_config);
Looks fine to me.
Reviewed-by: Ian Abbott abbo...@mev.co.uk
--
-=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk)=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv2 7/7] vt6655: Remove typedefs in 80211hdr.h
On Tue, Jan 07, 2014 at 01:11:51PM +0100, Michael Gunselmann wrote:
From: Martin Hofmann martin.hofm...@studium.uni-erlangen.de
The file 80211hdr.h contained typedefs for 5 types. To satisfy checkpatch,
this commit removes them. In 11 other files, every occurence of a now deleted
type has been substituted with the correct struct ... syntax.
Why not split this into 5 patches, one for each typedef? That way the
one I don't like, I could have ignored, and taken the other 4 patches?
:)
-typedef union tagUWLAN_80211HDR {
- WLAN_80211HDR_A2sA2;
- WLAN_80211HDR_A3sA3;
- WLAN_80211HDR_A4sA4;
-} UWLAN_80211HDR, *PUWLAN_80211HDR;
+} __attribute__((__packed__));
+
+union UWLAN_80211HDR {
+ struct WLAN_80211HDR_A2 sA2;
+ struct WLAN_80211HDR_A3 sA3;
+ struct WLAN_80211HDR_A4 sA4;
+};
This really should be a struct of a union, right? Then you don't have
these odd casts to do:
- pFrame-pHdr = (PUWLAN_80211HDR)pFrame-pBuf;
+ pFrame-pHdr = (union UWLAN_80211HDR *)pFrame-pBuf;
And are these casts even needed?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 24/46] imx-drm: provide common connector mode validation function
On Tue, Jan 07, 2014 at 02:38:05PM +0800, Shawn Guo wrote: On Thu, Jan 02, 2014 at 09:27:48PM +, Russell King wrote: diff --git a/drivers/staging/imx-drm/imx-drm.h b/drivers/staging/imx-drm/imx-drm.h index 5649f180dc44..4eb594ce9cff 100644 --- a/drivers/staging/imx-drm/imx-drm.h +++ b/drivers/staging/imx-drm/imx-drm.h @@ -68,4 +68,7 @@ int imx_drm_encoder_get_mux_id(struct drm_encoder *encoder); int imx_drm_encoder_add_possible_crtcs(struct imx_drm_encoder *imx_drm_encoder, struct device_node *np); +int imx_drm_connector_mode_valid(struct drm_connector *connector, + struct drm_display_mode *mode); + #endif /* _IMX_DRM_H_ */ CC drivers/staging/imx-drm/ipu-v3/ipu-dc.o LD net/ethernet/built-in.o In file included from drivers/staging/imx-drm/ipu-v3/ipu-dc.c:23:0: drivers/staging/imx-drm/ipu-v3/../imx-drm.h:56:9: warning: ‘struct drm_display_mode’ declared inside parameter list [enabled by default] drivers/staging/imx-drm/ipu-v3/../imx-drm.h:56:9: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] Thanks, fixed. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 30/46] imx-drm: remove separate imx-fbdev
On Tue, Jan 07, 2014 at 02:49:50PM +0800, Shawn Guo wrote:
On Thu, Jan 02, 2014 at 09:28:19PM +, Russell King wrote:
@@ -449,6 +458,24 @@ static int imx_drm_driver_load(struct drm_device *drm,
unsigned long flags)
}
}
+ /*
+* All components are now initialised, so setup the fb helper.
+* The fb helper takes copies of key hardware information, so the
+* crtcs/connectors/encoders must not change after this point.
+*/
+#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
+ if (legacyfb_depth != 16 legacyfb_depth != 32) {
+ dev_warn(drm-dev, Invalid legacyfb_depth. Defaulting to
16bpp\n);
+ legacyfb_depth = 16;
+ }
+ imxdrm-fbhelper = drm_fbdev_cma_init(drm, legacyfb_depth,
+ drm-mode_config.num_crtc, 4);
s/4/MAX_CRTC
imx-drm-core.c has the macro.
Possible, but when moving code from one location to another it's best
to move it with minimal changes. Even so, I've now changed this.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Tue, Jan 07, 2014 at 04:59:35PM +0800, Shawn Guo wrote:
On Thu, Jan 02, 2014 at 09:28:03PM +, Russell King wrote:
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index e75e11b36dff..0e005f21d241 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -62,6 +62,12 @@
};
};
+ imx-drm {
+ compatible = fsl,imx-drm;
+ crtcs = ipu1 0, ipu1 1;
+ connectors = ldb;
+ };
+
While the change works fine on imx6dl, it breaks LVDS support on imx6q
right away.
imx-ipuv3 240.ipu: IPUv3H probed
imx-ipuv3 280.ipu: IPUv3H probed
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
imx-drm imx-drm.16: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
imx-drm imx-drm.16: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
imx-drm imx-drm.16: failed to bind ldb.10 (ops imx_ldb_ops): -517
Because we have 4 crtcs for lvds-channel on imx6q while imx-drm master
defines only 2 in there, the imx_drm_encoder_parse_of() call from
imx_ldb_register() will always return -EPROBE_DEFER.
lvds-channel@0 {
crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
};
lvds-channel@1 {
crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
};
This is why some help would be useful here - I think I got these right
but I've no way to check them.
Can you confirm that adding all four is the right thing not only for
the imx6q but also the imx6dl sabresd please?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Tue, Jan 07, 2014 at 05:29:55PM +0100, Philipp Zabel wrote:
Thanky you. This is what I came up with so far:
From: Philipp Zabel p.za...@pengutronix.de
Subject: [PATCH 1/2] staging: imx-hdmi: use RX_SENSE0 for plug detection if
HPD is unreliable
On some boards HPD might not reliably detect DVI monitors. Allow to use
RX_SENSE0 as a workaround.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/staging/imx-drm/imx-hdmi.c | 45
+-
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-hdmi.c
b/drivers/staging/imx-drm/imx-hdmi.c
index 7779337..cc305f3 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -139,6 +139,7 @@ struct imx_hdmi {
struct regmap *regmap;
struct i2c_adapter *ddc;
+ bool hpd_unreliable;
void __iomem *regs;
unsigned int sample_rate;
@@ -1309,6 +1310,14 @@ static int imx_hdmi_setup(struct imx_hdmi *hdmi,
struct drm_display_mode *mode)
/* Wait until we are registered to enable interrupts */
static int imx_hdmi_fb_registered(struct imx_hdmi *hdmi)
{
+ int stat_bit = HDMI_IH_PHY_STAT0_HPD;
+ int mask_bits = ~HDMI_PHY_HPD;
+
+ if (hdmi-hpd_unreliable) {
+ stat_bit = HDMI_IH_PHY_STAT0_RX_SENSE0;
+ mask_bits = ~HDMI_PHY_RX_SENSE0;
+ }
+
How about storing these in imx_hdmi instead, so we don't have to compute
them in each interrupt? Maybe sink_detect_status and sink_detect_mask?
Thanks.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] Drivers: hv: Implement the file copy service
Implement the file copy service for Linux guests on Hyper-V. This permits the
host to copy a file (over VMBUS) into the guest. This facility is part of
guest integration services supported on the Windows platform.
Here is a link that provides additional details on this functionality:
http://technet.microsoft.com/en-us/library/dn464282.aspx
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
drivers/hv/Makefile|2 +-
drivers/hv/hv_fcopy.c | 451
drivers/hv/hv_util.c | 10 +
include/linux/hyperv.h | 60 ++
tools/hv/hv_fcopy_daemon.c | 171 +
5 files changed, 693 insertions(+), 1 deletions(-)
create mode 100644 drivers/hv/hv_fcopy.c
create mode 100644 tools/hv/hv_fcopy_daemon.c
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 0a74b56..5e4dfa4 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -5,4 +5,4 @@ obj-$(CONFIG_HYPERV_BALLOON)+= hv_balloon.o
hv_vmbus-y := vmbus_drv.o \
hv.o connection.o channel.o \
channel_mgmt.o ring_buffer.o
-hv_utils-y := hv_util.o hv_kvp.o hv_snapshot.o
+hv_utils-y := hv_util.o hv_kvp.o hv_snapshot.o hv_fcopy.o
diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
new file mode 100644
index 000..e44a112
--- /dev/null
+++ b/drivers/hv/hv_fcopy.c
@@ -0,0 +1,451 @@
+/*
+ * An implementation of file copy service.
+ *
+ * Copyright (C) 2014, Microsoft, Inc.
+ *
+ * Author : K. Y. Srinivasan ksriniva...@novell.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for more
+ * details.
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME : fmt
+
+#include linux/semaphore.h
+#include linux/fs.h
+#include linux/nls.h
+#include linux/workqueue.h
+#include linux/cdev.h
+#include linux/hyperv.h
+#include asm-generic/uaccess.h
+
+#define WIN8_SRV_MAJOR 1
+#define WIN8_SRV_MINOR 1
+#define WIN8_SRV_VERSION (WIN8_SRV_MAJOR 16 | WIN8_SRV_MINOR)
+
+
+
+/*
+ * Global state maintained for transaction that is being processed.
+ * Note that only one transaction can be active at any point in time.
+ *
+ * This state is set when we receive a request from the host; we
+ * cleanup this state when the transaction is completed - when we respond
+ * to the host with our response.
+ */
+
+static struct {
+ bool active; /* transaction status - active or not */
+ int recv_len; /* number of bytes received. */
+ struct hv_fcopy_hdr *fcopy_msg; /* current message */
+ struct hv_start_fcopy message; /* sent to daemon */
+ struct vmbus_channel *recv_channel; /* chn we got the request */
+ u64 recv_req_id; /* request ID. */
+ void *fcopy_context; /* for the channel callback */
+ struct semaphore read_sema;
+} fcopy_transaction;
+
+
+
+static dev_t fcopy_dev;
+static bool daemon_died = false;
+static bool opened; /* currently device opened */
+static struct task_struct *dtp; /* daemon task ptr */
+
+/*
+ * Before we can accept copy messages from the host, we need
+ * to handshake with the user level daemon. This state tracks
+ * if we are in the handshake phase.
+ */
+static bool in_hand_shake = true;
+
+static void fcopy_send_data(void);
+
+
+static void fcopy_respond_to_host(int error);
+static void fcopy_work_func(struct work_struct *dummy);
+
+static DECLARE_DELAYED_WORK(fcopy_work, fcopy_work_func);
+
+static u8 *recv_buffer;
+
+static void fcopy_work_func(struct work_struct *dummy)
+{
+ /*
+* If the timer fires, the user-mode component has not responded;
+* process the pending transaction.
+*/
+ fcopy_respond_to_host(HV_E_FAIL);
+}
+
+static int fcopy_handle_handshake(int op)
+{
+ int ret = 1;
+
+ pr_info(FCP: user-mode registering done.\n);
+ fcopy_transaction.active = false;
+ set_channel_read_state((struct vmbus_channel *)
+ fcopy_transaction.fcopy_context,
+ true);
+
+ if (fcopy_transaction.fcopy_context)
+ hv_fcopy_onchannelcallback(fcopy_transaction.fcopy_context);
+
+ in_hand_shake = false;
+ return ret;
+}
+
+static void fcopy_send_data(void)
+{
+ struct hv_start_fcopy *smsg_out = fcopy_transaction.message;
+ int operation = fcopy_transaction.fcopy_msg-operation;
+ struct hv_start_fcopy *smsg_in;
+
+ /*
+* The strings sent from the host are encoded in
+* in utf16; convert it to utf8 strings.
+* The host assures us that the utf16 strings will not exceed
+
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Wed, Jan 8, 2014 at 4:36 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 07, 2014 at 03:18:21PM -0500, Sean Paul wrote:
On Thu, Jan 2, 2014 at 4:27 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Subsystems such as ALSA, DRM and others require a single card-level
device structure to represent a subsystem. However, firmware tends to
describe the individual devices and the connections between them.
Therefore, we need a way to gather up the individual component devices
together, and indicate when we have all the component devices.
We do this in DT by providing a superdevice node which specifies
the components, eg:
imx-drm {
compatible = fsl,drm;
crtcs = ipu1;
connectors = hdmi;
};
Hi Russell,
This looks really good. I'd definitely like to use it for the exynos
drm driver both to bind the various IP blocks together, and also to
pull in any attached bridges that are specified in the device tree.
Along those lines, it might be worthwhile to pull some of the master
bind functionality in your next patch into drm helpers so other
drivers can use them, and so we have concrete bindings across drm.
Which bits do you think would be useful to move into the core?
imx_drm_add_components() is rather imx-drm specific, especially for
the CRTCs - it carries the knowledge that the OF device to be matched
can be found in the _parent_ device, rather than the device registered
into the component helpers.
Yeah, I was thinking of imx_drm_add_components() actually. It probably
doesn't make sense to enforce the parent relationship in a generic
manner, but it would be nice to have a helper which added the various
drm components (crtc/encoder/bridge/connector) with a consistent
binding.
We have 3 different exynos boards which would have the following
superdevices (please forgive my hypothetical syntax/naming):
Board 1:
exynos-drm {
compatible = exynos,drm;
crtcs = fimd1, mixer1;
encoders = dp1, hdmi1;
bridges = ptn3460 dp1;
connectors = ptn3460, hdmi1;
};
Board 2:
exynos-drm {
compatible = exynos,drm;
crtcs = fimd1, mixer1;
encoders = dp1, hdmi1;
bridges = ps8622 dp1, anx7808 hdmi1;
connectors = ps8622, anx7808;
};
Board 3:
exynos-drm {
compatible = exynos,drm;
crtcs = fimd1, mixer1;
encoders = dp1, hdmi1;
connectors = dp1, hdmi1;
};
In addition to enforcing common bindings across drivers, we could also
assign bridges to encoders from the dt. The bridge-encoder
relationship is 1:1 at the moment, and the bridge driver can be a
completely separate entity from the encoder. Allowing assignment from
the dt means the encoder never needs to know whether a bridge is
connected.
Right now the encoder must enumerate all possible bridges to see if
they are present (check out [PATCH v3 31/32] drm/exynos: Move lvds
bridge discovery into DP driver for an example of what I mean).
Sean
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] Drivers: hv: Implement the file copy service
On Wed, Jan 08, 2014 at 03:48:35PM -0800, K. Y. Srinivasan wrote: Implement the file copy service for Linux guests on Hyper-V. This permits the host to copy a file (over VMBUS) into the guest. This facility is part of guest integration services supported on the Windows platform. Here is a link that provides additional details on this functionality: http://technet.microsoft.com/en-us/library/dn464282.aspx Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- drivers/hv/Makefile|2 +- drivers/hv/hv_fcopy.c | 451 drivers/hv/hv_util.c | 10 + include/linux/hyperv.h | 60 ++ tools/hv/hv_fcopy_daemon.c | 171 + 5 files changed, 693 insertions(+), 1 deletions(-) create mode 100644 drivers/hv/hv_fcopy.c create mode 100644 tools/hv/hv_fcopy_daemon.c It's too late in the 3.14 development cycle for this (i.e. 3.13 is going to be out this weekend), but I'll queue this up for 3.15-rc1. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/3] staging: drm/imx: don't drop crtc offsets when doing pageflip
On Fri, Dec 20, 2013 at 05:28:34PM +0100, Philipp Zabel wrote: From: Lucas Stach l.st...@pengutronix.de Signed-off-by: Lucas Stach l.st...@pengutronix.de Signed-off-by: Philipp Zabel p.za...@pengutronix.de Why? Please resend all of these with better changelog comments. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: dwc2: Mark function as static in core.c
On Sat, Dec 21, 2013 at 03:50:29PM +0530, Rashika Kheria wrote: Mark function dwc2_set_param_uframe_sched() as static in core.c because it is not used outside this file. This eliminates the following warning in core.c: drivers/staging/dwc2/core.c:2739:5: warning: no previous prototype for ‘dwc2_set_param_uframe_sched’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria rashika.khe...@gmail.com This patch doesn't apply to my tree. And please stop sending patches in base64 mode, it makes it impossible to add reviewed-by: markings to them. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: Fix typo in lustre/ldlm
On Sun, Dec 22, 2013 at 12:42:20AM +0900, Masanari Iida wrote: Correct spelling typo in lustre/ldlm Signed-off-by: Masanari Iida standby2...@gmail.com --- drivers/staging/lustre/lustre/ldlm/ldlm_lock.c | 8 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c | 2 +- drivers/staging/lustre/lustre/ldlm/ldlm_request.c | 10 +- drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 4 ++-- 4 files changed, 12 insertions(+), 12 deletions(-) Someone already made this change to the tree, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] Staging: lustre: Fix line length exceeding 80 characters
On Sun, Jan 05, 2014 at 12:30:51PM -0800, Joe Perches wrote: On Mon, 2014-01-06 at 01:41 +0530, MonamAgarwal wrote: This patch fixes the following checkpatch.pl warning in lustre/ldlm/interval_tree.c WARNING: line over 80 characters in the file [] diff --git a/drivers/staging/lustre/lustre/ldlm/interval_tree.c b/drivers/staging/lustre/lustre/ldlm/interval_tree.c [] @@ -429,7 +429,8 @@ static void interval_erase_color(struct interval_node *node, struct interval_node *o_left; o_left = tmp-in_left; if (o_left) - o_left-in_color = INTERVAL_BLACK; + o_left-in_color = + INTERVAL_BLACK; Likely this function would be better off with some refactoring instead of straining to fit 80 cols. I agree, if you are doing things like this, that's a huge hint that the code needs fixing. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] Staging: lustre: Fix return does not need parantheses
On Mon, Jan 06, 2014 at 01:48:07AM +0530, MonamAgarwal wrote: This patch fixes the following checkpatch.pl warning in lustre/ldlm/interval_tree.c ERROR: return is not a function, parentheses are not required Signed-off-by: MonamAgarwal monamagarwal...@gmail.com I need a semblance of a real name, which usually consists of a first and last name for most places. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] mmc: rtsx: modify phase searching method for tuning
From: Micky Ching micky_ch...@realsil.com.cn
The new phase searching method is more concise and easier to
understand.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 112 +++--
include/linux/mfd/rtsx_pci.h |2 +-
2 files changed, 33 insertions(+), 81 deletions(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index c9a7328..7da270b 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -31,16 +31,6 @@
#include linux/mfd/rtsx_pci.h
#include asm/unaligned.h
-/* SD Tuning Data Structure
- * Record continuous timing phase path
- */
-struct timing_phase_path {
- int start;
- int end;
- int mid;
- int len;
-};
-
struct realtek_pci_sdmmc {
struct platform_device *pdev;
struct rtsx_pcr *pcr;
@@ -511,85 +501,47 @@ static int sd_change_phase(struct realtek_pci_sdmmc *host,
return 0;
}
-static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)
+static inline u32 test_phase_bit(u32 phase_map, unsigned int bit)
{
- struct timing_phase_path path[MAX_PHASE + 1];
- int i, j, cont_path_cnt;
- int new_block, max_len, final_path_idx;
- u8 final_phase = 0xFF;
+ bit %= RTSX_PHASE_MAX;
+ return phase_map (1 bit);
+}
- /* Parse phase_map, take it as a bit-ring */
- cont_path_cnt = 0;
- new_block = 1;
- j = 0;
- for (i = 0; i MAX_PHASE + 1; i++) {
- if (phase_map (1 i)) {
- if (new_block) {
- new_block = 0;
- j = cont_path_cnt++;
- path[j].start = i;
- path[j].end = i;
- } else {
- path[j].end = i;
- }
- } else {
- new_block = 1;
- if (cont_path_cnt) {
- /* Calculate path length and middle point */
- int idx = cont_path_cnt - 1;
- path[idx].len =
- path[idx].end - path[idx].start + 1;
- path[idx].mid =
- path[idx].start + path[idx].len / 2;
- }
- }
- }
+static int sd_get_phase_len(u32 phase_map, unsigned int start_bit)
+{
+ int i;
- if (cont_path_cnt == 0) {
- dev_dbg(sdmmc_dev(host), No continuous phase path\n);
- goto finish;
- } else {
- /* Calculate last continuous path length and middle point */
- int idx = cont_path_cnt - 1;
- path[idx].len = path[idx].end - path[idx].start + 1;
- path[idx].mid = path[idx].start + path[idx].len / 2;
+ for (i = 0; i RTSX_PHASE_MAX; i++) {
+ if (test_phase_bit(phase_map, start_bit + i) == 0)
+ return i;
}
+ return RTSX_PHASE_MAX;
+}
+
+static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)
+{
+ int start = 0, len = 0;
+ int start_final = 0, len_final = 0;
+ u8 final_phase = 0xFF;
- /* Connect the first and last continuous paths if they are adjacent */
- if (!path[0].start (path[cont_path_cnt - 1].end == MAX_PHASE)) {
- /* Using negative index */
- path[0].start = path[cont_path_cnt - 1].start - MAX_PHASE - 1;
- path[0].len += path[cont_path_cnt - 1].len;
- path[0].mid = path[0].start + path[0].len / 2;
- /* Convert negative middle point index to positive one */
- if (path[0].mid 0)
- path[0].mid += MAX_PHASE + 1;
- cont_path_cnt--;
+ if (phase_map == 0) {
+ dev_err(sdmmc_dev(host), phase error: [map:%x]\n, phase_map);
+ return final_phase;
}
- /* Choose the longest continuous phase path */
- max_len = 0;
- final_phase = 0;
- final_path_idx = 0;
- for (i = 0; i cont_path_cnt; i++) {
- if (path[i].len max_len) {
- max_len = path[i].len;
- final_phase = (u8)path[i].mid;
- final_path_idx = i;
+ while (start RTSX_PHASE_MAX) {
+ len = sd_get_phase_len(phase_map, start);
+ if (len_final len) {
+ start_final = start;
+ len_final = len;
}
-
- dev_dbg(sdmmc_dev(host), path[%d].start = %d\n,
- i, path[i].start);
- dev_dbg(sdmmc_dev(host), path[%d].end = %d\n,
- i, path[i].end);
-
[PATCH 3/3] mmc: rtsx: add support for pre_req and post_req
From: Micky Ching micky_ch...@realsil.com.cn
Add support for non-blocking request, pre_req() runs dma_map_sg() and
post_req() runs dma_unmap_sg(). This patch can increase card read/write
speed, especially for high speed card and slow CPU(for some embedded
platform).
Users can get a great benefit from this patch. if CPU frequency is 800MHz,
SDR104 or DDR50 card read/write speed may increase more than 15%.
test results:
intel i3(800MHz - 2.3GHz), SD card clock 208MHz
performance mode(2.3GHz):
Before:
dd if=/dev/mmcblk0p1 of=/dev/null bs=64k count=1024
67108864 bytes (67 MB) copied, 1.18191 s, 56.8 MB/s
After:
dd if=/dev/mmcblk0p1 of=/dev/null bs=64k count=1024
67108864 bytes (67 MB) copied, 1.09276 s, 61.4 MB/s
powersave mode(800MHz):
Before:
dd if=/dev/mmcblk0p1 of=/dev/null bs=64k count=1024
67108864 bytes (67 MB) copied, 1.29569 s, 51.8 MB/s
After:
dd if=/dev/mmcblk0p1 of=/dev/null bs=64k count=1024
67108864 bytes (67 MB) copied, 1.11218 s, 60.3 MB/s
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rtsx_pcr.c| 132
drivers/mmc/host/rtsx_pci_sdmmc.c | 426 ++---
include/linux/mfd/rtsx_common.h |1 +
include/linux/mfd/rtsx_pci.h |6 +
4 files changed, 448 insertions(+), 117 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 2af55bb..d21c894 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -338,58 +338,28 @@ int rtsx_pci_transfer_data(struct rtsx_pcr *pcr, struct
scatterlist *sglist,
int num_sg, bool read, int timeout)
{
struct completion trans_done;
- u8 dir;
- int err = 0, i, count;
+ int err = 0, count;
long timeleft;
unsigned long flags;
- struct scatterlist *sg;
- enum dma_data_direction dma_dir;
- u32 val;
- dma_addr_t addr;
- unsigned int len;
-
- dev_dbg((pcr-pci-dev), -- %s: num_sg = %d\n, __func__, num_sg);
-
- /* don't transfer data during abort processing */
- if (pcr-remove_pci)
- return -EINVAL;
-
- if ((sglist == NULL) || (num_sg = 0))
- return -EINVAL;
- if (read) {
- dir = DEVICE_TO_HOST;
- dma_dir = DMA_FROM_DEVICE;
- } else {
- dir = HOST_TO_DEVICE;
- dma_dir = DMA_TO_DEVICE;
- }
-
- count = dma_map_sg((pcr-pci-dev), sglist, num_sg, dma_dir);
+ count = rtsx_pci_dma_map_sg(pcr, sglist, num_sg, read);
if (count 1) {
dev_err((pcr-pci-dev), scatterlist map failed\n);
return -EINVAL;
}
dev_dbg((pcr-pci-dev), DMA mapping count: %d\n, count);
- val = ((u32)(dir 0x01) 29) | TRIG_DMA | ADMA_MODE;
- pcr-sgi = 0;
- for_each_sg(sglist, sg, count, i) {
- addr = sg_dma_address(sg);
- len = sg_dma_len(sg);
- rtsx_pci_add_sg_tbl(pcr, addr, len, i == count - 1);
- }
spin_lock_irqsave(pcr-lock, flags);
pcr-done = trans_done;
pcr-trans_result = TRANS_NOT_READY;
init_completion(trans_done);
- rtsx_pci_writel(pcr, RTSX_HDBAR, pcr-host_sg_tbl_addr);
- rtsx_pci_writel(pcr, RTSX_HDBCTLR, val);
spin_unlock_irqrestore(pcr-lock, flags);
+ rtsx_pci_dma_transfer(pcr, sglist, count, read);
+
timeleft = wait_for_completion_interruptible_timeout(
trans_done, msecs_to_jiffies(timeout));
if (timeleft = 0) {
@@ -413,7 +383,7 @@ out:
pcr-done = NULL;
spin_unlock_irqrestore(pcr-lock, flags);
- dma_unmap_sg((pcr-pci-dev), sglist, num_sg, dma_dir);
+ rtsx_pci_dma_unmap_sg(pcr, sglist, num_sg, read);
if ((err 0) (err != -ENODEV))
rtsx_pci_stop_cmd(pcr);
@@ -425,6 +395,73 @@ out:
}
EXPORT_SYMBOL_GPL(rtsx_pci_transfer_data);
+int rtsx_pci_dma_map_sg(struct rtsx_pcr *pcr, struct scatterlist *sglist,
+ int num_sg, bool read)
+{
+ enum dma_data_direction dir = read ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ if (pcr-remove_pci)
+ return -EINVAL;
+
+ if ((sglist == NULL) || num_sg 1)
+ return -EINVAL;
+
+ return dma_map_sg((pcr-pci-dev), sglist, num_sg, dir);
+}
+EXPORT_SYMBOL_GPL(rtsx_pci_dma_map_sg);
+
+int rtsx_pci_dma_unmap_sg(struct rtsx_pcr *pcr, struct scatterlist *sglist,
+ int num_sg, bool read)
+{
+ enum dma_data_direction dir = read ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ if (pcr-remove_pci)
+ return -EINVAL;
+
+ if (sglist == NULL || num_sg 1)
+ return -EINVAL;
+
+ dma_unmap_sg((pcr-pci-dev), sglist, num_sg, dir);
+ return num_sg;
+}
+EXPORT_SYMBOL_GPL(rtsx_pci_dma_unmap_sg);
+
+int rtsx_pci_dma_transfer(struct rtsx_pcr *pcr, struct scatterlist *sglist,
+ int sg_count, bool read)
+{
+ struct scatterlist
[PATCH 0/3] mmc: rtsx: fix bug and support nonblocking request
From: Micky Ching micky_ch...@realsil.com.cn First we fix the card poweroff bug: the card power is not shutdown when sd/mmc card removed, this will make UHS-card failed to running in high speed mode if we insert the card again. We offer a concise tuning searching method, it is much easier to read. At last we add support for nonblocking request, which will improve card read speed at about 10% write speed about 5% normally. Micky Ching (3): mmc: rtsx: fix card poweroff bug mmc: rtsx: modify phase searching method for tuning mmc: rtsx: add support for pre_req and post_req drivers/mfd/rtsx_pcr.c| 132 ++--- drivers/mmc/host/rtsx_pci_sdmmc.c | 537 ++--- include/linux/mfd/rtsx_common.h |1 + include/linux/mfd/rtsx_pci.h |8 +- 4 files changed, 481 insertions(+), 197 deletions(-) -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-next 479/499] drivers/staging/rtl8188eu/core/rtw_cmd.c:411 rtw_cmd_thread() error: double unlock 'sem:pcmdpriv-terminate_cmdthread_sema'
Hi Larry,
FYI, there are new smatch warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-next
head: 55323187f86f6ab39ee79eb4248b2efe29a464f2
commit: 2ca4ab5324062e70393e9a37a8db1ea94d6e2f99 [479/499] staging: r8188eu:
Remove wrappers _rtw_free_sema, _rtw_up_sema, and _rtw_mutex_init
New smatch warnings:
drivers/staging/rtl8188eu/core/rtw_cmd.c:411 rtw_cmd_thread() error: double
unlock 'sem:pcmdpriv-terminate_cmdthread_sema'
Old smatch warnings:
drivers/staging/rtl8188eu/core/rtw_cmd.c:2100 c2h_wk_callback() error: we
previously assumed 'c2h_evt' could be null (see line 2090)
git remote add staging
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
git remote update staging
git checkout 2ca4ab5324062e70393e9a37a8db1ea94d6e2f99
vim +411 drivers/staging/rtl8188eu/core/rtw_cmd.c
9a7fe54d Larry Finger 2013-08-21 395
9a7fe54d Larry Finger 2013-08-21 396 goto _next;
9a7fe54d Larry Finger 2013-08-21 397 }
9a7fe54d Larry Finger 2013-08-21 398 pcmdpriv-cmdthd_running = false;
9a7fe54d Larry Finger 2013-08-21 399
9a7fe54d Larry Finger 2013-08-21 400 /* free all cmd_obj resources */
9a7fe54d Larry Finger 2013-08-21 401 do {
9a7fe54d Larry Finger 2013-08-21 402 pcmd =
rtw_dequeue_cmd(pcmdpriv);
9a7fe54d Larry Finger 2013-08-21 403 if (pcmd == NULL)
9a7fe54d Larry Finger 2013-08-21 404 break;
9a7fe54d Larry Finger 2013-08-21 405
9a7fe54d Larry Finger 2013-08-21 406 /* DBG_88E(%s: leaving... drop
cmdcode:%u\n, __func__, pcmd-cmdcode); */
9a7fe54d Larry Finger 2013-08-21 407
9a7fe54d Larry Finger 2013-08-21 408 rtw_free_cmd_obj(pcmd);
9a7fe54d Larry Finger 2013-08-21 409 } while (1);
9a7fe54d Larry Finger 2013-08-21 410
2ca4ab53 Larry Finger 2013-12-22 @411 up(pcmdpriv-terminate_cmdthread_sema);
9a7fe54d Larry Finger 2013-08-21 412
9a7fe54d Larry Finger 2013-08-21 413 _func_exit_;
9a7fe54d Larry Finger 2013-08-21 414
dfa5e81e Larry Finger 2013-12-19 415 complete_and_exit(NULL, 0);
9a7fe54d Larry Finger 2013-08-21 416 }
9a7fe54d Larry Finger 2013-08-21 417
9a7fe54d Larry Finger 2013-08-21 418 u8 rtw_setstandby_cmd(struct adapter
*padapter, uint action)
9a7fe54d Larry Finger 2013-08-21 419 {
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch] staging: bcm: clean up a type issue in ConfigureEndPointTypesThroughEEPROM()
We only ever set the highest 4 bytes of ulReg. This would cause a
problem on big endian systems. The type should be u32 instead of
unsigned long.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/staging/bcm/InterfaceInit.c
b/drivers/staging/bcm/InterfaceInit.c
index 3acdb58a10f5..94f32728f7c8 100644
--- a/drivers/staging/bcm/InterfaceInit.c
+++ b/drivers/staging/bcm/InterfaceInit.c
@@ -69,7 +69,7 @@ static void InterfaceAdapterFree(struct bcm_interface_adapter
*psIntfAdapter)
static void ConfigureEndPointTypesThroughEEPROM(struct bcm_mini_adapter
*Adapter)
{
- unsigned long ulReg = 0;
+ u32 ulReg;
int bytes;
/* Program EP2 MAX_PKT_SIZE */
@@ -96,7 +96,7 @@ static void ConfigureEndPointTypesThroughEEPROM(struct
bcm_mini_adapter *Adapter
BeceemEEPROMBulkWrite(Adapter, (PUCHAR)ulReg, 0x140, 4, TRUE);
/* Program TX EP as interrupt(Alternate Setting) */
- bytes = rdmalt(Adapter, 0x0F0110F8, (u32 *)ulReg, sizeof(u32));
+ bytes = rdmalt(Adapter, 0x0F0110F8, ulReg, sizeof(u32));
if (bytes 0) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_INITEXIT, DRV_ENTRY,
DBG_LVL_ALL,
reading of Tx EP failed\n);
@@ -119,18 +119,18 @@ static void ConfigureEndPointTypesThroughEEPROM(struct
bcm_mini_adapter *Adapter
* Update EEPROM Version.
* Read 4 bytes from 508 and modify 511 and 510.
*/
- ReadBeceemEEPROM(Adapter, 0x1FC, (PUINT)ulReg);
+ ReadBeceemEEPROM(Adapter, 0x1FC, ulReg);
ulReg = 0x0101;
BeceemEEPROMBulkWrite(Adapter, (PUCHAR)ulReg, 0x1FC, 4, TRUE);
/* Update length field if required. Also make the string NULL
terminated. */
- ReadBeceemEEPROM(Adapter, 0xA8, (PUINT)ulReg);
+ ReadBeceemEEPROM(Adapter, 0xA8, ulReg);
if ((ulReg0x00FF)16 0x30) {
ulReg = (ulReg0xFF00)|(0x3016);
BeceemEEPROMBulkWrite(Adapter, (PUCHAR)ulReg, 0xA8, 4, TRUE);
}
- ReadBeceemEEPROM(Adapter, 0x148, (PUINT)ulReg);
+ ReadBeceemEEPROM(Adapter, 0x148, ulReg);
if ((ulReg0x00FF)16 0x30) {
ulReg = (ulReg0xFF00)|(0x3016);
BeceemEEPROMBulkWrite(Adapter, (PUCHAR)ulReg, 0x148, 4, TRUE);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/1] staging: Driver for downloading Xilinx FPGA image
Hi Greg, Here is a patch for downloading xilinx fpga program image: * Download Xilinx FPGA image * This module downloads Xilinx FPGA image using gpio pins. -- Patch checklist: -- [x] run checkpatch [x] specify where to apply the patch [x] build test using ppc64e_defconfig [x] running test, running code is built with 3.8.13 kernel due to target specific kernel Thank you, Insop Song -- 1. SUMMARY -- * Download Xilinx FPGA image * This module downloads Xilinx FPGA image using gpio pins. -- 1.b Patch is prepared at: -- - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git - branch: staging-next - after 98e54917311609d29d4a0aae3a4a08f8ab502984 (latest as of when sending this) -- 2. BACKGROUND -- An FPGA (Field Programmable Gate Array) is a programmable hardware that is used in various applications. Hardware design needs to programmed through a dedicated device or CPU assisted way (serial or parallel). This driver provides a way to download FPGA image. -- 3. DESIGN -- * load Xilinx FPGA bitstream format[1] image using kernel firmware framework, request_firmware() * program the Xilinx FPGA using SelectMAP (parallel) mode [2] * FPGA prgram is done by gpio based bit-banging, as an example * platform independent file: gs_fpgaboot.c * platform dependent file: io.c -- 4. HOW TO USE -- $ insmod gs_fpga.ko file=xlinx_fpga_top_bitstream.bit $ rmmod gs_fpga -- 5. REFERENCE -- 1. Xilinx APP NOTE XAPP583: http://www.xilinx.com/support/documentation/application_notes/xapp583-fpga-configuration.pdf 2. bitstream file info: http://home.earthlink.net/~davesullins/software/bitinfo.html Insop Song (1): Download Xilinx FPGA image drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/gs_fpgaboot/Kconfig |8 + drivers/staging/gs_fpgaboot/Makefile |4 + drivers/staging/gs_fpgaboot/README| 60 drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 505 + drivers/staging/gs_fpgaboot/gs_fpgaboot.h | 56 drivers/staging/gs_fpgaboot/io.c | 331 +++ drivers/staging/gs_fpgaboot/io.h | 90 + 9 files changed, 1057 insertions(+) create mode 100644 drivers/staging/gs_fpgaboot/Kconfig create mode 100644 drivers/staging/gs_fpgaboot/Makefile create mode 100644 drivers/staging/gs_fpgaboot/README create mode 100644 drivers/staging/gs_fpgaboot/gs_fpgaboot.c create mode 100644 drivers/staging/gs_fpgaboot/gs_fpgaboot.h create mode 100644 drivers/staging/gs_fpgaboot/io.c create mode 100644 drivers/staging/gs_fpgaboot/io.h -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: Driver for downloading Xilinx FPGA image
On Wed, Jan 08, 2014 at 10:00:15PM -0800, Insop Song wrote:
This module downloads Xilinx FPGA image using gpio pins
DESIGN
--
* load Xilinx FPGA bitstream format[1] image using kernel firmware
* framework,
request_firmware()
Odd formatting of the changelog entry, care to fix this up?
* program the Xilinx FPGA using SelectMAP (parallel) mode [2]
* FPGA prgram is done by gpio based bit-banging, as an example
* platform independent file: gs_fpgaboot.c
* platform dependent file: io.c
Signed-off-by: Insop Song insop.s...@gainspeed.com
---
drivers/staging/Kconfig |2 +
drivers/staging/Makefile |1 +
drivers/staging/gs_fpgaboot/Kconfig |8 +
drivers/staging/gs_fpgaboot/Makefile |4 +
drivers/staging/gs_fpgaboot/README| 60
drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 505
+
drivers/staging/gs_fpgaboot/gs_fpgaboot.h | 56
drivers/staging/gs_fpgaboot/io.c | 331 +++
drivers/staging/gs_fpgaboot/io.h | 90 +
9 files changed, 1057 insertions(+)
create mode 100644 drivers/staging/gs_fpgaboot/Kconfig
create mode 100644 drivers/staging/gs_fpgaboot/Makefile
create mode 100644 drivers/staging/gs_fpgaboot/README
create mode 100644 drivers/staging/gs_fpgaboot/gs_fpgaboot.c
create mode 100644 drivers/staging/gs_fpgaboot/gs_fpgaboot.h
create mode 100644 drivers/staging/gs_fpgaboot/io.c
create mode 100644 drivers/staging/gs_fpgaboot/io.h
Why is this driver going into the staging directory? We need a TODO
file listing the issues that need to be taken care of in order to be
able to move this out of the staging tree, can you please add that to
your next version?
Also be sure to add the responsible developer for the driver to the TODO
file, see the other examples for the format of what is needed here.
--- /dev/null
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -0,0 +1,505 @@
+/*
+ * 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.
Do you really mean any later version? (sorry, I have to ask.)
+/* Assert and Deassert CCLK */
+void xl_shift_cclk(int count)
+{
+ int i;
+ for (i = 0; i count; i++) {
+ xl_cclk_b(1);
+ xl_cclk_b(0);
+ }
+}
+EXPORT_SYMBOL(xl_shift_cclk);
You don't need to export symbols when they are only used in your own
module.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: Driver for downloading Xilinx FPGA image
This module downloads Xilinx FPGA image using gpio pins DESIGN -- * load Xilinx FPGA bitstream format[1] image using kernel firmware * framework, request_firmware() * program the Xilinx FPGA using SelectMAP (parallel) mode [2] * FPGA prgram is done by gpio based bit-banging, as an example * platform independent file: gs_fpgaboot.c * platform dependent file: io.c Signed-off-by: Insop Song insop.s...@gainspeed.com --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/gs_fpgaboot/Kconfig |8 + drivers/staging/gs_fpgaboot/Makefile |4 + drivers/staging/gs_fpgaboot/README| 60 drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 505 + drivers/staging/gs_fpgaboot/gs_fpgaboot.h | 56 drivers/staging/gs_fpgaboot/io.c | 331 +++ drivers/staging/gs_fpgaboot/io.h | 90 + 9 files changed, 1057 insertions(+) create mode 100644 drivers/staging/gs_fpgaboot/Kconfig create mode 100644 drivers/staging/gs_fpgaboot/Makefile create mode 100644 drivers/staging/gs_fpgaboot/README create mode 100644 drivers/staging/gs_fpgaboot/gs_fpgaboot.c create mode 100644 drivers/staging/gs_fpgaboot/gs_fpgaboot.h create mode 100644 drivers/staging/gs_fpgaboot/io.c create mode 100644 drivers/staging/gs_fpgaboot/io.h diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index d2beb07..c5c1c9c 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -150,4 +150,6 @@ source drivers/staging/dgnc/Kconfig source drivers/staging/dgap/Kconfig +source drivers/staging/gs_fpgaboot/Kconfig + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index bf62386..9359019 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -67,3 +67,4 @@ obj-$(CONFIG_XILLYBUS)+= xillybus/ obj-$(CONFIG_DGNC) += dgnc/ obj-$(CONFIG_DGAP) += dgap/ obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/ +obj-$(CONFIG_GS_FPGABOOT) += gs_fpgaboot/ diff --git a/drivers/staging/gs_fpgaboot/Kconfig b/drivers/staging/gs_fpgaboot/Kconfig new file mode 100644 index 000..4fbbae1 --- /dev/null +++ b/drivers/staging/gs_fpgaboot/Kconfig @@ -0,0 +1,8 @@ +# +# xilinx fpga download, fpgaboot +# +config GS_FPGABOOT + tristate Xilinx FPGA bitstream image download + default n + help + Xilinx FPGA program image download diff --git a/drivers/staging/gs_fpgaboot/Makefile b/drivers/staging/gs_fpgaboot/Makefile new file mode 100644 index 000..34cb606 --- /dev/null +++ b/drivers/staging/gs_fpgaboot/Makefile @@ -0,0 +1,4 @@ +gs_fpga-y += gs_fpgaboot.o io.o +obj-$(CONFIG_GS_FPGABOOT) += gs_fpga.o + +ccflags-$(CONFIG_GS_FPGA_DEBUG):= -DDEBUG diff --git a/drivers/staging/gs_fpgaboot/README b/drivers/staging/gs_fpgaboot/README new file mode 100644 index 000..0f301a0 --- /dev/null +++ b/drivers/staging/gs_fpgaboot/README @@ -0,0 +1,60 @@ +== +Linux Driver Source for Xilinx FPGA image download + +* Gainspeed, Inc. +* Insop Song INSOP dot SONG at GAINSPEED dot COM +== + + +TABLE OF CONTENTS. + +1. SUMMARY +2. BACKGROUND +3. DESIGN +4. HOW TO USE +5. REFERENCE + +-- +1. SUMMARY +-- + + * Download Xilinx FPGA image + * This module downloads Xilinx FPGA image using gpio pins. + +-- +2. BACKGROUND +-- + +An FPGA (Field Programmable Gate Array) is a programmable hardware that is +used in various applications. Hardware design needs to programmed through +a dedicated device or CPU assisted way (serial or parallel). + +This driver provides a way to download FPGA image. + + + +-- +3. DESIGN +-- +* load Xilinx FPGA bitstream format[1] image using kernel firmware framework, +request_firmware() +* program the Xilinx FPGA using SelectMAP (parallel) mode [2] +* FPGA prgram is done by gpio based bit-banging, as an example +* platform independent file: gs_fpgaboot.c +* platform dependent file: io.c + + +-- +4. HOW TO USE +-- + $ insmod gs_fpga.ko file=xlinx_fpga_top_bitstream.bit + $ rmmod gs_fpga +
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Wed, Jan 08, 2014 at 05:39:31PM -0500, Sean Paul wrote:
On Wed, Jan 8, 2014 at 4:36 PM, Russell King - ARM Linux
Which bits do you think would be useful to move into the core?
imx_drm_add_components() is rather imx-drm specific, especially for
the CRTCs - it carries the knowledge that the OF device to be matched
can be found in the _parent_ device, rather than the device registered
into the component helpers.
Yeah, I was thinking of imx_drm_add_components() actually. It probably
doesn't make sense to enforce the parent relationship in a generic
manner, but it would be nice to have a helper which added the various
drm components (crtc/encoder/bridge/connector) with a consistent
binding.
We have 3 different exynos boards which would have the following
superdevices (please forgive my hypothetical syntax/naming):
Board 1:
exynos-drm {
compatible = exynos,drm;
crtcs = fimd1, mixer1;
encoders = dp1, hdmi1;
bridges = ptn3460 dp1;
connectors = ptn3460, hdmi1;
};
Can we have an example with a different number of
encoders/connectors/crtcs, like:
exynos-drm {
compatible = exynos,drm;
crtcs = fimd1;
encoders = dp1, hdmi1, lvds1;
connectors = ptn3460, hdmi1;
};
Otherwise I get the impression that there is some topology of the
components or at least relationship between the components encoded
into the binding.
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- |
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
