Re: [spi-devel-general] [PATCH 1/3] [SPI] [OMAP] Add OMAP spi100k driver

On Mon, Dec 7, 2009 at 1:48 PM, Cory Maccarrone darkstar6...@gmail.com wrote: This change adds the OMAP SPI 100k driver created by Fabrice Crohas fcro...@gmail.com.  This SPI bus is found on OMAP7xx-series smartphones, and for many, the touchscreen is attached to this bus. The lion's share

Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers

On 9 September 2011 05:29, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Jassi's suggestion was that we should have some magic to automatically generate defaults for the relevant device registrations to sidestep these issues. Perhaps there is some misunderstanding no witchcraft is

Re: [PATCH] DMAEngine: Define generic transfer request api

that I am not sure of. Of course, neither can this api help transfers that don't lend to DMA by nature, i.e, scattered tiny read/writes with no periodic pattern. Signed-off-by: Jassi Brar jaswinder.si...@linaro.org anyway, this API needs a real user to prove why it needs to exist. prima2

Re: [PATCH] DMAEngine: Define generic transfer request api

On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote: if test pass, to the patch, and even for the moment, to the API's idea Acked-by: Barry Song baohua.s...@csr.com one issue i noticed is with a device_prep_dma_genxfer, i don't need device_prep_slave_sg any more, Yeah, the

Re: [PATCH] DMAEngine: Define generic transfer request api

On 15 September 2011 12:01, Barry Song 21cn...@gmail.com wrote: 2011/9/13 Barry Song 21cn...@gmail.com: 2011/9/13 Jassi Brar jaswinder.si...@linaro.org: On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote: if test pass, to the patch, and even for the moment, to the API's idea Acked

[PATCH 1/2] OMAPDSS: HDMI: Rid hw_params of extra argument

Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- drivers/video/omap2/dss/hdmi.c | 13 ++--- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 3262f0f..d3eae98 100644 --- a/drivers/video/omap2/dss

[PATCH 2/2] OMAPDSS: HDMI: Indirect trigger to IP specific version

Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- drivers/video/omap2/dss/hdmi.c|6 ++ drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |2 +- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |2 +- 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/video

Re: 3.5-rc3: PM/DSS broken (was vdd_mpu_iva warnings)

On 3 July 2012 16:29, Archit Taneja a0393...@ti.com wrote: I was going through Tomi's queue for the 3.6 merge window: git://gitorious.org/linux-omap-dss2/linux.git master There is a commit called: 2b8501d777346ce1d4fe99167e9b3c0e42aae7a8 OMAPDSS: Use PM notifiers for system suspend The

Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays

[CC'ing OMAPDSS matinainer] On 17 July 2012 19:31, Raphael Assenat r...@8d.com wrote: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays. Display panels are board specific and there is no limit to the number of panels that could be connected to omap dss. Does it make sense to

Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays

On 20 July 2012 13:41, Archit Taneja a0393...@ti.com wrote: On Tuesday 17 July 2012 09:57 PM, Jassi Brar wrote: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays. Display panels are board specific and there is no limit to the number of panels that could be connected to omap

[PATCH] OMAPDSS: DPI: Get panel configuration from platform data

Instead of harcoding in the driver some of potentially countless sets of parameters that could define a panel, have the board provide the parameters to the panel driver. Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- arch/arm/mach-omap2/board-2430sdp.c |4 +- arch/arm

Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays

On 20 July 2012 18:14, Archit Taneja a0393...@ti.com wrote: On Friday 20 July 2012 05:43 PM, Jassi Brar wrote: It's true that currently omap platforms don't share the same panels, but there is no stopping us to do that. We could remove the default panel and attach a new one, even though we

[PATCH] OMAPDSS: DISPC: Use msleep instead of blocking mdelay

We have no reason to block in the error handler workqueue, so use msleep. Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- drivers/video/omap2/dss/dispc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss

Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays

On 31 July 2012 13:21, Tomi Valkeinen tomi.valkei...@ti.com wrote: 2) Have the configuration for countless panels specified in the DT data Why should a DT blob for a board contain more than 1 panel configuration? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body

Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays

On 31 July 2012 13:44, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote: On 31 July 2012 13:21, Tomi Valkeinen tomi.valkei...@ti.com wrote: 2) Have the configuration for countless panels specified in the DT data Why should a DT blob

Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays

On 31 July 2012 14:12, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote: On 31 July 2012 13:44, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote: On 31 July 2012 13:21, Tomi Valkeinen tomi.valkei

Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays

