- May 02, 2012
-
-
Aneesh V authored
Change SDRAM timings and other settings as necessary on voltage and frequency changes. We calculate these register settings based on data from the device data sheet and inputs such a frequency, voltage state(stable or ramping), temperature level etc. TODO: frequency and voltage change handling needs to be integrated with clock framework and regulator framework respectively. This is not done today due to missing pieces in the kernel. Signed-off-by:
Aneesh V <aneesh@ti.com> Reviewed-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by:
Benoit Cousson <b-cousson@ti.com> [santosh.shilimkar@ti.com: Moved to drivers/memory from drivers/misc] Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Aneesh V authored
EMIF is an SDRAM controller used in various Texas Instruments SoCs. EMIF supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols. Add the basic infrastructure for EMIF driver that includes driver registration, probe, parsing of platform data etc. Signed-off-by:
-
Aneesh V authored
Add register offsets and bit field definitions for EMIF module in TI SoCs Signed-off-by:
-
Aneesh V authored
add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers. Right now this is used by the TI EMIF SDRAM controller driver. Signed-off-by:
-
- May 01, 2012
-
-
Jim Cromie authored
drivers/infiniband/ulp/srp/ib_srp.c #defines pr_fmt() PFX fmt, but PFX is not #defined until after <linux/*> headers are included. This results in a bad expansion of the pr_warn() in the stub function. 2084c2084 < printk("<4>" PFX "dyndbg supported only in " "CONFIG_DYNAMIC_DEBUG builds\n") Signed-off-by:
-
- Apr 30, 2012
-
-
Jim Cromie authored
1- Call dynamic_debug_init() from early_initcall, not arch_initcall. 2- Call dynamic_debug_init_debugfs() from fs_initcall, not module_init. RFC: This works for me on a 64 bit desktop and a i586 SBC, but is untested on other arches. I presume there is or was a reason original code used arch_initcall, maybe the constraints have changed. This makes facility available as soon as possible. 2nd change has a downside when dynamic_debug.verbose=1; all the vpr_info()s called in the proc-fs code are activated, causing voluminous output from dmesg. TBD: Im unsure of this explanation, but the output is there. This could be fixed by changing those callsites to v2pr_info(if verbose > 1). 1st change is still not early enough to enable pr_debugs in kernel/params, so parsing of boot-args isnt logged. The reparse of those args is however visible after params.dyndbg="+p" is processed. Signed-off-by:
Jim Cromie <jim.cromie@gmail.com> Acked-by:
Jason Baron <jbaron@redhat.com> Signed-off-by:
-
Jim Cromie authored
In dynamic-debug-howto.txt: - add section: Debug Messages at Module Initialization Time - update flags indicators in example outputs to include '=' - make flags descriptions tabular - add item on '_' flag-char - add dyndbg, boot-args examples - rewrap some paragraphs with long lines In Kconfig.debug, note that compiling with -DDEBUG enables all pr_debug()s in that code. In kernel-parameters.txt, add dyndbg and module.dyndbg items, and deprecate ddebug_query. Signed-off-by:
-
Jim Cromie authored
Pass module name into ddebug_exec_queries(), ddebug_exec_query(), and ddebug_parse_query() as separate parameter. In ddebug_parse_query(), the module name is added into the query struct before the query-string is parsed. This allows the query-string to be shorter: instead of: $modname.dyndbg="module $modname +fp" do this: $modname.dyndbg="+fp" Omitting "module $modname" from the query string is actually required for $modname.dyndbg rules; the set-only-once check added in a previous patch will throw an error if its added again. ddebug_query="..." has no $modname associated with it, so the query string may include it. This also fixes redundant "module $modname" otherwise needed to handle multiple queries per string: $modname.dyndbg="func foo +fp; func bar +fp" Signed-off-by:
-
Jim Cromie authored
Print ram usage of dynamic-debug tables and verbose section so user knows cost of enabling CONFIG_DYNAMIC_DEBUG. This only counts the size of the _ddebug tables for builtins and the __verbose section that they refer to, not those used in loadable modules. Signed-off-by:
-
Jim Cromie authored
We dont want errors while parsing ddebug_query to unload ddebug tables, so set success after tables are loaded, and return 0 after query parsing is done. Simplify error handling code since its no longer used for success, and change goto label to out_err to clarify this. Signed-off-by:
-
Jim Cromie authored
Refactor ddebug_dyndbg_boot_param_cb and ddebug_dyndbg_module_param_cb into a common helper function, and call it from both. The handling of foo.dyndbg is unneeded by the latter, but harmless. The 2 callers differ only by pr_info and the return code they pass to the helper for when an unknown param is handled. I could slightly reduce dmesg clutter by putting the vpr_info in the common helper, after the return on_err, but that loses __func__ context, is overly silent on module_cb unknown param errors, and the clutter is only when dynamic_debug.verbose=1 anyway. Signed-off-by:
-
Jim Cromie authored
With ddebug_dyndbg_boot_params_cb() handling bare dyndbg params, we dont need ddebug_query param anymore. Add a warning when processing ddebug_query= param that it is deprecated, and to change it to dyndbg= Add a deprecation notice for v3.8 to feature-removal-schedule.txt, and add a suggested deprecation period of 3 releases to the header. Signed-off-by:
-
Jim Cromie authored
This introduces a fake module param $module.dyndbg. Its based upon Thomas Renninger's $module.ddebug boot-time debugging patch from https://lkml.org/lkml/2010/9/15/397 The 'fake' module parameter is provided for all modules, whether or not they need it. It is not explicitly added to each module, but is implemented in callbacks invoked from parse_args. For builtin modules, dynamic_debug_init() now directly calls parse_args(..., &ddebug_dyndbg_boot_params_cb), to process the params undeclared in the modules, just after the ddebug tables are processed. While its slightly weird to reprocess the boot params, parse_args() is already called repeatedly by do_initcall_levels(). More importantly, the dyndbg queries (given in ddebug_query or dyndbg params) cannot be activated until after the ddebug tables are ready, and reusing parse_args is cleaner than doing an ad-hoc parse. This reparse would break options like inc_verbosity, but they probably should be params, like verbosity=3. ddebug_dyndbg_boot_params_cb() handles both bare dyndbg (aka: ddebug_query) and module-prefixed dyndbg params, and ignores all other parameters. For example, the following will enable pr_debug()s in 4 builtin modules, in the order given: dyndbg="module params +p; module aio +p" module.dyndbg=+p pci.dyndbg For loadable modules, parse_args() in load_module() calls ddebug_dyndbg_module_params_cb(). This handles bare dyndbg params as passed from modprobe, and errors on other unknown params. Note that modprobe reads /proc/cmdline, so "modprobe foo" grabs all foo.params, strips the "foo.", and passes these to the kernel. ddebug_dyndbg_module_params_cb() is again called for the unknown params; it handles dyndbg, and errors on others. The "doing" arg added previously contains the module name. For non CONFIG_DYNAMIC_DEBUG builds, the stub function accepts and ignores $module.dyndbg params, other unknowns get -ENOENT. If no param value is given (as in pci.dyndbg example above), "+p" is assumed, which enables all pr_debug callsites in the module. The dyndbg fake parameter is not shown in /sys/module/*/parameters, thus it does not use any resources. Changes to it are made via the control file. Also change pr_info in ddebug_exec_queries to vpr_info, no need to see it all the time. Signed-off-by:
-
Jim Cromie authored
Add a 3rd arg, named "doing", to unknown-options callbacks invoked from parse_args(). The arg is passed as: "Booting kernel" from start_kernel(), initcall_level_names[i] from do_initcall_level(), mod->name from load_module(), via parse_args(), parse_one() parse_args() already has the "name" parameter, which is renamed to "doing" to better reflect current uses 1,2 above. parse_args() passes it to an altered parse_one(), which now passes it down into the unknown option handler callbacks. The mod->name will be needed to handle dyndbg for loadable modules, since params passed by modprobe are not qualified (they do not have a "$modname." prefix), and by the time the unknown-param callback is called, the module name is not otherwise available. Minor tweaks: Add param-name to parse_one's pr_debug(), current message doesnt identify the param being handled, add it. Add a pr_info to print current level and level_name of the initcall, and number of registered initcalls at that level. This adds 7 lines to dmesg output, like: initlevel:6=device, 172 registered initcalls Drop "parameters" from initcall_level_names[], its unhelpful in the pr_info() added above. This array is passed into parse_args() by do_initcall_level(). CC: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Jim Cromie authored
clean up some space-before-tabs problems. Signed-off-by:
-
Jim Cromie authored
Use vpr_info to declutter code, reduce indenting, and change one additional pr_info call in ddebug_exec_queries. Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit f19420c1. It contained lots of errors and warnings and shouldn't have ever been applied, that was my fault, sorry. Cc: Markus Franke <markus.franke@s2002.tu-chemnitz.de> Cc: Evgeniy Polyakov <zbr@ioremap.net>, Signed-off-by:
-
Chanwoo Choi authored
This patch inform the state of only one cable instead of previous data including the state of 32 cables to notifee which use extcon_register_interest() function to monitor whether the specific cable is attachd or detached. Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
Myungjoo Ham <myungjoo.ham@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
- Apr 25, 2012
-
-
Dan Carpenter authored
Return -ENOMEM if the kmalloc() fails. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
- Apr 23, 2012
-
-
yan authored
create_dir is a static function used only in kobject_add_internal. There's no need to do check here, for kobject_add_internal will reject kobject with invalid name. Signed-off-by:
Yan Hong <clouds.yan@gmail.com> Signed-off-by:
-
yan authored
Signed-off-by:
-
MyungJoo Ham authored
Because extcon can also be a switch class for legacy userspace (Android) and is a superset of switch class in drivers/staging/android/switch, switch class may be removed. - Remove switch class - Remove switch class consideration in extcon class Signed-off-by:
-
- Apr 20, 2012
-
-
MyungJoo Ham authored
Signed-off-by:
-
MyungJoo Ham authored
There could be cables that t recannot be attaches simulatenously. Extcon device drivers may express such information via mutually_exclusive in struct extcon_dev. For example, for an extcon device with 16 cables (bits 0 to 15 are available), if mutually_exclusive = { 0x7, 0xC0, 0x81, 0 }, then, the following attachments are prohibitted. {0, 1} {0, 2} {1, 2} {6, 7} {0, 7} and every attachment set that are superset of one of the above. For the detail, please refer to linux/include/linux/extcon.h. The concept is suggested by NeilBrown <neilb@suse.de> Signed-off-by: -
MyungJoo Ham authored
One switch device (e.g., MUIC(MAX8997, MAX77686, ...), and some 30-pin devices) may have multiple cables attached. For example, one 30-pin port may inhabit a USB cable, an HDMI cable, and a mic. Thus, one switch device requires multiple state bits each representing a type of cable. For such purpose, we use the 32bit state variable; thus, up to 32 different type of cables may be defined for a switch device. The list of possible cables is defined by the array of cable names in the switch_dev struct given to the class. Signed-off-by:
-
Donggeun Kim authored
State changes of extcon devices have been notified via kobjet_uevent. This patch adds notifier interfaces in order to allow device drivers to get notified easily. Along with notifier interface, extcon_get_extcon_dev() function is added so that device drivers may discover a extcon_dev easily. Signed-off-by:
Donggeun Kim <dg77.kim@samsung.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> -- Changes from RFC - Renamed switch to extcon - Bugfix: extcon_dev_unregister() - Bugfix: "edev->dev" is "internal" data. - Added kerneldoc comments. - Reworded comments. Signed-off-by:
-
MyungJoo Ham authored
The generic GPIO extcon driver (an external connector device based on GPIO control) and imported from Android kernel. switch: switch class and GPIO drivers. (splitted) Author: Mike Lockwood <lockwood@android.com> switch: gpio: Don't call request_irq with interrupts disabled Author: Arve Hjønnevåg <arve@android.com> switch_gpio: Add missing #include <linux/interrupt.h> Author: Mike Lockwood <lockwood@android.com> Signed-off-by:
-
MyungJoo Ham authored
External connector class (extcon) is based on and an extension of Android kernel's switch class located at linux/drivers/switch/. This patch provides the before-extension switch class moved to the location where the extcon will be located (linux/drivers/extcon/) and updates to handle class properly. The before-extension class, switch class of Android kernel, commits imported are: switch: switch class and GPIO drivers. (splitted) Author: Mike Lockwood <lockwood@android.com> switch: Use device_create instead of device_create_drvdata. Author: Arve Hjønnevåg <arve@android.com> In this patch, upon the commits of Android kernel, we have added: - Relocated and renamed for extcon. - Comments, module name, and author information are updated - Code clean for successing patches - Bugfix: enabling write access without write functions - Class/device/sysfs create/remove handling - Added comments about uevents - Format changes for extcon_dev_register() to have a parent dev. Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit a15d49fd as that patch broke the build. Cc: Hannes Reinecke <hare@suse.de> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Kees Cook authored
The HOWTO document needed updating for the new kernel versioning. The git URI for -next was updated as well. Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
- Apr 18, 2012
-
-
Hannes Reinecke authored
klist_iter_init_node() takes a node as a start argument. However, this node might not be valid anymore. This patch updates the klist_iter_init_node() and dependent functions to return an error if so. All calling functions have been audited to check for a return code here. Signed-off-by:
Hannes Reinecke <hare@suse.de> Cc: Greg Kroah-Hartmann <gregkh@linuxfoundation.org> Cc: Kay Sievers <kay@vrfy.org> Cc: Stable Kernel <stable@kernel.org> Cc: Linux Kernel <linux-kernel@vger.kernel.org> Signed-off-by:
-
H Hartley Sweeten authored
The variable 'system_kset' is only referenced in this file and should be marked static to prevent it from being exposed globally. This quiets the sparse waring: warning: symbol 'system_kset' was not declared. Should it be static? Also, remove the comment since drivers/base/sys.c has now been deleted. Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Randy Dunlap authored
Fix kernel-doc warnings in dma-buf.c: Warning(drivers/base/dma-buf.c:305): No description found for parameter 'dmabuf' Warning(drivers/base/dma-buf.c:305): Excess function parameter 'dma_buf' description in 'dma_buf_begin_cpu_access' Warning(drivers/base/dma-buf.c:332): No description found for parameter 'dmabuf' Warning(drivers/base/dma-buf.c:332): Excess function parameter 'dma_buf' description in 'dma_buf_end_cpu_access' Warning(drivers/base/dma-buf.c:350): No description found for parameter 'dmabuf' Warning(drivers/base/dma-buf.c:350): Excess function parameter 'dma_buf' description in 'dma_buf_kmap_atomic' Warning(drivers/base/dma-buf.c:367): No description found for parameter 'dmabuf' Warning(drivers/base/dma-buf.c:367): Excess function parameter 'dma_buf' description in 'dma_buf_kunmap_atomic' Warning(drivers/base/dma-buf.c:385): No description found for parameter 'dmabuf' Warning(drivers/base/dma-buf.c:385): Excess function parameter 'dma_buf' description in 'dma_buf_kmap' Warning(drivers/base/dma-buf.c:402): No description found for parameter 'dmabuf' Warning(drivers/base/dma-buf.c:402): Excess function parameter 'dma_buf' description in 'dma_buf_kunmap' Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Peter Korsgaard authored
Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by:
-
Peter Korsgaard authored
Signed-off-by:
-
Dan Carpenter authored
We should unlock here before returning. Signed-off-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
- Apr 11, 2012
-
-
Markus Franke authored
This patch offers the possibility to disables irqs during w1_write_bit() and w1_reset_bus() operations as timing requirements are very strict for the 1-wire bus protocol. Per default interrupts are enabled but can be disabled via the module parameter "w1_disable_irqs". Extend 1-wire reset pulse length from 480us to 500us as 480us is the minimum requirement for the 1-wire reset/presence pulse. Signed-off-by:
Markus Franke <franm@hrz.tu-chemnitz.de> Acked-by:
-
Markus Franke authored
This patch adds a 1-wire slave device driver for the DS28E04-100. Signed-off-by:
-
- Apr 09, 2012
-
-
Dmitry Artamonow authored
W1 core prints "Failed to register master driver" if error happens on registering SLAVE driver. Fix it. Signed-off-by:
Dmitry Artamonow <mad_soft@inbox.ru> Acked-by:
-
Dan Carpenter authored
This function returns negative error codes, but because the type is u16 they get truncated into positive numbers. It doesn't look like the callers care, but we should fix it anyway as a cleanup. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
