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 > > > > 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 > --- > 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 --- 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 -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( 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: [PATCH 3/3] staging: comedi: usbduxsigma: removing unneccesay attached info
On 2014-01-07 21:43, Bernd Porr wrote: Comedi core now reports that a device has been attached so that the driver itself won't need to do it any longer. The driver now just outputs the offset of the ADC converter which is a soft indicator of the health of the board and also the user can grep this value from the kernel log easier for debugging purposes. Signed-off-by: Bernd Porr --- drivers/staging/comedi/drivers/usbduxsigma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/usbduxsigma.c b/drivers/staging/comedi/drivers/usbduxsigma.c index ff521b3..3beeb12 100644 --- a/drivers/staging/comedi/drivers/usbduxsigma.c +++ b/drivers/staging/comedi/drivers/usbduxsigma.c @@ -1661,7 +1661,7 @@ static int usbduxsigma_auto_attach(struct comedi_device *dev, return offset; } - dev_info(dev->class_dev, "attached, ADC_zero = %x\n", offset); + dev_info(dev->class_dev, "ADC_zero = %x\n", offset); return 0; } Reviewed-by: Ian Abbott (I guess a few other drivers will also have unnecessary "attached" dev_info messages now as well.) -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( 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: [PATCH 2/3] staging: comedi: usbduxsigma: return failure of auto attach
On 2014-01-07 21:43, Bernd Porr wrote: The function usbduxsigma_getstatusinfo() returns a negative value in case there has been a communication error with the board. This should always work and if this communication fails then there is something seriously wrong with the board. This is now returned to the caller so that it can terminte the auto attachement. The return command also prevents printing out the offset value in case of a fault. Signed-off-by: Bernd Porr --- drivers/staging/comedi/drivers/usbduxsigma.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/usbduxsigma.c b/drivers/staging/comedi/drivers/usbduxsigma.c index 194c686..ff521b3 100644 --- a/drivers/staging/comedi/drivers/usbduxsigma.c +++ b/drivers/staging/comedi/drivers/usbduxsigma.c @@ -1655,9 +1655,11 @@ static int usbduxsigma_auto_attach(struct comedi_device *dev, } offset = usbduxsigma_getstatusinfo(dev, 0); - if (offset < 0) + if (offset < 0) { dev_err(dev->class_dev, - "Communication to USBDUXSIGMA failed! Check firmware and cabling\n"); + "Communication to USBDUXSIGMA failed! Check firmware and cabling.\n"); + return offset; + } dev_info(dev->class_dev, "attached, ADC_zero = %x\n", offset); Reviewed-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( 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: [PATCH] comedi: Humusoft MF634 and MF624 DAQ cards driver
On 2014-01-08 08:35, Rostislav Lisovy wrote: 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 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 --- 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 I'll wait for the v3 patch, but apart from that it looks fine to me. I suppose it could be argued that the driver only uses 2 of the 3 BARs it ioremaps (a different 2 for each card), but they're only single page mappings. -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( 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: [PATCH 1/3] mfd: Add realtek USB card reader driver
On Wed, Jan 08, 2014 at 03:56:05PM +0800, Roger Tseng wrote: > Hi Dan, > > >> +int rtsx_usb_ep0_write_register(struct rtsx_ucr *ucr, u16 addr, > >> + u8 mask, u8 data) > >> +{ > >> + u16 value = 0, index = 0; > >> + > >> + value |= (u16)(3 & 0x03) << 14; > >> + value |= (u16)(addr & 0x3FFF); > > > >Don't do pointless things: > > > >value |= 0x03 << 14; > >value |= addr & 0x3FFF; > > > >> + value = ((value << 8) & 0xFF00) | ((value >> 8) & 0x00FF); > > > >This is an endian conversion? It is buggy. Use the kernel endian > >conversion functions cpu_to_le16(). > > This is not a conversion for endianess with respect to CPU but for > command format of the device. It should always be performed > regardless of platform. > > In other words, it could be equivalent to: > value |= 0x03 << 6; // lower byte > value |= (addr & 0x3F00) >> 8; // lower byte > value |= (addr & 0xFF) << 8; //higher byte > > We think the previous form is easier to read. Should we keep it or > change to the later one? To me it's really weird that the standard would specify that the address is in byte swapped reversed CPU-endian order. But if that's what it says then I don't care about formatting details. The original code is fine. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Re: product inquiry
Hello Sales Manager, Thank for the response.Please find attached especificaзгo for profoma invoice. Kindly revisгo and send final quote with best prices so we send PO imediatamente. Any pregunta, please ask. Saludos, Jose Benitez Anastacio Bustamante 76 Int.8 Francisco Sarabia,C.P.45235, Zapopan,Jalisco, Mexico Tel: (33) 36.30.58.59 Email: jbenitez...@yahoo.com.mx <>___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3.6 08/19] ozwpan: slight optimization of addr compare
On 08/01/14 02:53, Ding Tianhong wrote: Use possibly more efficient ether_addr_equal instead of memcmp. Cc: Rupesh Gujare Cc: Greg Kroah-Hartman Cc: de...@driverdev.osuosl.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Tan Xiaojun Signed-off-by: Ding Tianhong --- drivers/staging/ozwpan/ozcdev.c | 2 +- drivers/staging/ozwpan/ozproto.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c index 6ce0af9..c363f66 100644 --- a/drivers/staging/ozwpan/ozcdev.c +++ b/drivers/staging/ozwpan/ozcdev.c @@ -448,7 +448,7 @@ int oz_cdev_start(struct oz_pd *pd, int resume) } spin_lock(&g_cdev.lock); if ((g_cdev.active_pd == NULL) && - (memcmp(pd->mac_addr, g_cdev.active_addr, ETH_ALEN) == 0)) { + ether_addr_equal(pd->mac_addr, g_cdev.active_addr)) { oz_pd_get(pd); g_cdev.active_pd = pd; oz_dbg(ON, "Active PD arrived\n"); diff --git a/drivers/staging/ozwpan/ozproto.c b/drivers/staging/ozwpan/ozproto.c index 88714ec..19a2521 100644 --- a/drivers/staging/ozwpan/ozproto.c +++ b/drivers/staging/ozwpan/ozproto.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include "ozdbg.h" @@ -180,7 +181,7 @@ static struct oz_pd *oz_connect_req(struct oz_pd *cur_pd, struct oz_elt *elt, spin_lock_bh(&g_polling_lock); list_for_each(e, &g_pd_list) { pd2 = container_of(e, struct oz_pd, link); - if (memcmp(pd2->mac_addr, pd_addr, ETH_ALEN) == 0) { + if (ether_addr_equal(pd2->mac_addr, pd_addr)) { free_pd = pd; pd = pd2; break; @@ -597,7 +598,7 @@ struct oz_pd *oz_pd_find(const u8 *mac_addr) spin_lock_bh(&g_polling_lock); list_for_each(e, &g_pd_list) { pd = container_of(e, struct oz_pd, link); - if (memcmp(pd->mac_addr, mac_addr, ETH_ALEN) == 0) { + if (ether_addr_equal(pd->mac_addr, mac_addr)) { atomic_inc(&pd->ref_count); spin_unlock_bh(&g_polling_lock); return pd; Acked-by: Rupesh Gujare Thanks, -- Regards, Rupesh Gujare ___ 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 > > 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 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Tue, Jan 07, 2014 at 03:18:21PM -0500, Sean Paul wrote: > On Thu, Jan 2, 2014 at 4:27 PM, Russell King > 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. -- 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 > 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 > --- > 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 --- 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 + * + * 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 +#include +#include +#include +#include +#include +#include + +#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 +* the max lengths specified. We will however, reserve room +* for the string terminating character - in the utf16s_utf8s()
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 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 >> 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 > --- > 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 > > Signed-off-by: Lucas Stach > Signed-off-by: Philipp Zabel 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 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 > --- > 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 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
Re: [PATCH 5/6] beeceem: Fix newline issues at opening braces of conditional statements in InterfaceRx.c
On Wed, Jan 08, 2014 at 11:15:09PM +0100, Matthias Oefelein wrote: > In InterfaceRx.c, opening braces of (if-)conditionals are mostly dislocated, > meaning they are found behind an extra line break after the conditional > statement. > This patch moves the opening braces accordingly as specified by the official > conding style guidelines. Please properly line-wrap your changelog comments at 72 columns like git asks you to when you type them in... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] mmc: rtsx: fix card poweroff bug
From: Micky Ching If the host driver removed while card in the slot, the host will not power off card power correctly. This bug is produced because host eject flag set before the last mmc_set_ios callback, we should set the eject flag after power off. Signed-off-by: Micky Ching --- drivers/mmc/host/rtsx_pci_sdmmc.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c index 375a880e..c9a7328 100644 --- a/drivers/mmc/host/rtsx_pci_sdmmc.c +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c @@ -1328,7 +1328,6 @@ static int rtsx_pci_sdmmc_drv_remove(struct platform_device *pdev) pcr->slots[RTSX_SD_CARD].p_dev = NULL; pcr->slots[RTSX_SD_CARD].card_event = NULL; mmc = host->mmc; - host->eject = true; mutex_lock(&host->host_mutex); if (host->mrq) { @@ -1346,6 +1345,8 @@ static int rtsx_pci_sdmmc_drv_remove(struct platform_device *pdev) mutex_unlock(&host->host_mutex); mmc_remove_host(mmc); + host->eject = true; + mmc_free_host(mmc); dev_dbg(&(pdev->dev), -- 1.7.9.5 ___ 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 The new phase searching method is more concise and easier to understand. Signed-off-by: Micky Ching --- 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 #include -/* 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); - dev_dbg(sdmmc_dev(host), "path[%d].len = %d\n", -
[PATCH 3/3] mmc: rtsx: add support for pre_req and post_req
From: Micky Ching 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 --- 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 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
Re: [PATCH 31/31] staging: r8188eu: Fix smatch error
On Thu, Jan 02, 2014 at 04:19:33PM -0600, Larry Finger wrote: > On 01/02/2014 02:44 AM, Dan Carpenter wrote: > >On Sun, Dec 22, 2013 at 05:37:02PM -0600, Larry Finger wrote: > >>Smatch shows the following: > >> > >> CHECK drivers/staging/rtl8188eu/core/rtw_mlme_ext.c > >>drivers/staging/rtl8188eu/core/rtw_mlme_ext.c:1401 OnAssocReq() error: > >>buffer overflow 'pstapriv->sta_aid' 32 <= 32 > >> > > > >This is a false positive in Smatch. Don't do work arounds for buggy > >tools. > > > >If you have the cross function database built on the latest version of > >Smatch then I think it understands the code correctly and doesn't print > >a warning. > > When I analyzed the loop in question, I thought it resulted in a subscript > of [NUM_STA], but I now see that the largest one is [NUM_STA-1]. I will drop > this patch in the next round. > > Thanks for the info regarding a new version of Smatch. I'll update now. Ok, I've applied the first 30, but dropped this patch. thanks, greg k-h ___ 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 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 ((ulReg&0x00FF)>>16 > 0x30) { ulReg = (ulReg&0xFF00)|(0x30<<16); BeceemEEPROMBulkWrite(Adapter, (PUCHAR)&ulReg, 0xA8, 4, TRUE); } - ReadBeceemEEPROM(Adapter, 0x148, (PUINT)&ulReg); + ReadBeceemEEPROM(Adapter, 0x148, &ulReg); if ((ulReg&0x00FF)>>16 > 0x30) { ulReg = (ulReg&0xFF00)|(0x30<<16); 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 > --- > 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 --- 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 +== + + +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 + +-- +5. REFERENCE +--
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 > > Is there no way we could implement file copying in user space? > Signed-off-by: K. Y. Srinivasan > --- > 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 > + * > + * 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 > +#include > +#include > +#include > +#include > +#include > +#include Use #include for better security. > + > +#define WIN8_SRV_MAJOR 1 > +#define WIN8_SRV_MINOR 1 > +#define WIN8_SRV_VERSION (WIN8_SRV_MAJOR << 16 | WIN8_SRV_MINOR) > + > + > + Extra blank line. > +/* > + * 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; This is racy at the start. read_sema is supposed to be locked until there is a file to be copied but it starts out unlocked and we unlock it again at the start of a transaction. Sending multiple files is also racy. The "active" flag is supposed to serialize it but flags are not locks and they are not atomic. We can queue up one request in the fcopy_context pointer but it's written in a last added request overwrites the previous ones. It could overwrite the current one as well if we got really unlucky. > +} fcopy_transaction; > + > + > + Two extra newlines. > +static dev_t fcopy_dev; > +static bool daemon_died = false; daemon_died is a write only variable. > +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); > + > + Extra blank lines throughout... Never use consecutive blank lines. > +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)
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