On 31 July 2012 15:27, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-07-31 at 14:27 +0530, Jassi Brar wrote: On 31 July 2012 14:12, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote: On 31 July 2012 13:44, Tomi Valkeinen tomi.valkei

[PATCHv2] OMAP4: PANDA, SDP: Fix EHCI regulator supply

the default 'dummy' regulator to the ehci-omap device. Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- arch/arm/mach-omap2/board-4430sdp.c|7 ++- arch/arm/mach-omap2/board-omap4panda.c |7 ++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

On Sun, Jul 10, 2011 at 8:33 PM, Sundaram Raju sunda...@ti.com wrote: Added new dma_ctrl_cmd TI_DMA_STRIDE_CONFIG to pass the TI DMA controller specific configurations on how a buffer must be walked through and how data is picked for transfer based on a specified pattern over the channel.

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

On Tue, Jul 12, 2011 at 3:33 PM, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar jassisinghb...@gmail.com wrote: 1) Striding, in one form or other, is supported by other DMACs as well.   The number will only increase in future.   Are we to add

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

On Tue, Jul 12, 2011 at 5:01 PM, Raju, Sundaram sunda...@ti.com wrote: -Original Message- From: Jassi Brar [mailto:jassisinghb...@gmail.com] Sent: Tuesday, July 12, 2011 4:51 PM To: Linus Walleij Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org

