| Age | Commit message (Collapse) | Author |
|---|
|
Use module_platform_driver() instead.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Use devm_xx api instead.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
pinctrl-single is updated on 3.10. The interface on pin configurations
are changed. So sync latest code into code base.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
pinctrl_get_device_gpio_range() only checks whether a certain GPIO pin
is in gpio range. But maybe some GPIO pins don't have back-end pinctrl
interface, it means that these pins are always configured as GPIO
function. For example, gpio159 isn't related to back-end pinctrl device
in Hi3620 while other GPIO pins are related to back-end pinctrl device.
Append pinctrl_ready_for_gpio_range() that is used to check whether
pinctrl device with GPIO range is ready. This function will be called
after pinctrl_get_device_gpio_range() fails.
If pinctrl device with GPIO range is found, it means that pinctrl device
is already launched and a certain GPIO pin just don't have back-end pinctrl
interface. Then pinctrl_request_gpio() shouldn't return -EPROBE_DEFER in
this case.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Rename PIN_CONFIG_INPUT_SCHMITT_DISABLE to
PIN_CONFIG_INPUT_SCHMITT_ENABLE. It's used to make it more generialize.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
sfc350's io registers don't support byte reading(memcpy may produce byte
reading instruction). Using readl instead of memcpy when dealing with the
io regsters.
Signed-off-by: Mingjun Zhang <zhang.mingjun@linaro.org>
|
|
Use different of match table for hi6421 pmic's child devices and hi6421
regulators. This is to decouple its dependency over hi6421 regulator. Coding
style modifications are included as well.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
|
|
remove dead code and fix code style issues, still need to rewrite
the dma wait looping to wait event timeout.
Signed-off-by: Mingjun <zhang.mingjun@linaro.org>
|
|
Set gate clock falg to 0, the seventh parameter should be 0 for hi3620.
Signed-off-by: LiXin <li.xin@linaro.org>
|
|
Add static to global varialbe in clk-hs.c.
Signed-off-by: LiXin <li.xin@linaro.org>
|
|
Solve sysctrl redefine for hi3620.
Signed-off-by: LiXin <li.xin@linaro.org>
|
|
Remove debugging printk()'s added during hi6421 regulator driver
development.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
|
|
Refactored hi6421 regulators as children of MFD device, and add more
regulator operation functions.
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
|
|
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
|
|
|
|
|
|
|
|
Add clock driver based on common clock framework to hi4511.
Signed-off-by: LiXin <li.xin@linaro.org>
|
|
Hisilicon Serial NOR Flash controller provide three ways to access the
serial NOR flash chip: by reg interface, mapping it to a range of bus
address and using dma.
This driver implement the dma read/write ops and reg erase ops.
Signed-off-by: Mingjun Zhang <troy.zhangmingjun@huawei.com>
|
|
Add support hisilicon i2c driver, which reuse designware i2c ip
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
|
|
Check accessor_flags before reading DW_IC_COMP_TYPE
Give chance to platform no such register
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
|
|
Add dmaengine driver for hisilicon k3 platform based on virt_dma
Tested with dmatest.ko
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
|
|
Currently slave DMA channels are requested by calling dma_request_channel()
and requires DMA clients to pass various filter parameters to obtain the
appropriate channel.
With device-tree being used by architectures such as arm and the addition of
device-tree helper functions to extract the relevant DMA client information
from device-tree, add a new function to request a slave DMA channel using
device-tree. This function is currently a simple wrapper that calls the
device-tree of_dma_request_slave_channel() function.
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
In the current implementation of the OF DMA helpers, read-copy-update (RCU)
linked lists are being used for storing and accessing the DMA controller data.
This part of implementation is based upon V2 of the DMA helpers by Nicolas [1].
During a recent review of RCU, it became apparent that the code is missing the
required rcu_read_lock()/unlock() calls as well as synchronisation calls before
freeing any memory protected by RCU.
Having looked into adding the appropriate RCU calls to protect the DMA data it
became apparent that with the current DMA helper implementation, using RCU is
not as attractive as it may have been before. The main reasons being that ...
1. We need to protect the DMA data around calls to the xlate function.
2. The of_dma_simple_xlate() function calls the DMA engine function
dma_request_channel() which employs a mutex and so could sleep.
3. The RCU read-side critical sections must not sleep and so we cannot hold
an RCU read lock around the xlate function.
Therefore, instead of using RCU, an alternative for this use-case is to employ
a simple spinlock inconjunction with a usage count variable to keep track of
how many current users of the DMA data structure there are. With this
implementation, the DMA data cannot be freed until all current users of the
DMA data are finished.
This patch is based upon the DMA helpers fix for potential deadlock [2].
[1] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[2] http://marc.info/?l=linux-arm-kernel&m=134859982520984&w=2
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
In the latest version of the OF dma handlers I added support (rather hastily)
to exhaustively search for an available dma slave channel, for the use-case
where we have alternative slave channels that can be used. In the current
implementation a deadlock scenario can occur causing the CPU to loop forever.
The scenario is as follows ...
1. There are alternative channels avaialble
2. The first channel that is found by calling of_dma_find_channel() is not
available and so the call to the xlate function returns NULL. In this case
we will call of_dma_find_channel() again but we will return the same channel
that we found the first time and hence, again the xlate will return NULL and
we will loop here forever.
Fix this potential deadlock by just using a single for-loop and not a for-loop
nested in a do-while loop. This change also replaces the function
of_dma_find_channel() with of_dma_match_channel() which performs a simple check
to see if a DMA channel matches the name specified.
I have tested this implementation on an OMAP4 panda board by adding a dummy
DMA specifier, that will cause the xlate function to return NULL, to the
beginning of a list of DMA specifiers for a DMA client.
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, "dmaengine: add helper function to request a slave DMA
channel") which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
char *name)
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to easily
support them with regard to device tree. Ideally, these should be migrated
to DMA engine. However, if this is not possible, then they should still be
able to use this binding, the only constaint imposed by this implementation
is that when requesting a DMA channel via of_dma_request_slave_channel(), it
will return a type of dma_chan.
This implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I
have validated that MMC is working on the PANDA board with this implementation.
My development branch for testing on OMAP can be found here [5].
v6: - minor corrections in DMA binding documentation
v5: - minor update to binding documentation
- added loop to exhaustively search for a slave channel in the case where
there could be alternative channels available
v4: - revert the removal of xlate function from v3
- update the proposed binding format and APIs based upon discussions [3]
v3: - avoid passing an xlate function and instead pass DMA engine parameters
- define number of dma channels and requests in dma-controller node
v2: - remove of_dma_to_resource API
- make property #dma-cells required (no fallback anymore)
- another check in of_dma_xlate_onenumbercell() function
[1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
[2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[3] http://marc.info/?l=linux-omap&m=133582085008539&w=2
[4] http://pad.linaro.org/arm-mini-summit-2012
[5] https://github.com/jonhunter/linux/tree/dev-dt-dma
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Support the operation of generic pinconf. The supported config arguments
are INPUT_SCHMITT, INPUT_SCHMITT_DISABLE, POWER_SOURCE, BIAS_DISABLE,
BIAS_PULLUP, BIAS_PULLDOWN, SLEW_RATE.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Since Hisilicon's pin controller is divided into two parts. One is the
function mux, and the other is pin configuration. These two parts are
in the different memory regions. So make pinctrl-single,function-mask
as optional property. Then we can define pingroups without valid
function mux that is only used for pin configuration.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Add the support of dumping pin configuration.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Add PIN_CONFIG_SLEW_RATE parameter into pinconf-generic driver.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Since gpio driver could create gpio range in DTS, it could invokes
pinctrl_request_gpio(). In the pinctrl-single driver, it needs to
configure pins with gpio function mode.
A new gpio function range should be created in DTS file in below.
pinctrl-single,gpio-range = <phandle pin_offset nr_pins gpio_func>;
range: gpio-range {
#pinctrl-single,gpio-range-cells = <3>;
};
The difference between gpio-ranges property in gpio driver and
pinctrl-single,gpio-range property in pinctrl-single driver.
1. gpio-ranges = <phandle gpio_offset_in_chip pin_offset nr_pins>
gpio-ranges = < &pmx0 0 89 1 &pmx0 1 89 1 &pmx0 2 90 1
&pmx0 3 90 1 &pmx0 4 91 1 &pmx0 5 92 1>;
2. gpio driver could get pin offset from gpio-ranges property.
pinctrl-single driver could get gpio function mode from gpio_func
that is stored in @gpiofuncs list in struct pcs_device.
This new pinctrl-single,gpio-range is used as complement for
gpio-ranges property in gpio driver.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Replace subsys initcall by module initcall level. Since pinctrl
driver is already launched before gpio driver. It's unnecessary
to set gpio driver in subsys init call level.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Add the pl061_gpio_request() to request pinctrl. Create the logic
between pl061 gpio driver and pinctrl (pinctrl-single) driver.
While a gpio pin is requested, it will request pinctrl driver to
set that pin with gpio function mode. So pinctrl driver should
append .gpio_request_enable() in pinmux_ops.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
In original implementation, irq base is always specified in platform
data. If it's not specified, pl061 gpio driver can't pass the probe()
function since irq base is missing. While moving to device tree, everything
should be parsed from DTS file. So allocate irq dynamically for irq
base.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
gpiochip_find_base() always tries to find valid gpio with descend order.
It's inconvient if gpio information is passing from DTS. Now try to find
valid gpio with ascend order.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Since index++ calculates from 0, the checking condition of "while
(index++)" is always fake. So replace it by unconditional loop.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Add gpio offset into "gpio-range-cells" property. It's used to support
sparse pinctrl range in gpio chip.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
gpiochip_add_pin_range() needs pinctrl device name as parameter.
Currently the parameter is pinctrl description name. So fix it.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
Add new function to get devname from pinctrl_dev. pinctrl_dev_get_name()
can only get pinctrl description name. If we want to use gpio driver to
find pinctrl device node, we need to fetch the pinctrl device name.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
If amba serial driver is probed defer, amba serial driver may be
probed after init process. So the error log shows in below.
[ 0.389403] Warning: unable to open an initial console.
[ 0.390107] Freeing init memory: 2328K
It results in serial console not enabled. So replace arch_initcall
by module_init on pl011_init(). The boot sequence is changed in below.
pinctrl driver --> amba serial driver --> init process
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
|
|
If uart driver is probed defer, console_setup will be called later
after __init && __initdata sections destroyed. And amba_console isn't
defined in __init or __initdata section. So we needn't define
pl011_console_setup() && pl011_console_get_options() in __init section.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
|
|
Add fix rate clock support with device tree on Hisilicon SoC.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input subsystem fixes from Dmitry Torokhov:
"Two small driver fixups and a documentation update for managed input
devices"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: wacom - fix wacom_set_report retry logic
Input: document that unregistering managed devices is not necessary
Input: lm8323 - fix checking PWM interrupt status
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
Pull xen fixes from Konrad Rzeszutek Wilk:
"Two fixes:
- A simple bug-fix for redundant NULL check.
- CVE-2013-0228/XSA-42: x86/xen: don't assume %ds is usable in
xen_iret for 32-bit PVOPS
and two reverts:
- Revert the PVonHVM kexec. The patch introduces a regression with
older hypervisor stacks, such as Xen 4.1."
* tag 'stable/for-linus-3.8-rc7-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
Revert "xen PVonHVM: use E820_Reserved area for shared_info"
Revert "xen/PVonHVM: fix compile warning in init_hvm_pv_info"
xen: remove redundant NULL check before unregister_and_remove_pcpu().
x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.
|
|
As reported by Klaus Schmidinger:
"In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a
device (using stb0899). After this call I check 'errno' for
EOPNOTSUPP to determine whether this device supports this call. This
used to work just fine, until a few months ago I noticed that my
devices using stb0899 didn't display their signal quality in VDR's OSD
any more. After further investigation I found that
ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but
rather ENOTTY. And since I stop getting the signal quality in case
any unknown errno value appears, this broke my signal quality query
function."
While the changes reflect what is there at:
http://comments.gmane.org/gmane.linux.kernel/1235728
it does cause regression on userspace. So, revert it to stop the
damage.
This reverts commit 177ffe506cf8 ("[media] dvb_frontend: return -ENOTTY
for unimplement IOCTL").
Reported-by: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Pull sparc fixes from David Miller:
"A couple small fixes for sparc including some THP brown-paper-bag
material:
1) During the merging of all the THP support for various
architectures, sparc missed adding a
HAVE_ARCH_TRANSPARENT_HUGEPAGE to it's Kconfig, oops.
2) Sparc needs to be mindful of hugepages in get_user_pages_fast().
3) Fix memory leak in SBUS probe, from Cong Ding.
4) The sunvdc virtual disk client driver has a test of the bitmask of
vdisk server supported operations which was off by one bit"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sunvdc: Fix off-by-one in generic_request().
sparc64: Fix get_user_pages_fast() wrt. THP.
sparc64: Add missing HAVE_ARCH_TRANSPARENT_HUGEPAGE.
sparc: kernel/sbus.c: fix memory leakage
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fix from Bjorn Helgaas:
"This is another fix for v3.8. It fixes an oops that happens when a
Thunderbolt adapter is unplugged (remove device, poll for PME events
on no-longer-existing device, oops)."
* tag '3.8-pci-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI/PM: Clean up PME state when removing a device
|
|
Pull omapdss fixes from Tomi Valkeinen:
"It'd be great if these two late fixes would still make it into 3.8.
The other one fixes ARM kernel compilation when using 'allyesconfig',
and the other makes DPI displays function again on OMAP3630 boards:
- Fix ARM compilation with "allyesconfig" (omapdrm: fix the
dependency to omapdss)
- fix DPI displays on OMAP3630 (OMAPDSS: add FEAT_DPI_USES_VDDS_DSI
to omap3630_dss_feat_list)"
* tag 'omapdss-for-3.8-rc8' of git://gitorious.org/linux-omap-dss2/linux:
omapdrm: fix the dependency to omapdss
OMAPDSS: add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list
|
|
The 'operations' bitmap corresponds one-for-one with the operation
codes, no adjustment is necessary.
Reported-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
omapdrm uses "select" in Kconfig to enable omapdss. This doesn't work
correctly, as "select" forces omapdss to be enabled in the config even
if it normally could not be enabled because of missing Kconfig
dependencies.
This causes a build break on ARM, when using allyesconfig:
drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
Instead of using select, this patch changes omapdrm to use "depend
on".
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
