On 18/03/15 19:37, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [150318 07:00]:
Hi,
[NOTE: RFC only. Not for merge yet.]
This is an attempt to centralize OTG functionality in the kernel.
Still work in progress but I wanted to get an early feedback
to avoid major rework. :)
Why?:
Hi,
[NOTE: RFC only. Not for merge yet.]
This is an attempt to centralize OTG functionality in the kernel.
Still work in progress but I wanted to get an early feedback
to avoid major rework. :)
Why?:
Most of the OTG drivers have been dealing with the OTG state machine
themselves and
* Roger Quadros rog...@ti.com [150318 07:00]:
Hi,
[NOTE: RFC only. Not for merge yet.]
This is an attempt to centralize OTG functionality in the kernel.
Still work in progress but I wanted to get an early feedback
to avoid major rework. :)
Why?:
Most of the OTG drivers have
Hi!
This patchset contains the missing speech data support for the
Nokia N900 modem.
Userland access goes via /dev/cmt_speech. The API is implemented in
libcmtspeechdata, which is used by ofono and the freesmartphone.org project.
Apart from that the device is also used by the phone
On Monday 02 March 2015 21:51:48 Sebastian Reichel wrote:
Hi,
On Mon, Mar 02, 2015 at 08:05:31PM +0100, Pali Rohár wrote:
On Monday 02 March 2015 05:38:50 Sebastian Reichel wrote:
This patchset contains the missing speech data support for
the Nokia N900 modem.
[...]
Hello, do
Hi,
On Mon, Mar 02, 2015 at 08:05:31PM +0100, Pali Rohár wrote:
On Monday 02 March 2015 05:38:50 Sebastian Reichel wrote:
This patchset contains the missing speech data support for the
Nokia N900 modem.
[...]
Hello, do you have also DT patches? Or no DT changes are needed?
No DT
On Monday 02 March 2015 05:38:50 Sebastian Reichel wrote:
Hi,
This patchset contains the missing speech data support for the
Nokia N900 modem.
Userland access goes via /dev/cmt_speech. The API is
implemented in libcmtspeechdata, which is used by ofono and
the freesmartphone.org project.
Hi,
This patchset contains the missing speech data support for the
Nokia N900 modem.
Userland access goes via /dev/cmt_speech. The API is implemented in
libcmtspeechdata, which is used by ofono and the freesmartphone.org project.
Apart from that the device is also used by the phone binaries
On 13/02/15 18:01, Nishanth Menon wrote:
On 02/13/2015 09:11 AM, Tomi Valkeinen wrote:
Hi,
This series adds the arch/arm/ side of the display support for DRA7 (DRA72x,
DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM
boards
is added.
The series is based on OMAPDSS
Hi,
This series adds the arch/arm/ side of the display support for DRA7 (DRA72x,
DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards
is added.
The series is based on OMAPDSS driver patches in fbdev changes for 3.20, which
have been merged to Linus' tree.
The changes
On 02/13/2015 09:11 AM, Tomi Valkeinen wrote:
Hi,
This series adds the arch/arm/ side of the display support for DRA7 (DRA72x,
DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards
is added.
The series is based on OMAPDSS driver patches in fbdev changes for 3.20,
* Dmitry Lifshitz lifsh...@compulab.co.il [141118 01:15]:
Add support for more SBC-T3x single board computers features:
* CM-T3x CoM and SB-T35 baseboard EEPROMs
* TV out
* Touchscreen
* CM-T3x30 audio
* CM-T3x30 keypad
Applying all into omap-for-v3.19/dt-v2 thanks.
Tony
Dmitry
* Tony Lindgren t...@atomide.com [141121 16:04]:
* Dmitry Lifshitz lifsh...@compulab.co.il [141118 01:15]:
Add support for more SBC-T3x single board computers features:
* CM-T3x CoM and SB-T35 baseboard EEPROMs
* TV out
* Touchscreen
* CM-T3x30 audio
* CM-T3x30 keypad
Applying
Add support for more SBC-T3x single board computers features:
* CM-T3x CoM and SB-T35 baseboard EEPROMs
* TV out
* Touchscreen
* CM-T3x30 audio
* CM-T3x30 keypad
Dmitry Lifshitz (9):
ARM: dts: cm-t3x: cleanup comments indentation
ARM: dts: cm-t3x: add ADS7846 touchscreen support
ARM:
* Felipe Balbi ba...@ti.com [140915 14:16]:
Hi Tony,
Here are the remaining INTC patches rebased on your omap-for-v3.18/intc-v2
branch.
Based on our IRC chat, I kept irq-omap-intc.h header, but included it
on common.h instead of modifying every board-file.
Great thanks. We can deal with
Hi Tony,
Here are the remaining INTC patches rebased on your omap-for-v3.18/intc-v2
branch.
Based on our IRC chat, I kept irq-omap-intc.h header, but included it
on common.h instead of modifying every board-file.
cheers
Felipe Balbi (9):
irqchip: add irq-omap-intc.h header
arm: omap: irq:
These patches add labels in the initializations of structure fields (c99
initializers). The complete semantic patch thta makes this change is shown
below. This rule ignores cases where the initialization is just 0 or NULL,
where some of the fields already use labels, and where there are nested
On Sat, Aug 23, 2014 at 01:20:22PM +0200, Julia Lawall wrote:
These patches add labels in the initializations of structure fields (c99
initializers). The complete semantic patch thta makes this change is shown
below. This rule ignores cases where the initialization is just 0 or NULL,
where
Hello Jyri,
On 06 Aug 04:47 PM, Jyri Sarha wrote:
The code has a functional dependency to:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg108199.html
Without the above patch the audio card does not probe.
The code has been rebased on top of Linux 3.16 merged with
The code has a functional dependency to:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg108199.html
Without the above patch the audio card does not probe.
The code has been rebased on top of Linux 3.16 merged with
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
Hi Tony, Paul,
This patch series adds the minimal mailbox DT nodes for the SoCs that are
currently missing them (OMAP4, AM335x, DRA7). It also limits the legacy
mailbox platform device creation only for non-DT boot, and cleans up the
legacy hwmod addresses and attributes used for creating the
Hi Tony, Paul,
This patch series adds the minimal mailbox DT nodes for the SoCs that are
currently missing them (OMAP4, AM335x, DRA7). It also limits the legacy
mailbox platform device creation only for non-DT boot, and cleans up the
legacy hwmod addresses and attributes used for creating the
On 06/24/2014 08:00 PM, Suman Anna wrote:
Hi Tony, Paul,
Please ignore this, resent the same message and the series with the
proper subject.
regards
Suman
This patch series adds the minimal mailbox DT nodes for the SoCs that are
currently missing them (OMAP4, AM335x, DRA7). It also limits
Hi Mark/Lee Jones,
On Wednesday 28 May 2014 03:50 PM, Keerthy wrote:
The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- GPADC.
- Over Temperature warning and Shut down.
This patch
Hi Mark/Lee Jones,
On Wednesday 28 May 2014 03:50 PM, Keerthy wrote:
The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- GPADC.
- Over Temperature warning and Shut down.
On Fri, Jun 06, 2014 at 04:29:03PM +0530, Keerthy wrote:
A gentle ping on this rework.
Please don't send contentless pings.
signature.asc
Description: Digital signature
The tilcdc driver could be compiled as a module, but was severely broken
and could not be used as such. This patchset attempts to fix the issues
preventing a proper load/unload of the module.
Issues included dangling sysfs nodes, dangling devices, memory leaks and
a double kfree.
It now seems to
The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- GPADC.
- Over Temperature warning and Shut down.
This patch series adds support for TPS65917 mfd device. At this time only
the
Here are some minor cleanups for dmtimer code in preparation for moving it out
to drivers.
There is OMAP1 specific dmtimer code earlier, that are handled in mach-omap1
directly now. Other than this, few functions and code has been refactored to
reduce redundancy and some minor cleanups.
OMAP1
Andreas Fenkart (3):
mmc: omap_hsmmc: Enable SDIO interrupt
mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on
AM335x
mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux
Balaji T K (6):
mmc: omap_hsmmc: use devm_clk_get
mmc: omap_hsmmc: use devm_request_irq
Hi Rob,
On Sunday 09 March 2014 01:23 AM, Rob Herring wrote:
On Fri, Mar 7, 2014 at 6:16 AM, Sricharan R r.sricha...@ti.com wrote:
In some SoCs the dma request lines from the peripherals are
routed to the dma-controller through a crossbar. With this the
dma controller's available request
On Fri, Mar 7, 2014 at 6:16 AM, Sricharan R r.sricha...@ti.com wrote:
In some SoCs the dma request lines from the peripherals are
routed to the dma-controller through a crossbar. With this the
dma controller's available request lines are shared between the
peripherals.
This adds support to
In some SoCs the dma request lines from the peripherals are
routed to the dma-controller through a crossbar. With this the
dma controller's available request lines are shared between the
peripherals.
This adds support to register the crossbar router associated with
a dma-channel and let the
* Mugunthan V N mugunthan...@ti.com [140303 06:53]:
Benoit/Tony
Here I am send all the pending dt patches that can go into 3.15 merge window,
all the patches were already posted to mailing list and has beed reviewed.
I have rebased the patches on top of
On Thursday 06 March 2014 01:20 AM, Tony Lindgren wrote:
* Mugunthan V N mugunthan...@ti.com [140303 06:53]:
Benoit/Tony
Here I am send all the pending dt patches that can go into 3.15 merge window,
all the patches were already posted to mailing list and has beed reviewed.
I have rebased
Benoit/Tony
Here I am send all the pending dt patches that can go into 3.15 merge window,
all the patches were already posted to mailing list and has beed reviewed.
I have rebased the patches on top of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
omap-for-v3.15/dt
and
Benoit/Tony
Here I am send all the pending patches that can go into 3.15 merge window,
all the patches were already posted to mailing list and has beed reviewed.
Here I am rebasing the patches on top of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
omap-for-v3.15/dt
and
* Peter Ujfalusi peter.ujfal...@ti.com [140124 00:21]:
Hi Benoit,
OMAP: Put the audio nodes to disabled styate by default and board dts files
should
enable the nodes which is used on the board.
am335x: correct the audio mclk clock. This patch has been marked to go to 3.13
stable
This pathes fix some wrong property issues and add some new devices to
devicetree. This was tested on linux-next (next-20140124).
Marek Belisko (6):
ARM: dts: omap3-gta04: Fix mmc1 properties.
ARM: dts: omap3-gta04: Add basic sound support.
ARM: dts: omap3-gta04: Add twl4030 charger.
ARM:
Hi Benoit,
OMAP: Put the audio nodes to disabled styate by default and board dts files
should
enable the nodes which is used on the board.
am335x: correct the audio mclk clock. This patch has been marked to go to 3.13
stable as well.
Regards,
Peter
---
Peter Ujfalusi (9):
ARM: DTS:
Hi Joel,
On 26/09/2013 00:01, Joel Fernandes wrote:
Following series is a collection of dts patches for the below features:
crypto:
aes, sha on am335x
aes, des on am437x
aes, des on omap4
display:
beaglebone black HDMI
am335x-evm panel
Series is based on Benoit Cousson's
Following series is a collection of dts patches for the below features:
crypto:
aes, sha on am335x
aes, des on am437x
aes, des on omap4
display:
beaglebone black HDMI
am335x-evm panel
Series is based on Benoit Cousson's for_3.13/dts branch (commit sha 45646cd)
Available at:
Hi,
Modelling the RESET line as a regulator supply wasn't a good idea
as it abuses the regulator framework and makes adaptation
code/data more complex.
Instead, manage the RESET gpio line directly in the driver.
This also makes us easy to migrate to a dedicated GPIO RESET controller
whenever it
Hi Nishanth,
On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote:
Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board 750-2628-XXX platform.
Unfortunately, the
On 07/29/2013 04:57 AM, Keerthy wrote:
Hi Nishanth,
On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote:
Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board
The following series adds support to EDMA driver to enable DMA of
scatter-gather lists of arbitrary length, but still make use of only
a certain MAX number of slots at a time for a given channel. Thus
free-ing up the rest of the slots to other slaves/channels. With this
there is no need for slave
Hi Nishanth,
On 29/07/2013 15:17, Nishanth Menon wrote:
On 07/29/2013 04:57 AM, Keerthy wrote:
Hi Nishanth,
On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote:
Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5
On 07/29/2013 08:39 AM, Benoit Cousson wrote:
Hi Nishanth,
On 29/07/2013 15:17, Nishanth Menon wrote:
On 07/29/2013 04:57 AM, Keerthy wrote:
Hi Nishanth,
On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote:
Due to wrong older revision of documentation used as reference, we
seem to have
On 07/29/2013 09:19 AM, Benoit Cousson wrote:
2013/7/29 Nishanth Menon n...@ti.com mailto:n...@ti.com
Well you're lucky I'm now in an area with Wifi and 3G access... last
week it whould have been impossible to receive it :-)
hehe :)
All the fixes are sharing more than 50% of the changelog
Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board 750-2628-XXX platform.
Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
supply hardware blocks
On 03/14/2013 10:45 AM, Florian Vaussard wrote:
Hi Benoit,
On 03/14/2013 03:57 PM, Benoit Cousson wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent
Hi Javier,
On 03/14/2013 05:02 PM, Javier Martinez Canillas wrote:
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson b-cous...@ti.com wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
Vaussard [1] and OMAP5 DT
This is the result of my my build tests on 3.9-rc1, mostly bugs
that I had not caught before the merge window, or where the fix
for some reason has not yet made it in.
I hope the subsystem maintainers can take care of applying these,
for the arch/arm/mach-* patches I can either apply them
This series tries to clean-up the some of the areas like OMAP4 static
deps, FIQ usage in OMAP code, SMP code. The patches are self explanatory
and quite independent but since I had them mantained in a branch, am
sending them together not to loose track of them.
They have been tested on OMAP4 and
V == Bedia, Vaibhav vaibhav.be...@ti.com writes:
Hi,
Vaibhav Bedia (9):
ARM: OMAP2+: AM33XX: CM: Get rid of unncessary header inclusions
ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod
ARM: OMAP2+: AM33XX:
Hi Peter,
On Mon, Jan 21, 2013 at 14:33:20, Peter Korsgaard wrote:
V == Bedia, Vaibhav vaibhav.be...@ti.com writes:
Hi,
Vaibhav Bedia (9):
ARM: OMAP2+: AM33XX: CM: Get rid of unncessary header inclusions
ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
ARM:
Hi Paul, Benoit,
On Fri, Jan 18, 2013 at 12:49:20, Bedia, Vaibhav wrote:
Hi,
The following patches were earlier posted as part the AM33XX
suspend-resume support series [1]. Based on the suggestion
from Santosh Shilimkar santosh.shilim...@ti.com i have split
out the changes which update the
Hi,
The following patches were earlier posted as part the AM33XX
suspend-resume support series [1]. Based on the suggestion
from Santosh Shilimkar santosh.shilim...@ti.com i have split
out the changes which update the various data files related
to AM33XX support.
These patches apply on top of
On Fri, Dec 21, 2012 at 10:04:00AM -0700, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
[This supersedes the omap-sham driver patches sent in the
crypto: omap-sham updates series sent a few weeks ago.]
This patch series does several things to the omap-sham crypto
driver
Hi Omar,
On Fri, Dec 21, 2012 at 9:33 PM, Omar Ramirez Luna
omar.rami...@copitl.com wrote:
Yes, I made the changes, for tidspbridge and remoteproc, I will submit
both for review, based on this series.
Great, thanks.
Please note that when we do eventually merge this, we need your
updates to be
On 12/21/2012 08:31 AM, Ohad Ben-Cohen wrote:
On Thu, Dec 20, 2012 at 9:19 PM, Olof Johanssono...@lixom.net wrote:
While we can make the branch stable, would it make sense to make
remoteproc for omap depend on !multiplatform during the transition, to
reduce dependencies a little? Either way
From: Mark A. Greer mgr...@animalcreek.com
[This supersedes the omap-sham driver patches sent in the
crypto: omap-sham updates series sent a few weeks ago.]
This patch series does several things to the omap-sham crypto
driver including:
- converting to use pm_runtime
- adding suspend/resume
Hi Loic/Ohad,
On Fri, Dec 21, 2012 at 2:52 AM, Loic PALLARDY loic.palla...@st.com wrote:
On 12/21/2012 08:31 AM, Ohad Ben-Cohen wrote:
On Thu, Dec 20, 2012 at 9:19 PM, Olof Johanssono...@lixom.net wrote:
While we can make the branch stable, would it make sense to make
remoteproc for omap
On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
loic.pallardy-...@stericsson.com wrote:
OMAP and ST-Ericsson platforms are both using mailbox to communicate
with some coprocessors.
Based on OMAP existing mailbox framework, this series proposes a
generic framework, living under drivers/mailbox.
* Linus Walleij linus.wall...@linaro.org [121220 10:19]:
On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
loic.pallardy-...@stericsson.com wrote:
OMAP and ST-Ericsson platforms are both using mailbox to communicate
with some coprocessors.
Based on OMAP existing mailbox framework, this
On Thu, Dec 20, 2012 at 10:28 AM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [121220 10:19]:
On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
loic.pallardy-...@stericsson.com wrote:
OMAP and ST-Ericsson platforms are both using mailbox to communicate
with
* Olof Johansson o...@lixom.net [121220 11:22]:
On Thu, Dec 20, 2012 at 10:28 AM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [121220 10:19]:
On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
loic.pallardy-...@stericsson.com wrote:
OMAP and ST-Ericsson
On Thu, Dec 20, 2012 at 9:19 PM, Olof Johansson o...@lixom.net wrote:
While we can make the branch stable, would it make sense to make
remoteproc for omap depend on !multiplatform during the transition, to
reduce dependencies a little? Either way works, but it'd be nice to
keep them
OMAP and ST-Ericsson platforms are both using mailbox to communicate
with some coprocessors.
Based on OMAP existing mailbox framework, this series proposes a
generic framework, living under drivers/mailbox.
This series:
- moves omap-mailbox framework to a newly drivers/mailbox folder
(part of
This series resolves a few minor issues for EMIF driver.
Tested all the patches on OMAP4-sdp, OMAP5-sevm.
Patch : memory: emif: setup LP settings on freq update
is tested on a local tree, since freq update cannot be
tested on mainline.
Ambresh K (1):
memory: emif: use default custom config
Sorry to Spam you in-box.
Please discard this message...
Thanks
Lokesh
On Monday 10 December 2012 12:38 PM, a...@dbdp33.itg.ti.com wrote:
From: Lokesh Vutla lokeshvu...@ti.com
This series resolves a few minor issues for EMIF driver.
Tested all the patches on OMAP4-sdp, OMAP5-sevm.
Patch :
On 2012-10-22 08:48, Archit Taneja wrote:
On Wednesday 17 October 2012 04:50 PM, Tomi Valkeinen wrote:
Hi,
This series contains minor cleanups and fixes for omapdss.
This series looks fine to me. I have a related cleanup patch which you
may consider adding to the series.
Thanks,
Archit
On Wednesday 17 October 2012 04:50 PM, Tomi Valkeinen wrote:
Hi,
This series contains minor cleanups and fixes for omapdss.
This series looks fine to me. I have a related cleanup patch which you
may consider adding to the series.
Thanks,
Archit
From: Archit Taneja arc...@ti.com
Date: Thu,
Hi,
This series contains minor cleanups and fixes for omapdss.
Tomi
Tomi Valkeinen (9):
OMAPDSS: DSI: fix dsi_get_dsidev_from_id()
OMAPDSS: fix registering the vsync isr in apply
OMAPDSS: DISPC: constify function parameters
OMAPDSS: combine LCD related config into one func
OMAPDSS:
On 10/06/2012 02:03 AM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [121004 04:57]:
Hello,
u-boot recently stopped configuring 'non essential' pin mux. This change
leaves
the audio essential pins in non configured state which prevents the use of
audio.
The following
* Peter Ujfalusi peter.ujfal...@ti.com [121004 04:57]:
Hello,
u-boot recently stopped configuring 'non essential' pin mux. This change
leaves
the audio essential pins in non configured state which prevents the use of
audio.
The following series makes sure that the needed pins are
Hello,
u-boot recently stopped configuring 'non essential' pin mux. This change leaves
the audio essential pins in non configured state which prevents the use of
audio.
The following series makes sure that the needed pins are configured correctly by
the kernel on OMAP4 and OMAP5.
Tony: can this
Hi,
This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI
and DSI.
Tomi
Archit Taneja (1):
OMAPDSS: Add basic omap5 features to dss and dispc
Tomi Valkeinen (8):
OMAPDSS: DSI: improve DSI clock calcs for DISPC
OMAPDSS: move dss feats to the end of dss.c
On Monday 24 September 2012 07:28 PM, Tomi Valkeinen wrote:
Hi,
This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI
and DSI.
Looks good to me.
Archit
Tomi
Archit Taneja (1):
OMAPDSS: Add basic omap5 features to dss and dispc
Tomi Valkeinen (8):
* Rob Herring robherri...@gmail.com [120830 22:59]:
On 08/30/2012 07:52 PM, Tony Lindgren wrote:
Hi all,
Here's the first set of omap header clean-up patches needed for single
zImage support. This series is based v3.6-rc3 and the following patches
to avoid merge conflicts with the
* Igor Grinberg grinb...@compulab.co.il [120828 16:19]:
This patch series cleans up the plat/board.h and related files.
Great, thanks for doing this! Nice that we can finally remove
all of that. I've also tested that 770 boots after this, so
looks like we've already fixed up whatever it was
Hi all,
Here's the first set of omap header clean-up patches needed for single
zImage support. This series is based v3.6-rc3 and the following patches
to avoid merge conflicts with the includes:
- Arnd's patch ARM: omap: move platform_data definitions
- Igor's series ARM: OMAP: cleanup
On 08/30/2012 07:52 PM, Tony Lindgren wrote:
Hi all,
Here's the first set of omap header clean-up patches needed for single
zImage support. This series is based v3.6-rc3 and the following patches
to avoid merge conflicts with the includes:
- Arnd's patch ARM: omap: move platform_data
This patch series cleans up the plat/board.h and related files.
Remove confusingly empty struct omap_board_config_kernel structures
and unused omap_get_nr_config() macro along with
unused omap_get_var_config() function.
Those apparently were never used in upstream kernels.
Move OMAP3EVM revision
Hi,
This series provides new interface for GPMC peripherals that use
helper functions for initialization and configures omap3evm
beagleboard GPMC in Kernel. Existing interface would continue to
serve its purpose as before.
New interface for smsc911x has been provided the runtime timing
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform data. The goal of
Hi Tony, Paul,
On 05/17/2012 11:48 AM, Paul Walmsley wrote:
On Thu, 17 May 2012, Jon Hunter wrote:
Yes that's right. What is your preference here, the options are ...
1. Move the clkt_clksel.c file to arch/arm/plat-omap and change the
omap2_xxx API names to omap_xxx.
2. Add the functions
On 5/16/2012 3:34 PM, Jon Hunter wrote:
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up
Hi Paul,
On 05/16/2012 06:30 PM, Paul Walmsley wrote:
Hello Jon,
On Wed, 16 May 2012, Jon Hunter wrote:
I have been looking into this and in order to get rid for the above
function pointer we would need to move at a minimum the following
functions from omap-mach2/clkt_clksel.c into the
Hi Tarun,
On 05/17/2012 12:07 AM, DebBarma, Tarun Kanti wrote:
On Thu, May 17, 2012 at 1:44 AM, Jon Hunter jon-hun...@ti.com wrote:
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to
On Thu, 17 May 2012, Jon Hunter wrote:
Yes that's right. What is your preference here, the options are ...
1. Move the clkt_clksel.c file to arch/arm/plat-omap and change the
omap2_xxx API names to omap_xxx.
2. Add the functions in clkt_clksel.c to arch/arm/plat-omap/clock.c and
get rid of
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform data. The goal of
+ Tarun for any comments
On Wednesday 16 May 2012 05:05 AM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
was first necessary to clean-up the timer platform data. The goal of
Hello Jon,
On Wed, 16 May 2012, Jon Hunter wrote:
I have been looking into this and in order to get rid for the above
function pointer we would need to move at a minimum the following
functions from omap-mach2/clkt_clksel.c into the platform code.
By platform code, do you mean
On Thu, May 17, 2012 at 1:44 AM, Jon Hunter jon-hun...@ti.com wrote:
Hi Benoit,
On 05/16/2012 04:28 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found
that it
From: Jon Hunter jon-hun...@ti.com
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int
* Tony Lindgren t...@atomide.com [120329 10:31]:
Mathieu,
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:16]:
From: Arnd Bergmann a...@arndb.de
The following is a set of patches that have been sent
out during the 3.1 cycle that were not acked or merged.
1 - 100 of 214 matches
Mail list logo
