The omap_vout driver tries to set the DSS overlay_info using set_overlay_info()
when the physical address for the overlay is still not configured. This happens
in omap_vout_probe() and vidioc_s_fmt_vid_out().
The calls to omapvid_init(which internally calls set_overlay_info()) are removed
from
On Tue, Mar 06, 2012 at 04:25:30, Tony Lindgren wrote:
Hi,
* Vaibhav Hiremath hvaib...@ti.com [120119 06:01]:
OMAP device has 32k-sync timer which is currently used as a
clocksource in the kernel (omap2plus_defconfig).
The current implementation uses compile time selection between
On Wed, Mar 07, 2012 at 02:49:46AM +, Ming Lei wrote:
Hi Will,
Hello,
On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon will.dea...@arm.com wrote:
Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
you may miss samples if they occur during critical kernel sections
On Tue, Mar 06, 2012 at 04:26:40, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120119 06:01]:
Add missing idle_st bit for 32k-sync timer into the prcm-common
header file, required for hwmod data.
These should be queued by Paul when the related hwmod changes
are done.
Paul,
On Tue, Mar 06, 2012 at 04:27:52, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120123 00:16]:
On Thu, Jan 19, 2012 at 19:58:21, Hiremath, Vaibhav wrote:
This patch series cleans up the existing 32k-sync timer implementation
without any major code change and adds hwmod lookup
On Tue, Mar 06, 2012 at 04:44:13, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [120213 07:36]:
On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@ti.com
Afzal Update SRAM
On Monday 05 March 2012 01:24 PM, Rajendra Nayak wrote:
On Friday 24 February 2012 03:40 PM, Rajendra Nayak wrote:
Chris,
On Thursday 23 February 2012 04:56 PM, Rajendra Nayak wrote:
Re-sending as these patches did not make it to the lists due to
issues with my 'git send-email'
This series
On Tue, Mar 06, 2012 at 05:01:53PM +, Arnd Bergmann wrote:
On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote:
On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann a...@arndb.de wrote:
I think 'depends' would be better
On Wed, 2012-03-07 at 11:49 +0100, Sebastian Reichel wrote:
Hi Linus,
I've noticed that you have not pulled this (yet). I would like to
confirm that we at Intel are also very interested to have HSI upstream.
I believe this code base is more than worth merging since it has many
The GPIO trigger parameter is of type unsigned.
enum {
IRQ_TYPE_NONE = 0x,
IRQ_TYPE_EDGE_RISING= 0x0001,
IRQ_TYPE_EDGE_FALLING = 0x0002,
IRQ_TYPE_EDGE_BOTH = (IRQ_TYPE_EDGE_FALLING |
IRQ_TYPE_EDGE_RISING),
Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
_gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
This is redundant in omap_gpio_suspend() because wakeup_en
register automatically gets
In omap_gpio_runtime_resume() the context restore should be independent
of bank-enabled_non_wakeup_gpios. This was preventing context restore
of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja govindraj.r...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must read from regs-irqenable
instead of overwriting it with
Since we already have bank-context.wake_en to keep track
of gpios which are wakeup enabled, there is no need to have
this field any more.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
There are two ways through which wakeup_en register can be programmed
using gpiolib APIs as shown below. It is seen that in the second case
in _set_gpio_wakeup(), even though bank-suspend_wakeup is updated
correctly, its value is not programmed in wakeup_en register. Fix this.
This function should be capable of both enabling and disabling interrupts
based upon the *enable* parameter. Right now the function only enables
the interrupt and *enable* is not used at all. So add the interrupt
disable capability also using the parameter.
Signed-off-by: Tarun Kanti DebBarma
In the existing _set_gpio_dataout_*() implementation, the dataout
register is overwritten every time the function is called. This is
not intended behavior because that would end up one user of a GPIO
line overwriting what is written by another. Fix this so that previous
value is always preserved
There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask()
which writes to dataout register and the dataout context must be saved.
It is missing in the first function, _set_gpio_dataout_reg(). Fix this.
Reported-by: Govindraj Raja govindraj.r...@ti.com
Signed-off-by: Tarun
Since we already have context.fallingdetect and context.risingdetect
there is no more need to have these additional fields. Also, getting
rid of extra reads associated with them.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
The cleanup is mostly getting rid of redundant fields in struct gpio_bank{}
as we already have them as part of bank-context now. Also, remove un-used
variable from gpio_irq_handler.
The fixes include correction of _set_gpio_irqenable() implementation,
missing wakeup_en register update in
This local variable is just assigned zero and then OR'ed
with isr. It does not appear to serve any purpose and so
removing it.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
un-necessary operation to compute gpio mask. The gpio offset passed
to gpio_get() is sufficient to do that.
Here is Russell's original comment:
Can someone explain to me this:
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
There is no more need to have saved_wakeup because bank-context.wake_en
already holds that value. So getting rid of read/write operation associated
with this field.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe
On Thu, Jan 19, 2012 at 02:14:19PM +0200, Artem Bityutskiy wrote:
On Fri, 2012-01-13 at 15:25 +0200, Carlos Chinea wrote:
Hi Linus,
I have been working in an HSI framework. The High Speed Synchronous
Serial Interface (HSI) is a serial interface mainly used for
connecting application
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote:
There are two ways through which wakeup_en register can be programmed
using gpiolib APIs as shown below. It is seen that in the second case
in _set_gpio_wakeup(), even though bank-suspend_wakeup is updated
correctly, its value is
On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Can there be more than one
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote:
Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
_gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
This is redundant in
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask()
which writes to dataout register and the dataout context must be saved.
It is missing in the first function, _set_gpio_dataout_reg(). Fix this.
On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote:
In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
un-necessary operation to compute gpio mask. The gpio offset passed
to gpio_get() is sufficient to do that.
Here is Russell's original comment:
Can someone
On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I have to say I don't know much about DMM, but my
understanding is that
DMM is a bigger entity, of which TILER is
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
In omap_gpio_runtime_resume() the context restore should be independent
of bank-enabled_non_wakeup_gpios. This was preventing context restore
of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1,
On Wednesday 07 March 2012 12:16 PM, Tarun Kanti DebBarma wrote:
In the existing _set_gpio_dataout_*() implementation, the dataout
register is overwritten every time the function is called. This is
not intended behavior because that would end up one user of a GPIO
line overwriting what is
From: Govindraj.R govindraj.r...@ti.com
Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup capability.
Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other
On 03/05/2012 09:50 PM, Tony Lindgren wrote:
Just checking.. I assume this one is already taken care of with your
other McBSP changes?
Yes it is. I just resent it against the moved McBSP driver for ASoC.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's the
first set of patches from that ordeal. There's nothing DT specific in these
patches, but they are mostly generic cleanups that make sense even without DT.
The custom pdev creation depends on the following patches
The driver for the DVI framer should handle the power-down signal of the
framer, instead of the current way of handling it in the board files.
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by:
The driver for the TFP410 DVI framer chip was named quite badly as DVI
panel driver. This patch renames the code to use tfp410 name for the
driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c |4 +-
Now that the panel-dvi driver handles the PD (power-down) GPIO, we can
remove the custom PD handling from the board files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c | 32 +
Now that the tfp410 driver has been renamed in the code, this patch
finishes the renaming by renaming the files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
To ease device tree adaptation in the future, rewrite TFP410 platform
data handling to be done inside probe(), so that probe() is the only
place where we need to handle the DT/pdata choice.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-tfp410.c | 72
The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI
instance. However, there were a few places where dsidev-id was used
instead of the function. Fix those places to use the function.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |6
The reset GPIO for Taal panel driver is currently requested in the
4430sdp board file. This patch moves the gpio request/free into the Taal
driver, where it should be.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 16
For unknown reasons we seem to have a return in each of the omapdss's
uninit functions, which is a void function.
Remove the returns.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c |2 +-
drivers/video/omap2/dss/dsi.c |2 +-
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct
The platform devices for omapdss, dss and dispc drivers are always
present, so we can use platform_driver_probe instead of
platform_driver_register.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |3 +--
drivers/video/omap2/dss/dispc.c |3 +--
We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.
There doesn't seem to be any reason for that, so this patch changes the
registration for all drivers
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinen
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each
Now that the omapdss_core device is the parent for all other dss
devices, we don't need to use the dss_runtime_get/put anymore. Instead,
enabling omapdss_core will happen automatically when a child device is
enabled.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 111 +---
Instead of having an ugly #ifdef mess in the core.c for creating debugfs
files, add a dss_debugfs_create_file() function that the dss drivers
can use to create the debugfs files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 46
Now that the core.c doesn't fail if output driver's init fails, we can
change the uses of platform_driver_register to platform_driver_probe.
This will allow us to use __init in the following patches.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c |3
Now that we are using platform_driver_probe() we can add __inits and
__exits all around.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |4 ++--
drivers/video/omap2/dss/dispc.c | 10 +-
drivers/video/omap2/dss/dpi.c | 10 +-
Change omapfb to use platform_driver_probe and add __init __exit.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
We currently have a two ways to set a default panel device for dss, to
which the overlays are connected when the omapdss driver is loaded:
- in textual format (name of the display) as cmdline parameter
- as a pointer to the panel device from board file via pdata
The current code handles this in
Hi Grant,
That fix is tightly coupled with the previous twl4030-irq change, so it
will be good to pulled it with the twl series through MFD if you are OK
with that?
Care to ack this one and the next one?
Thanks,
Benoit
On 3/2/2012 5:50 PM, Benoit Cousson wrote:
Do not use the board pdata
On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi
On Wed, 2012-03-07 at 07:06 -0600, Rob Clark wrote:
On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hmm, why does the drm core care about it?
Because it is the one generating the bus-id.. see
drivers/gpu/drm/drm_platform.c drm_platform_set_busid()
Anyways,
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I have to say I don't know much about DMM, but my
understanding is
On Wed, Mar 7, 2012 at 5:49 PM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup
Hi Rajendra,
On Wed, Mar 07 2012, Rajendra Nayak wrote:
Chris, Ping. I am basing my DT support patches on top of these cleanups.
Would be great if you can have a look and pull them in.
Chris, just realized the last two requests from me to get this merged
weren't addressed to you directly,
On Mon, Mar 5, 2012 at 3:55 PM, T Krishnamoorthy, Balaji
balaj...@ti.com wrote:
On Mon, Mar 5, 2012 at 2:46 PM, Rajendra Nayak rna...@ti.com wrote:
On Friday 02 March 2012 10:52 PM, Tony Lindgren wrote:
BTW, with -rc5, looks like re-inserting omap_hsmmc on omap4 fails
to detect any cards, and
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Does this DMM has become synonymous mean that people just started
calling TILER DMM, and thus the name has stuck, or are there technical
reasons to handle it as DMM in the kernel? If the former, and if TILER
is the
On Mon, Mar 5, 2012 at 12:18 PM, Kevin Hilman khil...@ti.com wrote:
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Mar 01, 2012 at 12:36:57PM -0800, Kevin Hilman wrote:
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit
Hi,
Arnd Olof, some urgent changes are needed, see below.
* Russell King - ARM Linux li...@arm.linux.org.uk [120307 01:34]:
On Tue, Mar 06, 2012 at 05:01:53PM +, Arnd Bergmann wrote:
On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
On Tue, Feb 28, 2012 at 12:11:37PM +0200,
* Russ Dill russ.d...@ti.com [120307 07:28]:
On Mon, Mar 5, 2012 at 12:18 PM, Kevin Hilman khil...@ti.com wrote:
In either case $SUBJECT patch is already in Tony's fixes queue, so if it
is going be merged, then my fix above is needed also to not break
Overo and any other platform that has
* Chris Ball c...@laptop.org [120307 07:11]:
Hi Balaji,
On Wed, Mar 07 2012, T Krishnamoorthy, Balaji wrote:
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
Addng the offset to platform_device resource structure
increments the start address for every insmod operation.
MMC
Hi,
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
The driver for the DVI framer should handle the power-down signal of the
framer, instead of the current way of handling it in the board files.
What does framer mean?
This patch adds power_down_gpio into the device's platform
On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data.
Hi Russ,
Russ Dill russ.d...@ti.com writes:
On Mon, Mar 5, 2012 at 12:18 PM, Kevin Hilman khil...@ti.com wrote:
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Mar 01, 2012 at 12:36:57PM -0800, Kevin Hilman wrote:
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on
On Thu, Mar 01, 2012 at 02:26:35PM +0200, Tomi Valkeinen wrote:
From: Rob Clark r...@ti.com
The OMAPDSS: HDMI: PHY burnout fix commit switched the HDMI driver
over to using a GPIO for plug detect. Unfortunately the -detect()
method was not also updated, causing HDMI to no longer work for
Tony,
Please pull the following support for using regulators to control the
on-chip VC/VP managed voltage domains.
The regulator driver support for this is already queued in the regulator
tree, and this is the supporting core work.
This combined with the CPUfreq changes to use the regulator
Dave,
Please pull the following OMAP CPUfreq driver changes for v3.4.
Thanks,
Kevin
The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059:
Linux 3.3-rc4 (2012-02-18 15:53:33 -0800)
are available in the git repository at:
On Wed, Mar 07, 2012 at 12:20:41PM -0800, Kevin Hilman wrote:
Dave,
Please pull the following OMAP CPUfreq driver changes for v3.4.
pulled, thanks.
Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
On Thu, 1 Mar 2012, Govindraj wrote:
On Wed, Feb 29, 2012 at 11:36 PM, Brian Austin brian.aus...@cirrus.com wrote:
Applying this patch gives this on my beagleboard xM revC
Linux debian 3.3.0-rc4
Unable to set up timer: unexpected error
Failed to bring up eth0.
Works for me on 3.3-rc4 +
On Wed, 7 Mar 2012, Brian Austin wrote:
On Thu, 1 Mar 2012, Govindraj wrote:
On Wed, Feb 29, 2012 at 11:36 PM, Brian Austin brian.aus...@cirrus.com
wrote:
Applying this patch gives this on my beagleboard xM revC
Linux debian 3.3.0-rc4
Unable to set up timer: unexpected error
Failed to
Otherwise we can get the following for some .config files:
arch/arm/mach-omap2/powerdomain-common.c:
In function 'omap2_pwrdm_get_mem_bank_onstate_mask':
arch/arm/mach-omap2/powerdomain-common.c:64:3: error:
implicit declaration of function 'WARN_ON'
[-Werror=implicit-function-declaration]
cc1:
Hi,
On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Arnd Olof, some urgent changes are needed, see below.
* Russell King - ARM Linux li...@arm.linux.org.uk [120307 01:34]:
On Tue, Mar 06, 2012 at 05:01:53PM +, Arnd Bergmann wrote:
On Tuesday 06 March 2012,
* Olof Johansson o...@lixom.net [120307 13:46]:
On Wed, Mar 7, 2012 at 9:10 AM, Tony Lindgren t...@atomide.com wrote:
What I got queued up in fixes-non-critical-part2 should fix all those
errors and warnings.
Arnd Olof, I've posted one fix that should be applied to arm-soc tree
at
Hi Arnd Olof,
The following contains fixes for the next merge window.
Included are the issues noted by Russell.
I've tested it against the current next tree with
omap1_defconfig, omap2plus_defconfig, and Russell's
omap3430-ldp and omap4430-sdp seed configs, and the
related allnoconfigs.
One
On Wed, Mar 7, 2012 at 2:59 PM, Tony Lindgren t...@atomide.com wrote:
The following changes since commit d82ba9954b6b2c4ac91ec6f6f42be8c5215d0619:
Peter Ujfalusi (1):
OMAP4: dma: Correct CPU version check for dma_common_ch_end
are available in the git repository at:
On Tue, Mar 6, 2012 at 10:09 AM, Ohad Ben-Cohen o...@wizery.com wrote:
Hi Arnd,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
rpmsg-fixes-and-more-for-3.4
To get a few rpmsg/remoteproc fixes, cleanups and some generalization
work for 3.4.
Again, I should
* Olof Johansson o...@lixom.net [120307 14:41]:
On Wed, Mar 7, 2012 at 2:59 PM, Tony Lindgren t...@atomide.com wrote:
The following changes since commit d82ba9954b6b2c4ac91ec6f6f42be8c5215d0619:
Peter Ujfalusi (1):
OMAP4: dma: Correct CPU version check for dma_common_ch_end
On Wed, Mar 07, 2012 at 02:44:59PM -0800, Tony Lindgren wrote:
OK thanks, will do that next time if there's something urgent.
I'll send a pull request shortly for fixes-non-critical-part2 that
should sort out the remaining issues.
FYI, I've just updated the build tree with what's in arm-soc
* Tony Lindgren t...@atomide.com [120307 13:04]:
Looks like this is needed for some .config files with
current for-next
This is because of next/master commit 6c03438ed (kernel.h: doesn't
explicitly use bug.h, so don't include it). Will update the commit
message to say:
Otherwise we can get
Otherwise we can get the following if bug.h is not included from kernel.h:
arch/arm/mach-omap2/powerdomain-common.c:
In function 'omap2_pwrdm_get_mem_bank_onstate_mask':
arch/arm/mach-omap2/powerdomain-common.c:64:3: error:
implicit declaration of function 'WARN_ON'
On Wed, Mar 7, 2012 at 5:28 PM, Tony Lindgren t...@atomide.com wrote:
Otherwise we can get the following if bug.h is not included from kernel.h:
arch/arm/mach-omap2/powerdomain-common.c:
In function 'omap2_pwrdm_get_mem_bank_onstate_mask':
arch/arm/mach-omap2/powerdomain-common.c:64:3: error:
* Olof Johansson o...@lixom.net [120307 16:59]:
On Wed, Mar 7, 2012 at 5:28 PM, Tony Lindgren t...@atomide.com wrote:
Otherwise we can get the following if bug.h is not included from kernel.h:
arch/arm/mach-omap2/powerdomain-common.c:
In function 'omap2_pwrdm_get_mem_bank_onstate_mask':
* Kevin Hilman khil...@ti.com [120307 11:42]:
Tony,
Please pull the following support for using regulators to control the
on-chip VC/VP managed voltage domains.
The regulator driver support for this is already queued in the regulator
tree, and this is the supporting core work.
This
To reduce the number of lines of data in the OMAP portion of the Linux
code base, subsequent patches will remove the lists of hwmod
interconnect links from the static hwmod data. These lists will be
built dynamically during boot. To ease this transition, this patch
centralizes the way that
N800 logs this message on boot:
[0.182281] omap_hwmod: iva: cannot be enabled for reset (3)
Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2
hwmod for OMAP2430. There is still more information to be added, but
this should resolve the immediate issue.
Signed-off-by:
The IVA hwmod data is missing some fields that cause the following
warning on boot:
[0.118011] omap_hwmod: iva: cannot be enabled for reset (3)
Fix by encoding the IP block's main functional clock, reset lines, and
clockdomain.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
The hwmod code and data format was originally designed to minimize
boot time and for autogenerated data files. Compactness was traded
for precomputation. Now that the emphasis is on reducing the number
of lines in the OMAP source tree, this trade can be reversed.
This series removes the
Several struct omap_hwmod_ocp_if records can be shared between OMAP2420
and OMAP2430. Move these shared records out of the chip-specific files
into mach-omap2/omap_hwmod_2xxx_interconnect_data.c. This should save some
memory and source lines, at the cost of readability.
Signed-off-by: Paul
The OMAP3 hwmod data listed iva2_ck as an interface clock between the
IVA and L3. This is incorrect. iva2_ck is not an interface clock.
Since it cannot auto-idle, specifying it here prevents the IVA and at
least one of the CORE clockdomains from going idle, which causes PM
problems such as these
Most IP blocks on the OMAP SoC have an interconnect link that is
intended to be used by the MPU to communicate with the IP block.
Several parts of the hwmod code need to be able to identify this link.
Currently, this is open-coded. However, future patches will change
the way that interconnect
Now that the data has been converted to use interface registration, we
can remove the (now unused) direct hwmod registration code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 124 +++---
Add support for direct IP block interconnect (link) registration to
the hwmod code via a new function, omap_hwmod_register_links(). This
will replace direct registration of hwmods, and a subsequent patch
will remove omap_hwmod_register().
This change will allow a subsequent patch to remove the
1 - 100 of 115 matches
Mail list logo