Re: [PATCH v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage

On Wed, Jul 20, 2011 at 10:41 AM, Vikram Pandita vikram.pand...@ti.com wrote: From: Anand Gadiyar gadi...@ti.com This patch enables the DMA mode1 RX support. This feature is enabled based on the short_not_ok flag passed from gadget drivers. This will result in a thruput performance gain of

Re: [PATCH v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage

On Wed, Jul 20, 2011 at 11:15 AM, Pandita, Vikram vikram.pand...@ti.com wrote: On Tue, Jul 19, 2011 at 10:34 PM, Jassi Brar jassisinghb...@gmail.com wrote: On Wed, Jul 20, 2011 at 10:41 AM, Vikram Pandita vikram.pand...@ti.com wrote: From: Anand Gadiyar gadi...@ti.com This patch enables

Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration

On Mon, Jul 18, 2011 at 1:21 PM, Raju, Sundaram sunda...@ti.com wrote: Maybe a new api to pass fixed-format variable-length encoded message to the DMAC drivers? Which could be interpreted by DMAC drivers to extract all the needed xfer parameters from the 'header' section and instructions to

Re: [PATCH v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage

On Tue, Jul 26, 2011 at 8:36 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Jul 20, 2011 at 09:48:53AM -0700, Pandita, Vikram wrote: This *today happens to be only UMS* is my exact point here. Can you guarantee no other function driver will ever expect only full packet xfers and treat

[PATCH] DMAEngine: Define generic transfer request api

that don't lend to DMA by nature, i.e, scattered tiny read/writes with no periodic pattern. Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- include/linux/dmaengine.h | 73 + 1 files changed, 73 insertions(+), 0 deletions(-) diff --git

Re: [PATCH] DMAEngine: Define generic transfer request api

On 19 August 2011 22:58, Koul, Vinod vinod.k...@intel.com wrote: On Fri, 2011-08-19 at 21:16 +0530, Jassi Brar wrote: On 19 August 2011 19:49, Linus Walleij linus.ml.wall...@gmail.com wrote: 2011/8/19 Koul, Vinod vinod.k...@intel.com: On Tue, 2011-08-16 at 15:06 +0200, Linus Walleij wrote

Re: How to disable message Uncompressing linux... on kernel start?

On 18 September 2012 12:09, Maximilian Schwerin maximilian.schwe...@tigris.de wrote: Hi all, I have been convinced that my patch for disabling the message Uncompressing linux... on kernel start was not all that good an idea. As the problem still remains an issue for me and I'd like to find a

Re: How to disable message Uncompressing linux... on kernel start?

On 18 September 2012 15:37, Jassi Brar jaswinder.si...@linaro.org wrote: On 18 September 2012 12:09, Maximilian Schwerin maximilian.schwe...@tigris.de wrote: Hi all, I have been convinced that my patch for disabling the message Uncompressing linux... on kernel start was not all that good

Re: How to disable message Uncompressing linux... on kernel start?

On 18 September 2012 12:09, Maximilian Schwerin maximilian.schwe...@tigris.de wrote: Hi all, I have been convinced that my patch for disabling the message Uncompressing linux... on kernel start was not all that good an idea. As the problem still remains an issue for me and I'd like

Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On 19 September 2012 17:29, Felipe Balbi ba...@ti.com wrote: this is what I mean, actually. If we remove pm_runtime_get_sync() in exchange for pm_runtime_set_active() before pm_runtime_enable(), it works on PandaBoard, but breaks BeagleBoard. Perhaps it suggests that OMAP4 (PandaBoard) serial

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 1 May 2012 02:47, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.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

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 4 May 2012 20:47, Jon Hunter jon-hun...@ti.com wrote: Hi Jassi, On 05/04/2012 01:56 AM, Jassi Brar wrote: On 1 May 2012 02:47, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 5 May 2012 00:53, Arnd Bergmann a...@arndb.de wrote: On Friday 04 May 2012, Jassi Brar wrote: I see this requires a client driver to specify a particular req_line on a particular dma controller. I am not sure if this is most optimal. I think such client-req_line map should be provided

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 7 May 2012 21:23, Stephen Warren swar...@wwwdotorg.org wrote: On 05/05/2012 11:10 AM, Jassi Brar wrote: Hmm... there ought to be a way by which a client is handed a random 'token' via its dt node and similarly the dmac informed which channel (and with what capabilities) to allocate should

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 8 May 2012 22:05, Stephen Warren swar...@wwwdotorg.org wrote: The data doesn't need to be part of the DMA controller node in order for the DMA controller driver to be the entity interpreting it. I rather say, if the dma controller driver is the entity going to interpret the data, why not

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 10 May 2012 00:40, Stephen Warren swar...@wwwdotorg.org wrote: On 05/08/2012 01:09 PM, Jassi Brar wrote: There is important difference between providing data via clients during runtime vs providing info about every client to the dmac driver at one go during its probe. I certainly see

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 10 May 2012 22:30, Stephen Warren swar...@wwwdotorg.org wrote: On 05/09/2012 03:38 PM, Jassi Brar wrote: One point is about 'qos' here something like bandwidth allocation. If the dmac driver knew up-front the max possible clients that could be active simultaneously, it could divide

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote: On 05/10/2012 01:59 PM, Jassi Brar wrote: I think arbitrary numerical tokens are a reasonable price to pay for the robustness and simplicity they bring. I have to disagree here. Using phandle+ID is almost as simple, and much

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 12 May 2012 05:21, Stephen Warren swar...@wwwdotorg.org wrote: On 05/11/2012 03:06 PM, Jassi Brar wrote: On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote: On 05/10/2012 01:59 PM, Jassi Brar wrote: ... client0: i2s {   /* has 2 DMA request output signals: 0, 1

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

Hi Jon, On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote: On 05/04/2012 02:01 PM, Jassi Brar wrote: +       i2c1: i2c@1 { +               ... +               dma = sdma 2 1 sdma 3 2; +               ... +       }; I see this requires a client driver to specify a particular

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 16 May 2012 21:31, Jon Hunter jon-hun...@ti.com wrote: On 05/16/2012 08:15 AM, Jon Hunter wrote: Hi Jassi, On 05/16/2012 07:37 AM, Jassi Brar wrote: Hi Jon, On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote: On 05/04/2012 02:01 PM, Jassi Brar wrote: +       i2c1: i2c@1

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 16 May 2012 21:45, Stephen Warren swar...@wwwdotorg.org wrote: On 05/16/2012 10:01 AM, Jon Hunter wrote: ... By the way, I do see your point. You wish to describe the all the mappings available to all dma controllers and then set a mapping in the device tree. Where as I am simply setting a

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 16 May 2012 22:42, Jon Hunter jon-hun...@ti.com wrote: What is still unclear to me, is if you use this token approach how readable is the device-tree? For example, if you have a client that can use one of two dmac and for each dmac the request/channel number is different, then by using a

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 17 May 2012 01:12, Arnd Bergmann a...@arndb.de wrote: Generic binding to provide a way to provide the client-channel map and other dmac specific parameters to the dma controller driver DMA Model:-   Only the most common characteristics of a dma setup are assumed in this binding. Client:

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 17 May 2012 05:29, Stephen Warren swar...@wwwdotorg.org wrote: Generic binding to provide a way to provide the client-channel map and other dmac specific parameters to the dma controller driver DMA Model:-   Only the most common characteristics of a dma setup are assumed in this binding.

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 18 May 2012 01:02, Stephen Warren swar...@wwwdotorg.org wrote: Now, the DMA node for an on-SoC DMAC would be in soc.dtsi. Typically, the DMAC is connected to many on-SoC devices, and hence soc.dtsi would need to specify the routing information for all those devices to avoid duplicating it

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

On 14 June 2012 04:02, Jon Hunter jon-hun...@ti.com wrote: On 06/08/2012 07:04 PM, Arnd Bergmann wrote: As I said previously, I think just encoding the direction but not the client specific ID (meaning we would have to disambiguate the more complex cases that Stephen mentioned using a

Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member

On 18 June 2012 13:41, Tomi Valkeinen tomi.valkei...@ti.com wrote: Explicitly maintaining HDMI phy power state using a flag is prone to race and un-necessary when we have a zero-cost alternative of checking the state before trying to set it. Why would reading the value from the register be

Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member

On 18 June 2012 16:24, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote: BTW, coming to think about it, I am not sure what we need the spin_lock_irqsave() protection for in hdmi_check_hpd_state() ?  It can't control HPD gpio state change

Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member

On 18 June 2012 17:54, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote: So preferably I would move request_threaded_irq() to after hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable()  and convert the No, you can't move the check. If you move

Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member

On 18 June 2012 18:41, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote: On 18 June 2012 17:54, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote: So preferably I would move request_threaded_irq

Re: [PATCH] OMAPDSS: HDMI: Cache EDID

On 25 June 2012 12:05, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote: From: Jassi Brar jaswinder.si...@linaro.org We can easily keep track of latest EDID from the display and hence avoid expensive EDID re-reads over I2C

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 25 June 2012 11:50, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:  Currenlty HDMI fails to come up in the suspend-resume path. This patch helps that real-world scenario. What is the problem there? It'd be good to

Re: [PATCH] OMAPDSS: HDMI: Cache EDID

On 25 June 2012 13:41, Tomi Valkeinen tomi.valkei...@ti.com wrote: I am perfectly OK to resend as a patch series, if you want. Yes please. OK, will do.  bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)  { -     return gpio_get_value(ip_data-hpd_gpio); +     if

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 25 June 2012 15:00, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-25 at 14:19 +0530, Jassi Brar wrote: On 25 June 2012 11:50, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:  Currenlty HDMI fails to come

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 25 June 2012 17:35, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:  Currenlty HDMI fails to come up in the suspend-resume path. This patch helps

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 25 June 2012 18:11, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-25 at 17:57 +0530, Jassi Brar wrote: On 25 June 2012 15:00, Tomi Valkeinen tomi.valkei...@ti.com wrote: The driver needs to enable the HW and the call to pm_runtime_get() is skipped. Won't this lead to crash

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 25 June 2012 19:19, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote: /* this accesses a register, but the HW is disabled? */ dispc_read_reg(FOO); the H/W is already always enabled if CONFIG_PM_RUNTIME is not defined

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 26 June 2012 12:49, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote: Normally if the driver does dispc_runtime_get() and dispc_read_reg(), the first call will enable the HW so the reg read works. But if the pm_runtime is disabled, say

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 26 June 2012 14:37, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-06-26 at 14:02 +0530, Jassi Brar wrote: Something non-omapdss in vanilla breaks suspend/resume. I was able to reproduce (probably) the same issue with omap3 overo. Does this looks familiar: [ 2267.140197

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 26 June 2012 17:33, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote: Seems similar, but I only tested OMAP4 HDMI. Would something like this one below work for you? It fixes the issues on my overo board. I think this should work too (I

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 26 June 2012 20:38, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote: On 26 June 2012 17:33, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote: Seems similar, but I only tested OMAP4 HDMI

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 26 June 2012 20:41, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote: On 26 June 2012 20:38, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote: On 26 June 2012 17:33, Tomi Valkeinen tomi.valkei

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 27 June 2012 00:14, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Tue, 2012-06-26 at 22:31 +0530, Jassi Brar wrote: But if pm_runtime_get_sync() returns an error, it means the HW has not been resumed successfully, and is not operational, Not always. The HW could be in RPM_ACTIVE state

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 27 June 2012 11:28, Tomi Valkeinen tomi.valkei...@ti.com wrote: It doesn't matter how omapdss is organized, -EACCES _is_ an error. It tells us that something unexpected happened, and we should react to it somehow. $ git show 5025ce070 Exactly how omapdss is organised is the reason -EBUSY

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 27 June 2012 13:43, Tomi Valkeinen tomi.valkei...@ti.com wrote: I don't like it at all that omapdss disables and enables the panels in omapdss's suspend/resume hooks. But I'm not sure how this should work... Should panel drivers each have their own suspend/resume hooks, and handle it

Re: [PATCH 1/2] OMAPDSS: Use PM notifiers for system suspend

version. But as I said, this patch may be temporary, so let's leave the sync version still in place. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reported-by: Jassi Brar jaswinder.si...@linaro.org Please feel free to add Tested-by: Jassi Brar jaswinder.si...@linaro.org -- To unsubscribe

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

On 28 June 2012 12:11, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote: On 27 June 2012 13:43, Tomi Valkeinen tomi.valkei...@ti.com wrote: I don't like it at all that omapdss disables and enables the panels in omapdss's suspend/resume hooks

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 13:18, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-06-27 at 19:35 +0530, jaswinder.si...@linaro.org wrote: From: Jassi Brar jaswinder.si...@linaro.org We can easily keep track of latest EDID from the display and hence avoid expensive EDID re-reads over I2C

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 15:44, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote: --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c @@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 16:17, Jassi Brar jaswinder.si...@linaro.org wrote: On 28 June 2012 15:44, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote: --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 16:40, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote: Sorry a correction. Reading detect() won't work. I suggest we keep HPD IRQ enabled for the lifetime of the driver. Ok, I see. But that's not acceptable. It would require

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 17:33, Andy Green andy.gr...@linaro.org wrote: On 06/28/12 19:10, the mail apparently from Tomi Valkeinen included: On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote: On 28 June 2012 16:17, Jassi Brar jaswinder.si...@linaro.org wrote: On 28 June 2012 15:44, Tomi Valkeinen

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 19:01, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote: On 28 June 2012 17:33, Andy Green andy.gr...@linaro.org wrote: If Jassi's alright with it we might have a go at implementing this, but can you define a bit more about how

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 20:44, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote: A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during probe and disable during remove. HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 20:57, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-06-28 at 20:44 +0530, Jassi Brar wrote: it has, some user action should enable it while 'making the device ready for new display'. IOW, how do you envision an OMAP4 based tablet with HDMI port react to display

Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On 28 June 2012 21:18, Jassi Brar jaswinder.si...@linaro.org wrote: On 28 June 2012 20:57, Tomi Valkeinen tomi.valkei...@ti.com wrote: By the way, when the device is in system suspend, we surely won't detect the HPD even if we kept the HPD always enabled. So there we'll miss the HPD

Re: [RFC] dmaengine: add new api for preparing simple slave transfer

On Thu, Jun 9, 2011 at 6:09 PM, Raju, Sundaram sunda...@ti.com wrote: Generic buffer description: A generic buffer can be split into number of frames which contain number of chunks inside them. The frames need not be contiguous, nor do the chunks inside a frame.        

[PATCH] regulator: twl: Add 'fixed' set_voltage callback

Define dummy set_voltage callback for fixed lines, without which voltage constraints fail to apply. Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- drivers/regulator/twl-regulator.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/regulator/twl

[PATCH] mfd: omap: Restore TLL initialization

The commit 7e6502d577106fb5b202bbaac64c5f1b065 'mfd: Add omap-usbhs runtime PM support' besides moving to RPM, removes necessary TLL initialization as well. Restore the TLL initialization, without which device detection fails. Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- drivers

[PATCH] OMAP4: PANDA, SDP: Fix EHCI regulator supply

the default 'dummy' regulator to the ehci-omap device. Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- arch/arm/mach-omap2/board-4430sdp.c|6 +- arch/arm/mach-omap2/board-omap4panda.c |6 +- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2

Re: [PATCH] of: Add generic device tree DMA helpers

On Mon, Mar 19, 2012 at 9:41 PM, Arnd Bergmann a...@arndb.de wrote: Secondly, there are platforms (Samsung) where peripherals are connected to more than one DMA controller, and either DMA controller can be used - I'm told by Jassi that there's reasons why you'd want to select one or other as

Re: [alsa-devel] [PATCH v4 - resend 00/13] OMAP4: ASoC: Support for PandaBoard family

On 24 January 2012 17:22, Peter Ujfalusi peter.ujfal...@ti.com wrote: Hello, the following series will add ASoC support for PandaBoards. PandaBoards have different audio routings compared to SDP4430/Blaze boards, but the differences not that big to justify a new ASoC machine driver. The

Re: [alsa-devel] [PATCH v4 - resend 00/13] OMAP4: ASoC: Support for PandaBoard family

Hi Sebastien, On 28 January 2012 04:21, Guiriec, Sebastien s-guir...@ti.com wrote: Hi Peter,     I tried the patchset on my 4430 Panda. Playback works ok, but not Capture. All is get is a hiss.    Is capture supposed to work ? If yes, any amixer settings that need to be done? Hi Jassi,

Re: [RFC PATCH 1/5] drivers : introduce device_path api

On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote: We should have a more generic solution in a more central location, like the device core. For example, each struct platform_device could have a list of

Re: [RFC PATCH 1/5] drivers : introduce device_path api

On Sat, Dec 1, 2012 at 2:07 PM, Andy Green andy.gr...@linaro.org wrote: On 12/01/2012 03:49 PM, the mail apparently from Jassi Brar included: On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote: We should

Re: [RFC PATCH 1/5] Device Power: introduce power controller

On 6 December 2012 06:57, Ming Lei tom.leim...@gmail.com wrote: On Thu, Dec 6, 2012 at 12:49 AM, Roger Quadros rog...@ti.com wrote: On 12/03/2012 05:00 AM, Ming Lei wrote: On Mon, Dec 3, 2012 at 12:02 AM, Andy Green andy.gr...@linaro.org wrote: On 02/12/12 23:01, the mail apparently from Ming

Re: [RFC PATCH 1/5] drivers : introduce device_path api

On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros rog...@ti.com wrote: Hi Jassi, On 12/01/2012 09:49 AM, Jassi Brar wrote: On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote: We should have a more generic

Re: [RFC PATCH 1/5] Device Power: introduce power controller

On 6 December 2012 18:48, Ming Lei tom.leim...@gmail.com wrote: On Thu, Dec 6, 2012 at 11:46 AM, Jassi Brar jaswinder.si...@linaro.org wrote: The patch can make usb port deal with the 'power controller' only, and make it avoid to deal with regulators/clocks/... directly. I am curious too

Re: [RFC PATCH 1/5] drivers : introduce device_path api

On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros rog...@ti.com wrote: On 12/06/2012 04:34 PM, Jassi Brar wrote: Yes, this is where we can think of a generic PHY driver to make sure thy PHY has necessary resources enabled. In the Panda case it would be the PHY clock and RESET gpio. I wonder

Re: [PATCH v3 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure

On 5 December 2012 19:43, Roger Quadros rog...@ti.com wrote: On 12/05/2012 03:42 PM, Sergei Shtylyov wrote: Hello. On 04-12-2012 18:31, Roger Quadros wrote: clk_set_parent is expected to fail on OMAP3 platforms. We don't consider that as fatal so don't spam console. Signed-off-by: Roger

Re: [GIT PULL] mailbox driver framework for v3.10 merge window

Hello Arnd, On 9 April 2013 16:25, Arnd Bergmann a...@arndb.de wrote: On Thursday 04 April 2013, Anna, Suman wrote: OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The

Re: [GIT PULL] mailbox driver framework for v3.10 merge window

On 3 May 2013 03:39, Suman Anna s-a...@ti.com wrote: Hi Arnd, On 04/28/2013 11:07 PM, Jassi Brar wrote: Not to mean only talk and no do, I prepared another proposal that addressed all the concerns shared so far in the RFC http://www.spinics.net/lists/kernel/msg1523873.html (its not ready

Re: [PATCH v4] mailbox/omap: adapt to the new mailbox framework

omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Cc: Jassi Brar jassisinghb...@gmail.com Cc: Ohad Ben-Cohen o...@wizery.com

Re: [PATCH v4] mailbox/omap: adapt to the new mailbox framework

omap_mbox handle. The first 2 will be removed when the OMAP mailbox driver is adapted to runtime_pm. The other exported API omap_mbox_request_channel will be removed once existing legacy users are converted to DT. Cc: Jassi Brar jassisinghb...@gmail.com Cc: Ohad Ben-Cohen o...@wizery.com

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

On 22 October 2015 at 05:35, Suman Anna wrote: >> Anyways I am OK too, if you guys want to fix it with a platform >> specific quirk. Let me know I'll pick this patch. > > I haven't gotten a chance to try #1, and I won't be able to look at it > atleast for another month. I

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlach wrote: > The mailbox framework controls the transmission queue and requires > either its controller implementations or clients to run the state > machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready > interrupt as