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(str
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.
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: Felip
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
> >> http://article.gmane.org/
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 alwa
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 subde
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 use
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
I was able to test this one with Intel Merrifield:
Acked-by: David
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<
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 0x480022
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
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 /sys/p
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 i
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 witho
it's best to just remove all ifdefs and always
define our dev_pm_ops structure.
Signed-off-by: Felipe Balbi
---
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 b/drivers/usb/dwc3/dwc3-omap.c
ind
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)
> + SET_RUNTIME_PM_OPS(kd
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
---
improve error path a little bit.
drivers/
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.
>
>
it's best to just remove all ifdefs and always
define our dev_pm_ops structure.
Signed-off-by: Felipe Balbi
---
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
index 8b20c70.
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
---
drivers/usb/dwc3/dwc3-omap.c | 39 +++--
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 p
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
---
drivers/usb/dwc3/dwc3-exynos.c | 65 --
1 file changed, 56 insertions(+), 9 deletions(-)
diff --git
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
---
drivers/usb/dwc3/dwc3-pci.c | 66 ++---
1 file changed, 51 insertions(+), 15 deletions(-)
diff --g
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
---
drivers/usb/dwc3/dwc3-keystone.c | 97 +
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
---
drivers/usb/dwc3/dwc3-omap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/u
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
---
drivers/usb/dwc3/dwc3-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
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 occasion
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 wrote:
> > * Belisko Marek [131210 14:13]:
> >> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren wrote:
> >> >
> >> > It would be best to set it up as omap-ctrl.c driver
From: Felipe Balbi
Date: Wed, 11 Dec 2013 22:09:05 -0600
> From: Mugunthan V N
>
> 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 MDIO probe, SO Enabling the
On Thu, Dec 12, 2013 at 7:28 PM, Felipe Balbi 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 *ba
On Thu, Dec 12, 2013 at 07:19:35PM +0100, Linus Walleij wrote:
> On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu wrote:
>
> > From: Felipe Balbi
> >
> > try to keep gpio block suspended as much as possible.
> >
> > Tested with pandaboard and a sysfs exported gpio.
> >
> > Signed-off-by: Felipe Balbi
>
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,
On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu wrote:
> From: Felipe Balbi
>
> try to keep gpio block suspended as much as possible.
>
> Tested with pandaboard and a sysfs exported gpio.
>
> Signed-off-by: Felipe Balbi
>
> [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added
> revision che
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 co
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 de
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
> >
> > 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 check
Enable this option as it's required to use USB on AM335x SoC.
Signed-off-by: Ezequiel Garcia
---
arch/arm/configs/omap2plus_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 12c848e..e427b95 100644
---
On Wednesday 11 December 2013 12:03 AM, Tony Lindgren wrote:
* Balaji T K [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 register.
Good to se
> 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 b
On Wednesday 11 December 2013 04:12 AM, Tony Lindgren wrote:
* Balaji T K [131210 02:17]:
Add pbias regulator node as a child of system control
module - syscon.
Signed-off-by: Balaji T K
---
arch/arm/boot/dts/dra7.dtsi | 14 ++
arch/arm/boot/dts/omap2430.dtsi | 14 +
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
> Date: Thu, 12 Dec 2013 14:52:39 +0100
> Subject: [PATCH] device tree
>
> ---
> arch/arm/bo
Maybe, this is more correctly but still doesn't work...
From 9f6e524fa86834c3ab9a5f710021620a103019b2 Mon Sep 17 00:00:00 2001
From: Denis Ciocca
Date: Thu, 12 Dec 2013 14:52:39 +0100
Subject: [PATCH] device tree
---
arch/arm/boot/dts/omap4-panda-es.dts | 22 ++
1 file
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 ?
d
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 {
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?
>
> Som
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.
>
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
+++ b/arch/arm/boot/dts/omap4-panda-es.
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 it
On Tue, Oct 29, 2013 at 02:23:18PM -0700, Tony Lindgren wrote:
> * NeilBrown [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, he
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
---
arch/arm/mach-omap2/omap_hwmod.c | 65 --
1 file changed, 63 insertions(+), 2 deletio
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
---
arch/arm/boot/dts/omap4.dtsi | 100 +++
arch/arm
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 Tero
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
---
arch/arm/mach-omap2/omap_hwmod.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a
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
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 {
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
Наша методология гарантирует Вам кристальное зрение
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 http://vger.kernel.org/majordomo-info
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 previo
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
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
pi
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.
T
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
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:
- Fo
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
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 de-interl
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 descriptor
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
Hi Tony,
On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren wrote:
> * Belisko Marek [131210 14:13]:
>> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren wrote:
>> >
>> > It would be best to set it up as omap-ctrl.c driver under drivers
>> > somewhere with few functions exported for DSS and MMC driv
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;
e
Balbi
On Thursday 12 December 2013 09:39 AM, Felipe Balbi wrote:
> From: Mugunthan V N
>
> 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.
>
> Signed-off-by: Mu
71 matches
Mail list logo