- 11 Oct, 2013 40 commits
-
-
Ian Abbott authored
Re-tag `struct buffer_dma` to `struct s626_buffer_dma` to avoid potential namespace clashes. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Reviewed-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ian Abbott authored
Move the declaration of `struct buffer_dma` from "s626.h" to "s626.c" as it seems more at home there. After this move, "s626.h" just contains macros related to hardware registers. Signed-off-by:
-
Ian Abbott authored
Declare the static variables `trimchan[]` and `trimadrs[]` as constant data. Signed-off-by:
-
Ian Abbott authored
`s626_mc_enable()` is often called to enable some function in a control register after setting up some other registers. Precede the write to the control register with a call to `mmiowb()` to preserve mmio write ordering. `s626_mc_disable()` is called to disable some function in a control register and is often followed up by writes to other registers. Follow the write to the control register with a call to `mmiowb()` to preserve mmio write ordering. Signed-off-by:
-
Ian Abbott authored
"s626.h" defines the macros `TRUE` and `FALSE` if they are not already defined, yielding the expected numeric values. Remove the macros and replace their usage with the values `true` and `false`, respectively. Signed-off-by:
-
Ian Abbott authored
Move `s626_enc_chan_info[]` and remove its forward declaration. Signed-off-by:
-
Ian Abbott authored
Move the final lot of encoder functions to help avoid the forward declaration of `s626_enc_chan_info[]`. Signed-off-by:
-
Ian Abbott authored
Move some more functions to help avoid the forward declaration of `s626_enc_chan_info[]`. Signed-off-by:
-
Ian Abbott authored
Move some functions to help avoid the forward declaration of `s626_enc_chan_info[]`. Signed-off-by:
-
Ian Abbott authored
The `encpriv` macro relies on a local variable `dev` (of type `struct comedi_device *`) being set correctly. By a convoluted path involving the `private` data pointer of subdevice 5 (the encoder (counter) subdevice), the macro always yields a pointer to the first element of the static array `enc_private_data[]`. That holds statically constant data for each of 6 encoder channels. Instead of using the `encpriv` macro, just access the array it points to directly and get rid of the macro. Don't bother initializing the `private` member of the encoder subdevice any more. Since `enc_private_data[]` now has nothing to so with subdevice private data, rename `enc_private_data[]` to `s626_enc_chan_info[]` and rename its type from `struct enc_private` to `struct s626_enc_info`. Since the array contains unchanging, static information, declare it `const` and declare all the variables that point to it `const`. A forward declaration of `s626_enc_chan_info[]` has been added temporarily and will be removed by a later patch. Signed-off-by:
-
Ian Abbott authored
Rename the remaining CamelCase parameters and variables. Signed-off-by:
-
Ian Abbott authored
Rename the remaining non-lower-case functions. Signed-off-by:
-
Ian Abbott authored
The `set_mode_a()` and `set_mode_b()` functions use a local variable `setup` which is initialized to the value of parameter `Setup` which is not used further. Get rid of the local variable and rename the parameter to `setup`. Signed-off-by:
-
Ian Abbott authored
Rename the CamelCase members of `struct enc_private`. Since most of those are function pointers pointing to functions with similar names as the members, rename the functions they point to as well. Signed-off-by:
-
Ian Abbott authored
Rename the CamelCase members of `struct s626_private`. Signed-off-by:
-
Ian Abbott authored
Rename `struct bufferDMA` and its members to avoid CamelCase. Signed-off-by:
-
Ian Abbott authored
The `I2C_B0(ATTR, VAL)`, `I2C_B1(ATTR, VAL)` and `I2C_B2(ATTR, VAL)` macros are defined identically in "s626.h" and "s626.c". Remove the duplicates from "s626.c". Signed-off-by:
-
Ian Abbott authored
The `I2CR` and `I2CW` macros expand to the I2C read and write addresses, respectively. They are only used in one place each and include the name of a local variable `devpriv` in their expansion. Get rid of the macros and expand them in place. Signed-off-by:
-
Ian Abbott authored
Rename the `ai_continous` member of `struct s626_private` to `ai_continuous`. Signed-off-by:
-
Ian Abbott authored
The Sensoray 626 is based on the Philips SAA7146 chip using the Philips vendor and device ID for the chip, but with custom subdevice and subvendor IDs. Use the Philips IDs in the PCI device table and replace the macros for the subvendor and subdevice IDs with open-coded values. Signed-off-by:
-
Ian Abbott authored
The `DMAHandle` member of `struct bufferDMA` in "s626.h" is unused, so remove it. Signed-off-by:
-
Ian Abbott authored
Convert a printk() to a dev_err(). Signed-off-by:
-
Ian Abbott authored
Tidy up the source code in "s626.c" and make it (slightly) more readable. It's mostly whitespace changes although some large statements have been split into smaller statements. It fixes most of the checkpatch errors and warnings. Signed-off-by:
-
Ian Abbott authored
Make the comments at the top of the file conform to the CodingStyle. Signed-off-by:
-
Ian Abbott authored
Tidy up the "s626.h" header file a bit, cleaning up the whitespace and fixing overlength lines. Add multiple inclusion protection (even though it's only included once and only by "s626.c"). Remove unnecessary driver comment near the start of the file as it is more or less the same as the one in "s626.c". Remove obviously unused/useless stuff. I'm not sure what to do about the INTEL/MOTOROLA platform selection in the file. I've left it alone (set to INTEL) for now. Signed-off-by:
-
Philipp Zabel authored
Lets the IPU driver make use of the PRIME functionality introduced by the "drm: GEM CMA: Add DRM PRIME support" patch. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
This patch adds support for a drm overlay plane on DI0 using the DP. In principle, the overlay plane could also be used on DI1, but to switch the overlay plane between display interfaces, the base planes would have to be exchanged transparently while both display interfaces are inactive. Signed-off-by:
-
Sascha Hauer authored
During a device close the drm core frees all pending events in drm_events_release(). If at that time a pageflip is pending the interrupt handler will try to complete the now unitialized event resulting in a NULL pointer exception. Seen on imx-drm when userspace is killed during a page flip. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
Signed-off-by:
-
Philipp Zabel authored
Signed-off-by:
-
Sascha Hauer authored
Currently we wait for a channel until it's idle before actually disabling it. This is not needed for all channels though, so make waiting for idle a separate function and call it where necessary. Signed-off-by:
-
Philipp Zabel authored
Signed-off-by:
-
Philipp Zabel authored
Signed-off-by:
-
Philipp Zabel authored
The drm fourccs define formats not available as video4linux pixel formats, such as DRM_FORMAT_BGR565, or the DRM_FORMAT_RGBX/BGRX variants. Also, contrary to the v4l2 formats, the drm formats are well defined. This patch also fixes the BGRA32 and RGB/RGB24 internal formats to use a common internal representation. Signed-off-by:
-
Philipp Zabel authored
Signed-off-by:
-
Philipp Zabel authored
Connecting a 320x240 parallel display on i.MX6 resulted in an invalid DRDY signal because the DC would not receive NL/EOL events on every line. Reducing the allocated DMFC space from 4 slots (256 * 128-bit) to 2 slots (128 * 128-bit) solved the problem. Signed-off-by:
-
Fabio Estevam authored
Booting a mx6 with CONFIG_PROVE_LOCKING we get: ====================================================== [ INFO: possible circular locking dependency detected ] 3.12.0-rc4-next-20131009+ #34 Not tainted ------------------------------------------------------- swapper/0/1 is trying to acquire lock: (&imx_drm_device->mutex){+.+.+.}, at: [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98 but task is already holding lock: (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&crtc->mutex){+.+...}: [<800777d0>] __lock_acquire+0x18d4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805ead5c>] _mutex_lock_nest_lock+0x58/0x3a8 [<802fec50>] drm_crtc_init+0x48/0xa8 [<80457c88>] imx_drm_add_crtc+0xd4/0x144 [<8045e2e8>] ipu_drm_probe+0x114/0x1fc [<80312278>] platform_drv_probe+0x20/0x50 [<80310c68>] driver_probe_device+0x110/0x22c [<80310e20>] __driver_attach+0x9c/0xa0 [<8030f218>] bus_for_each_dev+0x5c/0x90 [<80310750>] driver_attach+0x20/0x28 [<8031034c>] bus_add_driver+0xdc/0x1dc [<803114d8>] driver_register+0x80/0xfc [<80312198>] __platform_driver_register+0x50/0x64 [<808172fc>] ipu_drm_driver_init+0x18/0x20 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c -> #1 (&dev->mode_config.mutex){+.+.+.}: [<800777d0>] __lock_acquire+0x18d4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805eb100>] mutex_lock_nested+0x54/0x3a4 [<802fe758>] drm_modeset_lock_all+0x20/0x54 [<802fead4>] drm_encoder_init+0x20/0x7c [<80457ae4>] imx_drm_add_encoder+0x88/0xec [<80459838>] imx_ldb_probe+0x344/0x4fc [<80312278>] platform_drv_probe+0x20/0x50 [<80310c68>] driver_probe_device+0x110/0x22c [<80310e20>] __driver_attach+0x9c/0xa0 [<8030f218>] bus_for_each_dev+0x5c/0x90 [<80310750>] driver_attach+0x20/0x28 [<8031034c>] bus_add_driver+0xdc/0x1dc [<803114d8>] driver_register+0x80/0xfc [<80312198>] __platform_driver_register+0x50/0x64 [<8081722c>] imx_ldb_driver_init+0x18/0x20 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c -> #0 (&imx_drm_device->mutex){+.+.+.}: [<805e510c>] print_circular_bug+0x74/0x2e0 [<80077ad0>] __lock_acquire+0x1bd4/0x1c24 [<80077fec>] lock_acquire+0x68/0x7c [<805eb100>] mutex_lock_nested+0x54/0x3a4 [<804575a8>] imx_drm_encoder_get_mux_id+0x28/0x98 [<80459a98>] imx_ldb_encoder_prepare+0x34/0x114 [<802ef724>] drm_crtc_helper_set_mode+0x1f0/0x4c0 [<802f0344>] drm_crtc_helper_set_config+0x828/0x99c [<802ff270>] drm_mode_set_config_internal+0x5c/0xdc [<802eebe0>] drm_fb_helper_set_par+0x50/0xb4 [<802af580>] fbcon_init+0x490/0x500 [<802dd104>] visual_init+0xa8/0xf8 [<802df414>] do_bind_con_driver+0x140/0x37c [<802df764>] do_take_over_console+0x114/0x1c4 [<802af65c>] do_fbcon_takeover+0x6c/0xd4 [<802b2b30>] fbcon_event_notify+0x7c8/0x818 [<80049954>] notifier_call_chain+0x4c/0x8c [<80049cd8>] __blocking_notifier_call_chain+0x50/0x68 [<80049d10>] blocking_notifier_call_chain+0x20/0x28 [<802a75f0>] fb_notifier_call_chain+0x1c/0x24 [<802a9224>] register_framebuffer+0x188/0x268 [<802ee994>] drm_fb_helper_initial_config+0x2bc/0x4b8 [<802f118c>] drm_fbdev_cma_init+0x7c/0xec [<80817288>] imx_fb_helper_init+0x54/0x90 [<800088c0>] do_one_initcall+0xfc/0x160 [<807e7c5c>] kernel_init_freeable+0x104/0x1d4 [<805e2930>] kernel_init+0x10/0xec [<8000ea68>] ret_from_fork+0x14/0x2c other info that might help us debug this: Chain exists of: &imx_drm_device->mutex --> &dev->mode_config.mutex --> &crtc->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&crtc->mutex); lock(&dev->mode_config.mutex); lock(&crtc->mutex); lock(&imx_drm_device->mutex); *** DEADLOCK *** 6 locks held by swapper/0/1: #0: (registration_lock){+.+.+.}, at: [<802a90bc>] register_framebuffer+0x20/0x268 #1: (&fb_info->lock){+.+.+.}, at: [<802a7a90>] lock_fb_info+0x20/0x44 #2: (console_lock){+.+.+.}, at: [<802a9218>] register_framebuffer+0x17c/0x268 #3: ((fb_notifier_list).rwsem){.+.+.+}, at: [<80049cbc>] __blocking_notifier_call_chain+0x34/0x68 #4: (&dev->mode_config.mutex){+.+.+.}, at: [<802fe758>] drm_modeset_lock_all+0x20/0x54 #5: (&crtc->mutex){+.+...}, at: [<802fe778>] drm_modeset_lock_all+0x40/0x54 In order to avoid this lockdep warning, remove the locking from imx_drm_encoder_get_mux_id() and imx_drm_crtc_panel_format_pins(). Tested on a mx6sabrelite and mx53qsb. Reported-by:Russell King <rmk+kernel@arm.linux.org.uk> Tested-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Malcolm Priestley authored
There is no need remove and add the control urb in device open/close. Move to the probe and disconnect. This make the USB control in/out functions always available to driver. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Sachin Kamat authored
module_spi_driver removes the boilerplate code and simplifies it. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Cc: Henry Pan <hspan@micron.com> Signed-off-by:
-
Sachin Kamat authored
module_platform_driver simplifies the code by removing the boilerplate. Signed-off-by:
-
