Balbi
On Thursday 12 December 2013 09:39 AM, Felipe Balbi wrote:
From: Mugunthan V N mugunthan...@ti.com
When only one port of the two port is pinned out, then dt probe is failing
because second port phy is not found. fixing this by checking the number of
slaves and breaking the loop.
On Thursday 12 December 2013 01:25 PM, Huang Shijie wrote:
On Fri, Dec 06, 2013 at 07:54:48PM +0530, Sourav Poddar wrote:
Adapt driver to do a memory mapped read.
@@ -109,6 +109,7 @@ struct m25p {
u8 program_opcode;
u8 *command;
Hi Tony,
On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren t...@atomide.com wrote:
* Belisko Marek marek.beli...@gmail.com [131210 14:13]:
On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren t...@atomide.com wrote:
It would be best to set it up as omap-ctrl.c driver under drivers
somewhere with
On Thu, Dec 12, 2013 at 01:45:24PM +0530, Sourav Poddar wrote:
On Thursday 12 December 2013 01:25 PM, Huang Shijie wrote:
+ if (spi-master-configure_from_slave)
+ m25p80_fill_flash_information(flash);
+
You have add a configure_from_slave hook in the SPI, why you also need
a
VPE and VIP IPs in DAR7x contain a color space converter(CSC) sub block. Create
a library which will perform CSC related configurations and hold CSC register
definitions. The functions provided by this library will be called by the vpe
and vip drivers using a csc_data handle.
The vpe_dev holds
The VPE and VIP IPs in DRA7x contain common scaler and color conversion hardware
blocks. We create libraries for these components such that the vpe driver and
the vip driver(in future) can use these library funcs to configure the blocks.
There are some points for which I would like comments:
-
Add the required SC register configurations which lets us perform linear scaling
for the supported range of horizontal and vertical scaling ratios.
The horizontal scaler performs polyphase scaling using it's 8 tap 32 phase
filter, decimation is performed when downscaling passes beyond 2x or 4x.
The CSC block can be used for color space conversion between YUV and RGB
formats.
It is configurable via a programmable set of coefficients. Add functionality to
choose the appropriate CSC coefficients and program them in the CSC registers.
We take the source and destination colorspace formats as
Make the driver allocate dma buffers to store horizontal and scaler coeffs.
Use the scaler library api to choose and copy scaler coefficients to a
the above buffers based on the scaling ratio. Since the SC block comes after
the de-interlacer, make sure that the source height is doubled if
The struct vpdma_data_format holds the color format depth and the data_type
value needed to be programmed in the data descriptors. However, it doesn't
tell what type of color format is it, i.e, whether it is RGB, YUV or Misc.
This information is needed when by vpdma library when forming
VPE and VIP IPs in DAR7x contain a scaler(SC) sub block. Create a library which
will perform scaler block related configurations and hold SC register
definitions. The functions provided by this library will be called by the vpe
and vip drivers using a sc_data handle.
The vpe_dev holds the sc_data
Use the csc library functions to configure the CSC block in VPE.
Some changes are required in try_fmt to handle the pix-colorspace parameter
more correctly. Previously, we copied the source queue colorspace to the
destination queue colorspace as we didn't support RGB formats. Now, we configure
On 2013-12-12 01:44, Laurent Pinchart wrote:
The DSS subdevices depend on the dss_core. dss_core has to be powered up
for any of the subdevices to work. This is done automatically by the
runtime PM when the subdevices are children of the dss_core.
I'd like to get a clearer picture of the
Hi,
On 2013-12-12 02:39, Laurent Pinchart wrote:
Hi Tomi,
On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
Hi,
Here's a new version for DT support to OMAP Display Subsystem. See
http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
the previous version,
Наша методология гарантирует Вам кристальное зрение
http://vk.com/away.php?to=http://yoga.cn.ua/tmp/xjguq.htm
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon
to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
On DRA7 though, we seem to be missing this flag, and atleast on the DRA7 EVM
where we
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
A label property is still an option.
Hmm, what do you mean? Label as in:
foo : node {
};
Isn't that 'foo' label only visible in DT itself, as a shortcut?
Some driver use a label property like this:
foo : node {
label
Hi Rajendra,
On Thursday 12 December 2013 03:22 PM, Rajendra Nayak wrote:
With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon
to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
On
With clocks for OMAP moving to DT, its now possible to pass the 'main_clk'
data for each device from DT instead of having it in hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
With support to parse clock data from DT, move all main and optional
clock information from hwmod to DT.
We still retain clocks in hwmod for devices which do not have a DT node.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 100
v1 of this series was posted a while back [1] but there wasn't much that
was concluded if the approach used in the series was acceptable or if there
are better alternatives. So I am just doing a repost of these to see if we
can conclude this time around.
Needless to say, patches are based off
With clocks for OMAP moving to DT, its now possible to pass all optional clock
data for each device from DT instead of having it in hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 65 --
1 file changed, 63
On Tue, Oct 29, 2013 at 02:23:18PM -0700, Tony Lindgren wrote:
* NeilBrown ne...@suse.de [131023 23:36]:
I submitted this in December last year. I got lots of good feedback
and fixed some things, but it never got accepted. Not entirely sure
why, maybe I dropped the ball.
Anyway,
On Thursday 12 December 2013 11:05:28 Sebastian Reichel wrote:
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
A label property is still an option.
Hmm, what do you mean? Label as in:
foo : node {
};
Isn't that 'foo' label only visible in DT itself, as a
Hi Nishant,
I've configured the device tree as you told me. Now, my device tree code
is that:
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..5644260 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++
On Thu, Oct 24, 2013 at 05:36:20PM +1100, NeilBrown wrote:
I submitted this in December last year. I got lots of good feedback
and fixed some things, but it never got accepted. Not entirely sure
why, maybe I dropped the ball.
Anyway, here is again with device-tree support added.
This
On 2013-12-12 12:05, Sebastian Reichel wrote:
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
A label property is still an option.
Hmm, what do you mean? Label as in:
foo : node {
};
Isn't that 'foo' label only visible in DT itself, as a shortcut?
Some driver use a
Hi Tomi,
On Thursday 12 December 2013 16:13:04 Tomi Valkeinen wrote:
On 2013-12-12 12:05, Sebastian Reichel wrote:
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
A label property is still an option.
Hmm, what do you mean? Label as in:
foo : node {
};
Isn't
On 2013-12-12 16:15, Laurent Pinchart wrote:
As you mentioned in your previous e-mail, if the labels are used by omapfb
only, I won't strongly push to keep them. I wonder, however, when using
DRM/KMS, where do the connector labels that are displayed by xrandr for
instance come from ?
Maybe, this is more correctly but still doesn't work...
From 9f6e524fa86834c3ab9a5f710021620a103019b2 Mon Sep 17 00:00:00 2001
From: Denis Ciocca denis.cio...@st.com
Date: Thu, 12 Dec 2013 14:52:39 +0100
Subject: [PATCH] device tree
---
arch/arm/boot/dts/omap4-panda-es.dts | 22
On 12/12/2013 08:27 AM, Denis CIOCCA wrote:
Maybe, this is more correctly but still doesn't work...
From 9f6e524fa86834c3ab9a5f710021620a103019b2 Mon Sep 17 00:00:00 2001
From: Denis Ciocca denis.cio...@st.com
Date: Thu, 12 Dec 2013 14:52:39 +0100
Subject: [PATCH] device tree
---
On Wednesday 11 December 2013 04:12 AM, Tony Lindgren wrote:
* Balaji T K balaj...@ti.com [131210 02:17]:
Add pbias regulator node as a child of system control
module - syscon.
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 14 ++
why is mcspi1 your interrupt parent when you did a padconf for GPIO?
you want GPIO136, so you need the right gpio block as the interrupt
parent and map interrupts in the correct map.
see [1] for an example (omap2).
Oh my god! Now I've understand how device tree works...I'm sorry
Nishanth but
On Wednesday 11 December 2013 12:03 AM, Tony Lindgren wrote:
* Balaji T K balaj...@ti.com [131210 06:36]:
pbias register controls internal power supply to sd card i/o pads
in most OMAPs (OMAP2-5, DRA7).
Control bits for selecting voltage level and
enabling/disabling are in the same PBIAS
Enable this option as it's required to use USB on AM335x SoC.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/configs/omap2plus_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/omap2plus_defconfig
Hi,
On Thu, Dec 12, 2013 at 01:41:11PM +0530, Mugunthan V N wrote:
On Thursday 12 December 2013 09:39 AM, Felipe Balbi wrote:
From: Mugunthan V N mugunthan...@ti.com
When only one port of the two port is pinned out, then dt probe is failing
because second port phy is not found. fixing
On 12/12/2013 09:05 AM, Denis CIOCCA wrote:
why is mcspi1 your interrupt parent when you did a padconf for GPIO?
you want GPIO136, so you need the right gpio block as the interrupt
parent and map interrupts in the correct map.
see [1] for an example (omap2).
Oh my god! Now I've understand how
On Thu, Dec 12, 2013 at 04:19:01PM +0200, Tomi Valkeinen wrote:
On 2013-12-12 16:15, Laurent Pinchart wrote:
As you mentioned in your previous e-mail, if the labels are used by omapfb
only, I won't strongly push to keep them. I wonder, however, when using
DRM/KMS, where do the connector
On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu caesarxuc...@gmail.com wrote:
From: Felipe Balbi ba...@ti.com
try to keep gpio block suspended as much as possible.
Tested with pandaboard and a sysfs exported gpio.
Signed-off-by: Felipe Balbi balbi at ti.com
[caesarxuc...@gmail.com : Refreshed
On Mon, Dec 09, 2013 at 10:52:45AM +0200, Heikki Krogerus wrote:
Hi,
On Fri, Dec 06, 2013 at 02:15:30PM -0600, Felipe Balbi wrote:
On Tue, Dec 03, 2013 at 12:39:50PM +0200, Heikki Krogerus wrote:
On Thu, Oct 17, 2013 at 09:54:26AM -0500, Felipe Balbi wrote:
On Wed, Oct 16, 2013 at
On Thu, Dec 12, 2013 at 07:19:35PM +0100, Linus Walleij wrote:
On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu caesarxuc...@gmail.com wrote:
From: Felipe Balbi ba...@ti.com
try to keep gpio block suspended as much as possible.
Tested with pandaboard and a sysfs exported gpio.
On Thu, Dec 12, 2013 at 7:28 PM, Felipe Balbi ba...@ti.com wrote:
On Thu, Dec 12, 2013 at 07:19:35PM +0100, Linus Walleij wrote:
One thing caught my eye, you add:
+static void _aggressive_pm_runtime_get_sync(struct gpio_bank *bank)
+static void _aggressive_pm_runtime_put(struct gpio_bank
From: Felipe Balbi ba...@ti.com
Date: Wed, 11 Dec 2013 22:09:05 -0600
From: Mugunthan V N mugunthan...@ti.com
When CPSW and Davinci MDIO are build as modules, CPSW crashes when
accessing CPSW registers in CPSW probe. The same is working in built-in
as the CPSW clocks are enabled in Davindi
On Thu, Dec 12, 2013 at 09:31:02AM +0100, Belisko Marek wrote:
Hi Tony,
On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren t...@atomide.com wrote:
* Belisko Marek marek.beli...@gmail.com [131210 14:13]:
On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren t...@atomide.com wrote:
It would be
Hi Grazvydas,
Von: Grazvydas Ignotas [mailto:nota...@gmail.com]
Gesendet: Donnerstag, 12. Dezember 2013 01:21
An: linux-...@vger.kernel.org
Cc: Felipe Balbi; linux-omap@vger.kernel.org; Naumann Andreas; Grazvydas
Ignotas; sta...@vger.kernel.org
Betreff: [PATCH] usb: musb: omap2430: fix
pm_runtime_put_sync() will kill dwc3's clocks and,
since dwc3 core accesses registers during removal,
we must make sure to unregister core before
disabling clocks and pm_runtime.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 2 +-
1 file changed, 1 insertion(+), 1
even if pm_runtime_get*() fails, it still increments
pm usage counter, so we must pm_runtime_put*()
in that case too. Fix that observation in dwc3-omap.c.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
teach the PCI glue about pm_runtime so that
it's easier to teach dwc3 core about it
later.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-pci.c | 66 ++---
1 file changed, 51 insertions(+), 15
hi all,
these patches add pm_runtime support for all glue layers.
I plan to add pm_runtime support for dwc3 after these
patches are merged upstream.
Please test.
Felipe Balbi (7):
usb: dwc3: keystone: add basic PM support
usb: dwc3: omap: add basic pm_runtime support
usb: dwc3: pci: add
A bare-minimum PM implementation which will
server as building block for more complex
PM implementation in the future.
At the least will not leave clocks on unnecessarily
when e.g. a user write mem to /sys/power/state.
Signed-off-by: Felipe Balbi ba...@ti.com
---
it's best to just remove all ifdefs and always
define our dev_pm_ops structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-exynos.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
If we want to suspend/runtime in runtime, we
can do so, in OMAP's case at least, with the
same implementation we use for system pm.
This patch adds basic pm_runtime support with
that in mind.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 39
teach Exynos glue about pm_runtime so that
it's easier to teach dwc3 core about it
later.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-exynos.c | 65 --
1 file changed, 56 insertions(+), 9
On Thu, Dec 12, 2013 at 03:38:39PM -0600, Felipe Balbi wrote:
A bare-minimum PM implementation which will
server as building block for more complex
PM implementation in the future.
At the least will not leave clocks on unnecessarily
when e.g. a user write mem to /sys/power/state.
A bare-minimum PM implementation which will
server as building block for more complex
PM implementation in the future.
At the least will not leave clocks on unnecessarily
when e.g. a user write mem to /sys/power/state.
Signed-off-by: Felipe Balbi ba...@ti.com
---
improve error path a little
Hi,
On Thu, Dec 12, 2013 at 03:45:55PM -0600, Felipe Balbi wrote:
+static const struct dev_pm_ops kdwc3_dev_pm_ops = {
+ .prepare= kdwc3_prepare,
+ .complete = kdwc3_complete,
+
+ SET_SYSTEM_SLEEP_PM_OPS(kdwc3_suspend, kdwc3_resume)
+
it's best to just remove all ifdefs and always
define our dev_pm_ops structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
one more patch
drivers/usb/dwc3/dwc3-omap.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c
On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
On 2013-12-12 01:44, Laurent Pinchart wrote:
So, are they independent? I don't know =). I think they lean on the
independent side. dss_core is always needed for the submodules to work,
but for example DSI could be used without
On 12/10/2013 04:41 AM, Tomi Valkeinen wrote:
Hi,
On beagle-xm, v3.13-rc3, I see the following crash if I use the pinctrl
debugfs:
# cat /debug/pinctrl/48002030.pinmux/pins
[ 16.464233] Unhandled fault: external abort on non-linefetch (0x1028)
at 0xfa002268
in 3630 TRM, There is a
On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote:
A bare-minimum PM implementation which will
server as building block for more complex
s/server/serve ;-)
PM implementation in the future.
At the least will not leave clocks on unnecessarily
when e.g. a user write mem to
On Thu, Dec 12, 2013 at 07:29:24PM -0500, Santosh Shilimkar wrote:
On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote:
A bare-minimum PM implementation which will
server as building block for more complex
s/server/serve ;-)
hah! :-) will fix in my branch.
PM implementation in the
3430 TRM(SWPU222W) states that control core module padconf
registers have ranges:
0x48002030 to 0x48002264(CONTROL_PADCONF_SDRC_CKE1)
0x480025D8(CONTROL_PADCONF_ETK_CLK) to 0x480025F8.
AM3517 TRM(SPRUGR0C) states that control core module padconf
registers has a single range:
0x48002030 to
On 19:02-20131212, Nishanth Menon wrote:
3430 TRM(SWPU222W) states that control core module padconf
missed a typo in beagle-xm.dts which i failed to
commit --amend :( grr.. Apologies on the noise..
Fixed version below:
8
From
On Thu, Dec 12, 2013 at 03:38:41PM -0600, Felipe Balbi wrote:
teach the PCI glue about pm_runtime so that
it's easier to teach dwc3 core about it
later.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
I was able to test this one with Intel Merrifield:
Acked-by:
Hi Tomi,
On Thursday 12 December 2013 09:48:30 Tomi Valkeinen wrote:
On 2013-12-12 01:19, Laurent Pinchart wrote:
On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
Add helpers to get ports and endpoints from DT data.
While all the functions in dss-of.c might be useful for
Hi Tomi,
On Thursday 12 December 2013 10:38:34 Tomi Valkeinen wrote:
On 2013-12-12 01:44, Laurent Pinchart wrote:
The DSS subdevices depend on the dss_core. dss_core has to be powered up
for any of the subdevices to work. This is done automatically by the
runtime PM when the subdevices are
Hi Tony,
On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
On 2013-12-12 01:44, Laurent Pinchart wrote:
So, are they independent? I don't know =). I think they lean on the
independent side. dss_core is always
Hi Tomi,
On Thursday 12 December 2013 10:54:48 Tomi Valkeinen wrote:
On 2013-12-12 02:39, Laurent Pinchart wrote:
On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
Hi,
Here's a new version for DT support to OMAP Display Subsystem. See
On Thu, Dec 12, 2013 at 05:56:05PM -0800, David Cohen wrote:
On Thu, Dec 12, 2013 at 03:38:41PM -0600, Felipe Balbi wrote:
teach the PCI glue about pm_runtime so that
it's easier to teach dwc3 core about it
later.
No functional changes otherwise.
Signed-off-by: Felipe Balbi
On Thu, Dec 12, 2013 at 10:17:19PM -0600, Felipe Balbi wrote:
On Thu, Dec 12, 2013 at 05:56:05PM -0800, David Cohen wrote:
On Thu, Dec 12, 2013 at 03:38:41PM -0600, Felipe Balbi wrote:
teach the PCI glue about pm_runtime so that
it's easier to teach dwc3 core about it
later.
No
Hi Felipe,
-static int dwc3_exynos_suspend(struct device *dev)
+static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
{
- struct dwc3_exynos *exynos = dev_get_drvdata(dev);
-
clk_disable(exynos-clk);
return 0;
}
+static int __dwc3_exynos_resume(struct
71 matches
Mail list logo
