Re: USB & hwmon on am33xx
On 7/10/2013 1:31 AM, Sebastian Andrzej Siewior wrote: > On 07/09/2013 08:08 PM, Mugunthan V N wrote: >> Yes, you need hwmod entry for each of the above device. Since USB has only >> only >> clock ctrl register, have one as parrent and make other devices as child >> node. >> you can take CPSW as an example. > So there is not some kind of ref counting if I use this entry twice? > What about the PWM as an example? It has two child nodes and also only > one clock register. > Yes, you can take PWM as example. Regards Mugunthan V N -- 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.html
Re: [PATCH 0/5] Add phy support for AM335X platform using Generic PHy framework
On 7/10/2013 10:53 AM, Felipe Balbi wrote:
On Wed, Jul 10, 2013 at 10:26:25AM +0530, George Cherian wrote:
On 7/9/2013 5:05 PM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 09 July 2013 11:10 AM, George Cherian wrote:
On 7/9/2013 1:14 AM, Sebastian Andrzej Siewior wrote:
On 07/08/2013 12:43 PM, George Cherian wrote:
This patch series adds phy support for AM335X platform.
This patch series is based on Generic PHY framework [1].
This series has
- adds dual musb instances support for am335x platform (just for testing)
- adds phy-am-usb driver used in AM platforms
- adds dt bindings for the phys
- removes usb-phy and replaced with generic phy apis in glue layer
No, I don't like this all. You did the one thing I tried to avoid while
posting my quick-and-dirty phy driver recently: You duplicated a lot of
code which can be served by the nop driver and added only power
on/power off callbacks.
I wanted to add phy wakeup control also, but currently phy_ops dont have an op
for wkup_ctrl
Kishon, Can we add one?
Since this should be a capability of the PHY, can't we have wkup_ctrl always
enabled if the PHY has such a capability?
No, we cant have wakeup always enabled. Normally we enable it only
when we go to low power states and
if the user needs USB a wakeup source.
So how about enable/disable phy wakeup from phy suspend/resume?
you should use something like so on your ->suspend() or
->runtime_suspend() method
static int my_phy_{suspend,runtime_suspend}(struct device *dev)
{
struct my_phy *phy = dev_get_drvdata(dev);
if (device_may_wakeup(dev))
my_phy_enable_wakeup(phy);
return 0;
}
Makes sense. will do it in v2.
or if it needs more user control,
should we implement a sysfs entry to enable wakeup?
that already exists ;-)
--
-George
--
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.html
Re: [PATCH 0/5] Add phy support for AM335X platform using Generic PHy framework
On Wed, Jul 10, 2013 at 10:26:25AM +0530, George Cherian wrote:
> On 7/9/2013 5:05 PM, Kishon Vijay Abraham I wrote:
> >Hi,
> >
> >On Tuesday 09 July 2013 11:10 AM, George Cherian wrote:
> >>On 7/9/2013 1:14 AM, Sebastian Andrzej Siewior wrote:
> >>>On 07/08/2013 12:43 PM, George Cherian wrote:
> This patch series adds phy support for AM335X platform.
> This patch series is based on Generic PHY framework [1].
>
>
> This series has
> - adds dual musb instances support for am335x platform (just for
> testing)
> - adds phy-am-usb driver used in AM platforms
> - adds dt bindings for the phys
> - removes usb-phy and replaced with generic phy apis in glue layer
> >>>No, I don't like this all. You did the one thing I tried to avoid while
> >>>posting my quick-and-dirty phy driver recently: You duplicated a lot of
> >>>code which can be served by the nop driver and added only power
> >>>on/power off callbacks.
> >>I wanted to add phy wakeup control also, but currently phy_ops dont have
> >>an op
> >>for wkup_ctrl
> >>Kishon, Can we add one?
> >Since this should be a capability of the PHY, can't we have wkup_ctrl always
> >enabled if the PHY has such a capability?
>
> No, we cant have wakeup always enabled. Normally we enable it only
> when we go to low power states and
> if the user needs USB a wakeup source.
>
> So how about enable/disable phy wakeup from phy suspend/resume?
you should use something like so on your ->suspend() or
->runtime_suspend() method
static int my_phy_{suspend,runtime_suspend}(struct device *dev)
{
struct my_phy *phy = dev_get_drvdata(dev);
if (device_may_wakeup(dev))
my_phy_enable_wakeup(phy);
return 0;
}
> >or if it needs more user control,
> >should we implement a sysfs entry to enable wakeup?
that already exists ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/5] Add phy support for AM335X platform using Generic PHy framework
On 7/9/2013 5:05 PM, Kishon Vijay Abraham I wrote: Hi, On Tuesday 09 July 2013 11:10 AM, George Cherian wrote: On 7/9/2013 1:14 AM, Sebastian Andrzej Siewior wrote: On 07/08/2013 12:43 PM, George Cherian wrote: This patch series adds phy support for AM335X platform. This patch series is based on Generic PHY framework [1]. This series has - adds dual musb instances support for am335x platform (just for testing) - adds phy-am-usb driver used in AM platforms - adds dt bindings for the phys - removes usb-phy and replaced with generic phy apis in glue layer No, I don't like this all. You did the one thing I tried to avoid while posting my quick-and-dirty phy driver recently: You duplicated a lot of code which can be served by the nop driver and added only power on/power off callbacks. I wanted to add phy wakeup control also, but currently phy_ops dont have an op for wkup_ctrl Kishon, Can we add one? Since this should be a capability of the PHY, can't we have wkup_ctrl always enabled if the PHY has such a capability? No, we cant have wakeup always enabled. Normally we enable it only when we go to low power states and if the user needs USB a wakeup source. So how about enable/disable phy wakeup from phy suspend/resume? or if it needs more user control, should we implement a sysfs entry to enable wakeup? Nope, I dont want to create another sysfs entry. Thanks Kishon -- -George -- 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.html
Re: find real users and drivers of rpmsg
Hi Suman, 2013/7/10 Suman Anna : > Barry, > >> On Mon, Jul 8, 2013 at 10:31 AM, Barry Song <21cn...@gmail.com> wrote: >>> hi Ohad/all, >>> i am trying to find some real users of rpmsg, here i only get >>> samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers >>> are out of mainline? >> >> Yes >> >>> where could i get them? >> >> TI maintains them in internal trees, some of which might be public. >> I'm looping in Suman from TI who might be able to refer you to some > > You will find couple of rpmsg client drivers in our product kernels. > Following is a kernel used towards our Android product, you can look > in the drivers/rpmsg folder. > > http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4 yes. i have repmsg-resmgr and repmsg-omx now. and i also have sysbios-rpmsg and domx. thanks! > >> >>> i am also trying to find source codes running in Cortex-M3 which use >>> rpmsg and hope to find some Linux userspace codes which use rpmsg too. >>> Thanks >>> barry > > Some information from the following wiki might also be handy (kinda old, > but still useful) for you to find the equivalent code running on the > Cortex-M3 > > http://omappedia.org/wiki/Category:RPMsg DOMX(Distributed OpenMAX for OMAP4 processors) on the page seems to be based on syslink and lose maintaince for 3 years, where can i get a new version based on rpmsg? > > regards > Suman > -barry -- 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.html
[PATCH] bq24190_charger: Add support for TI BQ24190 Battery Charger
From: "Mark A. Greer" Add driver support for the Texas Instruments BQ24190 battery charger. Some of the information provided by the device is about the charger and other information is about the battery so create two power_supply objects (one for each) and provide the appropriate information for each one. The device has many fields that go beyond what is reasonable to report or modify using the existing 'POWER_SUPPLY_PROP_*' properties so the driver exports the register fields via sysfs. They are prefixed by 'f_' (for 'field') to make it easier to distinguish between a register field and a "normal" sysfs file exported by the power_supply infrastructure. Signed-off-by: Mark A. Greer --- - Tested on an ARM 3703-based platform which hasn't been submitted to the community yet. - Patch based on git://git.infradead.org/battery-2.6.git but was tested on stock 3.10 plus patches for platform mentioned above. - Information on the device is available here: http://www.ti.com/product/bq24190?DCMP=hpa-pmp-battery-bq2419x-en&HQS=bq24190-pr drivers/power/Kconfig |6 + drivers/power/Makefile|1 + drivers/power/bq24190_charger.c | 1538 + include/linux/power/bq24190_charger.h | 16 + 4 files changed, 1561 insertions(+) create mode 100644 drivers/power/bq24190_charger.c create mode 100644 include/linux/power/bq24190_charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 7b8979c..c31ec0a 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -334,6 +334,12 @@ config CHARGER_BQ2415X You'll need this driver to charge batteries on e.g. Nokia RX-51/N900. +config CHARGER_BQ24190 + tristate "TI BQ24190 battery charger driver" + depends on I2C && GPIOLIB + help + Say Y to enable support for the TI BQ24190 battery charger. + config CHARGER_SMB347 tristate "Summit Microelectronics SMB347 Battery Charger" depends on I2C diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 653bf6c..4ae4533 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o +obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o diff --git a/drivers/power/bq24190_charger.c b/drivers/power/bq24190_charger.c new file mode 100644 index 000..f077fe6 --- /dev/null +++ b/drivers/power/bq24190_charger.c @@ -0,0 +1,1538 @@ +/* + * Driver for the TI bq24190 battery charger. + * + * Author: Mark A. Greer + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +#defineBQ24190_MANUFACTURER"Texas Instruments" + +#define BQ24190_REG_ISC0x00 /* Input Source Control */ +#define BQ24190_REG_ISC_EN_HIZ_MASKBIT(7) +#define BQ24190_REG_ISC_EN_HIZ_SHIFT 7 +#define BQ24190_REG_ISC_VINDPM_MASK(BIT(6) | BIT(5) | BIT(4) | \ +BIT(3)) +#define BQ24190_REG_ISC_VINDPM_SHIFT 3 +#define BQ24190_REG_ISC_IINLIM_MASK(BIT(2) | BIT(1) | BIT(0)) +#define BQ24190_REG_ISC_IINLIM_SHIFT 0 + +#define BQ24190_REG_POC0x01 /* Power-On Configuration */ +#define BQ24190_REG_POC_RESET_MASK BIT(7) +#define BQ24190_REG_POC_RESET_SHIFT7 +#define BQ24190_REG_POC_WDT_RESET_MASK BIT(6) +#define BQ24190_REG_POC_WDT_RESET_SHIFT6 +#define BQ24190_REG_POC_CHG_CONFIG_MASK(BIT(5) | BIT(4)) +#define BQ24190_REG_POC_CHG_CONFIG_SHIFT 4 +#define BQ24190_REG_POC_SYS_MIN_MASK (BIT(3) | BIT(2) | BIT(1)) +#define BQ24190_REG_POC_SYS_MIN_SHIFT 1 +#define BQ24190_REG_POC_BOOST_LIM_MASK BIT(0) +#define BQ24190_REG_POC_BOOST_LIM_SHIFT0 + +#define BQ24190_REG_CCC0x02 /* Charge Current Control */ +#define BQ24190_REG_CCC_ICHG_MASK (BIT(7) | BIT(6) | BIT(5) | \ +BIT(4) | BIT(3) | BIT(2)) +#define BQ24190_REG_CCC_ICHG_SHIFT 2 +#define BQ24190_REG_CCC_FORCE_20PCT_MASK BIT(0) +#define BQ24190_REG_CCC_FORCE_20PCT_SHIFT 0 + +#define BQ24190_REG_PCTCC 0x03 /* Pre-charge/Termination Current Cntl */ +#define BQ24190_REG_PCTCC_IPRECHG_MASK (BIT(7) | BIT(6) | BIT(5) | \ +BI
Re: find real users and drivers of rpmsg
Barry, > On Mon, Jul 8, 2013 at 10:31 AM, Barry Song <21cn...@gmail.com> wrote: >> hi Ohad/all, >> i am trying to find some real users of rpmsg, here i only get >> samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers >> are out of mainline? > > Yes > >> where could i get them? > > TI maintains them in internal trees, some of which might be public. > I'm looping in Suman from TI who might be able to refer you to some You will find couple of rpmsg client drivers in our product kernels. Following is a kernel used towards our Android product, you can look in the drivers/rpmsg folder. http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4 > >> i am also trying to find source codes running in Cortex-M3 which use >> rpmsg and hope to find some Linux userspace codes which use rpmsg too. >> Thanks >> barry Some information from the following wiki might also be handy (kinda old, but still useful) for you to find the equivalent code running on the Cortex-M3 http://omappedia.org/wiki/Category:RPMsg regards Suman -- 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.html
Re: USB & hwmon on am33xx
On 07/09/2013 08:08 PM, Mugunthan V N wrote: > Yes, you need hwmod entry for each of the above device. Since USB has only > only > clock ctrl register, have one as parrent and make other devices as child > node. > you can take CPSW as an example. So there is not some kind of ref counting if I use this entry twice? What about the PWM as an example? It has two child nodes and also only one clock register. > Regards > Mugunthan V N Sebastian -- 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.html
Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
Hi,
On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
> >>>Imagine the device is marked as suspended even though it's fully enabled
> >>>(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>>your context structure is all zeroes (context has never been saved
> >>>before) then when you call pm_runtime_get_sync() on probe() your
> >>>->runtime_resume() will get called, which will restore context,
> >>>essentially undoing anything which was configured by u-boot.
> >>
> >>This could be a problem for drivers which do a save context in
> >>->runtime_suspend()
> >>but from what I see with omap serial, there is no save context done as part
> >>of
> >>->runtime_suspend.
> >
> >right, because context is "saved" in set_termios. probe() will get
> >called much before set_termios() has a chance to run, right ?
> >
> >Same problem will trigger in that case.
> >
> >I still think patch below is necessary
> >
> >>>(completely untested, didn't even try to compile, just to illustrate)
> >>>
> >>>diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> >>>b/arch/arm/mach-omap2/omap_hwmod.c
> >>>index 7341eff..d8dca68 100644
> >>>--- a/arch/arm/mach-omap2/omap_hwmod.c
> >>>+++ b/arch/arm/mach-omap2/omap_hwmod.c
> >>>@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct
> >>>omap_hwmod *oh)
> >>> (postsetup_state == _HWMOD_STATE_IDLE)) {
> >>> oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >>> postsetup_state = _HWMOD_STATE_ENABLED;
> >>>+
> >>>+ /* tell pm_runtime this device is already active */
> >>>+ pm_runtime_set_active(&oh->od->pdev->dev);
> >>>+ } else {
> >>>+ /* tell pm_runtime this device is trully suspended */
> >>>+ pm_runtime_set_suspended(&oh->od->pdev->dev);
> >>> }
> >>>
> >>> if (postsetup_state == _HWMOD_STATE_IDLE)
> >
>
> This will not work - _setup_postsetup() is called from core_initcall
> level and OMAP devices have not been created at this moment yet
> (of_platform_populate() is called from
> customize_machine->init_machine->omap_generic_init() at arch_initcall time)
fair enough, but something *like* that needs to be done. If pm_runtime
doesn't know the state of the device by the time pm_runtime_enable() is
called, the wrong assumptions might be made and we will forever have
such problems as our ->runtime_resume() callback being called when it
shouldn't.
> More over, I don't recommend to depend on hwmod->od field - it's been
> created to support OPPs and it's obsolete now in case of DT use.
that's alright, but still we need something similar.
But in any case, if on DT boot that's not used, than *what* uses
HWMOD_INIT_NO_IDLE during DT boot ?
There's a single place in kernel source which checks if
HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.
We, certainly, need a way to tell pm_runtime if the device is active or
suspended by the time we reach our probe() function. Either we assume
*all* devices are active and we blindly call pm_runtime_set_active() for
all devices, or we assume *all* devices are suspended as we call
pm_runtime_set_suspend() for all devices, or we figure out which ones
are active and which are not and call pm_runtime_set_{active,suspend}()
conditionally.
> Seems, This issue need to be handled in driver for DT boot use case,
> possibly cmdline need to be parsed in the same way as it's done in
> omap_serial_early_init().
so you want *every* single driver to parse their own cmdline ? How big
would the cmdline become ? This makes no sense.
--
balbi
signature.asc
Description: Digital signature
Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
Hi,
On 07/09/2013 09:42 AM, Felipe Balbi wrote:
Hi,
On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
I wonder if this is because the timeouts get now initialized to 0 instead
of -1 for the serial driver?
You meant initialized to -1, right? There's an additional check for timeout
being 0. Unless i
am missing something DT-boot will start off with timeout set to 0 and then get
forced to -1.
OK
Issue 2: Causing boot to stop when serial driver is initialized.
(After Issue 1 is fixed)
I could narrow this down to the change done to return -EINVAL
instead of 0 in serial_omap_get_context_loss_count() as part of
commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
Fix device tree based PM runtime"
What this change in turn seems to do is cause a
serial_omap_restore_context() to get called as part of
serial_omap_runtime_resume() which was not the case when
serial_omap_get_context_loss_count() returned 0
from serial_omap_runtime_resume():
-
int loss_cnt = serial_omap_get_context_loss_count(up);
if (loss_cnt < 0) {
dev_dbg(dev, "serial_omap_get_context_loss_count failed :
%d\n",
loss_cnt);
serial_omap_restore_context(up);
} else if (up->context_loss_cnt != loss_cnt) {
serial_omap_restore_context(up);
}
-
I am still working on why a serial_omap_restore_context() could
have caused console to die. I will work with Sourav on this and
post the fixes for both issue 1 and issue2 once its clear on whats
really causing issue 2.
That's because we don't have the omap specific pdata callbacks for
context loss any longer. We may be able to detect when the context
was really lost in the serial driver, and only then call the
serial_omap_restore_context().
Right, but calling serial_omap_restore_context() even when the context
is not lost, should not ideally cause an issue.
it does in one condition. If context hasn't been saved before. And that
can happen in the case of wrong pm runtime status for that device.
Imagine the device is marked as suspended even though it's fully enabled
(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
your context structure is all zeroes (context has never been saved
before) then when you call pm_runtime_get_sync() on probe() your
->runtime_resume() will get called, which will restore context,
essentially undoing anything which was configured by u-boot.
This could be a problem for drivers which do a save context in
->runtime_suspend()
but from what I see with omap serial, there is no save context done as part of
->runtime_suspend.
right, because context is "saved" in set_termios. probe() will get
called much before set_termios() has a chance to run, right ?
Same problem will trigger in that case.
I still think patch below is necessary
(completely untested, didn't even try to compile, just to illustrate)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..d8dca68 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod
*oh)
(postsetup_state == _HWMOD_STATE_IDLE)) {
oh->_int_flags |= _HWMOD_SKIP_ENABLE;
postsetup_state = _HWMOD_STATE_ENABLED;
+
+ /* tell pm_runtime this device is already active */
+ pm_runtime_set_active(&oh->od->pdev->dev);
+ } else {
+ /* tell pm_runtime this device is trully suspended */
+ pm_runtime_set_suspended(&oh->od->pdev->dev);
}
if (postsetup_state == _HWMOD_STATE_IDLE)
This will not work - _setup_postsetup() is called from core_initcall
level and OMAP devices have not been created at this moment yet
(of_platform_populate() is called from
customize_machine->init_machine->omap_generic_init() at arch_initcall time)
More over, I don't recommend to depend on hwmod->od field - it's been
created to support OPPs and it's obsolete now in case of DT use.
Seems, This issue need to be handled in driver for DT boot use case,
possibly cmdline need to be parsed in the same way as it's done in
omap_serial_early_init().
Regards,
-grygorii
--
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.html
Re: USB & hwmon on am33xx
On 7/9/2013 10:02 PM, Sebastian Andrzej Siewior wrote: > Hi Paul, > > I'm slowly losing my mind with hwmod. > > arch/arm/boot/dts/am33xx.dtsi has the ti,musb-am33xx node. > > That one has "usb_otg_hs" as hwmod property. > The entry for it arch/arm/mach-omap2/omap_hwmod_33xx_data.c uses > AM33XX_CM_PER_USB0_CLKCTRL_OFFSET (0x1c) as the clk. The TRM only > mentions this one, i.e. no USB1. > > Now I have the following logical devices here: > - usb0 instance + its glue code for irqs > - usb1 instance + its glue code for irqs > - two phy instances, one for USB0 and one USB1 > - one dma engine which serves both usb instances. > > Shouldn't I have for each device (usb0/1, phy0/1, dma) a hwmod entry? > Or is it enough to use the same entry for each device? Yes, you need hwmod entry for each of the above device. Since USB has only only clock ctrl register, have one as parrent and make other devices as child node. you can take CPSW as an example. Regards Mugunthan V N -- 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.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On 07/09/2013 05:16 PM, Stefan Roese wrote: > Hi Roger, > > On 07/09/2013 03:55 PM, Roger Quadros wrote: >>> I'm using latest kernel.org for this (git ID d2b4a646 also tested with >>> v3.10 release). This is with DT-enabled booting and without-DT (same >>> problem). I also tested some older Linux kernel versions and it fails >>> there as well. Only v3.2.40 seems to be able to mount this rootfs via >>> NFS reliably (approx. 10 times success). >> >> I can't really tell at the moment where the problem is. >> >> Did you compile in all the necessary drivers required for NFS booting? >> In the beagle case that would mean NOP_USB_XCEIV, USB_EHCI_HCD, >> USB_EHCI_HCD_OMAP >> and the smsc95xx driver. > > Yes, sure. Otherwise no USB/NFS mount would have been possible. > >> If you can paste your full kernel boot log we can check if all these show up >> before the kernel tries to look up for the NFS server. > > Please find it attached (one log for the NFS mount working and one for > failing - both with exact the same kernel/dtb). Also my current .config. > Thanks for the logs. Configuration part seems OK. NFS root has been mounted in failing case as well. Then it fails. I'll need to investigate more what happens. cheers, -roger -- 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.html
USB & hwmon on am33xx
Hi Paul, I'm slowly losing my mind with hwmod. arch/arm/boot/dts/am33xx.dtsi has the ti,musb-am33xx node. That one has "usb_otg_hs" as hwmod property. The entry for it arch/arm/mach-omap2/omap_hwmod_33xx_data.c uses AM33XX_CM_PER_USB0_CLKCTRL_OFFSET (0x1c) as the clk. The TRM only mentions this one, i.e. no USB1. Now I have the following logical devices here: - usb0 instance + its glue code for irqs - usb1 instance + its glue code for irqs - two phy instances, one for USB0 and one USB1 - one dma engine which serves both usb instances. Shouldn't I have for each device (usb0/1, phy0/1, dma) a hwmod entry? Or is it enough to use the same entry for each device? Sebastian -- 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.html
Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 07/09/2013 10:29 AM, Mark Brown wrote: On Mon, Jul 08, 2013 at 12:22:36PM -0500, Nishanth Menon wrote: case #1 - TPS62361 has a single SMPS and a single generic i2c bus, one can talk on. In this case, you'd associate the regulator device in one place - i2cX or on custom SoC hardware interface. When used with custom SoC hardware interface, generic tps62361 regulator which talks regular i2c wont even probe for omap_pmic to get the regulator data from tps62361 regulator driver. Even if we were to define the generic TPS62361 in dts nodes, it will fail probe as it cant access any of it's registers using generic i2c. This seems like something we should be able to cope with by for example adding a bus for the custom PMIC interface or otherwise finding a way to I had considered introducing a custom bus for custom PMIC interface, but as you stated below, standard regulators will probably need some custom monkeying around. get to the data at runtime based on the compatible string. This would need some custom code in the regulators but would have the advantage of keeping the data the same at least. Hrm. Ofcourse,this will be to add custom set/get_voltage implementation using this "custom API" which we discussed was'nt that good an idea. I am at a stalemate as to where we should go from here. Another option is for the drivers to provide the data and use the helpers for their linear ranges as part of a more complex implementation. Having looked at a few regulator driver implementations, there seems to be the following combinations: a) drivers which have n ranges of linear voltages for incremental selector b) drivers with 1 range of linear voltages only for all ranges of selectors c) drivers with 1 range of linear voltages and nonlinear voltage values for other vsels. Everything else is just a special case of option a - either there's just a single range or there's a bunch of ranges each with a single value. I suspect that ranges will be the most useful thing for any hardware which can practically be used by these regulators anyway. True, but slightly different topic though. OK, that's a bit more fun but I think the kernel wants that information in general anyway since a software cpufreq driver or something might want to make the same latency decisions. This is what set_voltage_time() is for in part. But to a first approximation is there really much variation in the numbers? between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec, TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec Those are ramp rates, they're not I2C I/O limits. Ramp rates we already know about. I think what you're saying here is that this latency value is actually about worst case ramp times? Arrgh.. my bad. I confused ramp time with I2C transfer timeout parameter. I know that I2C bus can be held[1] by PMIC as long as it is busy. Some custom ASIC can do some weird stuff I suppose. I dont seem to have clear data points in the sketchy TRMs for 6030/2 , 6035, 5030, for these other than to state it is i2c specification compliant (/me grumbles). So, I just have emperical value which is a bit conservative and seem to work on the devices. [1] http://www.i2c-bus.org/clock-generation-stretching-arbitration/ -- Regards, Nishanth Menon -- 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.html
Re: How to keep DM37x GPIO_162 high during off-mode
* Peter Barada [130709 08:14]: > I'm working with a 3.0.8 kernel in Android ICS and have run into a > problem using wl12xx bluetooth after a suspend/resume cycle. > > GPIO_162 in this design is connected to the BT_EN pin of the wl12xx and > needs to be held high to keep the bluetooth core from resetting while > the DM37x goes into off mode. > > I've tried muxing the pin using OMAP_PIN_OUTPUT | > OMAP_PIN_OFF_OUTPUT_HIGH, but the pin goes low when the chip goes into > off mode. If I disable off mode via "echo 0 > > /sys/kernel/debug/pm_debug/enable_off_mode" the pin remains high while > the chip goes into retention and the bluetooth core works after resume. > > Any ideas why GPIO_162 would go low during suspend to off mode? Unless the GPIO is in a GPIO bank that's connected to the WKUP power domain, the GPIO bank context will be lost. So there's a short period where the GPIO bank is in an uninitialized state between waking from off-idle and before the context to the GPIO bank gets restored in omap_gpio_runtime_resume(). If there's a pull on the line, the period is long enough to change the line. Unless the TI people know some magic tricks that I'm not aware of, there's no way around it, except to use external pulls to keep the GPIO line in desired state, or move the GPIO somewhere else, like TWL. Regards, Tony -- 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.html
Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jul 08, 2013 at 12:22:36PM -0500, Nishanth Menon wrote: > case #1 - TPS62361 has a single SMPS and a single generic i2c bus, > one can talk on. In this case, you'd associate the regulator device > in one place - i2cX or on custom SoC hardware interface. > When used with custom SoC hardware interface, generic tps62361 > regulator which talks regular i2c wont even probe for omap_pmic to > get the regulator data from tps62361 regulator driver. Even if we > were to define the generic TPS62361 in dts nodes, it will fail probe > as it cant access any of it's registers using generic i2c. This seems like something we should be able to cope with by for example adding a bus for the custom PMIC interface or otherwise finding a way to get to the data at runtime based on the compatible string. This would need some custom code in the regulators but would have the advantage of keeping the data the same at least. Hrm. > >Another option is for the drivers to provide the data and use the > >helpers for their linear ranges as part of a more complex > >implementation. > Having looked at a few regulator driver implementations, there seems > to be the following combinations: > a) drivers which have n ranges of linear voltages for incremental selector > b) drivers with 1 range of linear voltages only for all ranges of selectors > c) drivers with 1 range of linear voltages and nonlinear voltage > values for other vsels. Everything else is just a special case of option a - either there's just a single range or there's a bunch of ranges each with a single value. I suspect that ranges will be the most useful thing for any hardware which can practically be used by these regulators anyway. > >OK, that's a bit more fun but I think the kernel wants that information > >in general anyway since a software cpufreq driver or something might > >want to make the same latency decisions. This is what set_voltage_time() > >is for in part. But to a first approximation is there really much > >variation in the numbers? > between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec, > TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec Those are ramp rates, they're not I2C I/O limits. Ramp rates we already know about. I think what you're saying here is that this latency value is actually about worst case ramp times? signature.asc Description: Digital signature
How to keep DM37x GPIO_162 high during off-mode
I'm working with a 3.0.8 kernel in Android ICS and have run into a problem using wl12xx bluetooth after a suspend/resume cycle. GPIO_162 in this design is connected to the BT_EN pin of the wl12xx and needs to be held high to keep the bluetooth core from resetting while the DM37x goes into off mode. I've tried muxing the pin using OMAP_PIN_OUTPUT | OMAP_PIN_OFF_OUTPUT_HIGH, but the pin goes low when the chip goes into off mode. If I disable off mode via "echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode" the pin remains high while the chip goes into retention and the bluetooth core works after resume. Any ideas why GPIO_162 would go low during suspend to off mode? Note I can't move to a newer kernel due to scheduling constraints. Thanks in advance! -- Peter Barada peter.bar...@logicpd.com -- 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.html
Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Hello.
On 07/09/2013 06:07 PM, Sergei Shtylyov wrote:
Adds device node for HS USB Host module for AM437x
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
Signed-off-by: George Cherian
---
arch/arm/boot/dts/am4372.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
compatible = "ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+usb_otg_hs1: am4372_dwc3@4838 {
See http://www.devicetree.org/Device_Tree_Usage, "Node Names" section.
+compatible = "ti,am437x-dwc3";
+reg = <0x4838 0x1ff>;
And I bet this should be 0x200, not 0x1ff. This is length, not upper
limit.
+interrupts = ;
+#address-cells = <1>;
+#size-cells = <1>;
+utmi-mode = <1>;
+ranges;
+
+dwc3@4839 {
The same comment.
+compatible = "snps,dwc3";
+reg = <0x4839 0xcfff>;
The same, this should be 0xd000, not 0xcfff.
+interrupts = ;
+};
+
+};
+
WBR, Sergei
--
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.html
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On 15:40-20130709, Mark Brown wrote: > On Tue, Jul 09, 2013 at 07:50:55AM -0500, Nishanth Menon wrote: > > > with this input and looking closer, I think I see what you are saying now: > > dra7xxx_qspi_prepare_xfer -> does a pm_runtime_get_sync > > dra7xxx_qspi_unprepare_xfer -> does a pm_runtime_mark_last_busy, > > pm_runtime_put_autosuspend > > > In between these calls, you have the remaining xfer calls going on. > > we are assuming here that autosuspend timeout should be greater than > > the time to complete the worst case transfer. > > No, autosuspend will do nothing so long as there are references to the > device held. The effect of autosuspend is to delay power down after the > last reference has been dropped, otherwise things run normally. Thanks on the clarification. That concludes my confusion on the topic :). -- Regards, Nishanth Menon -- 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.html
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On Tue, Jul 09, 2013 at 07:50:55AM -0500, Nishanth Menon wrote: > with this input and looking closer, I think I see what you are saying now: > dra7xxx_qspi_prepare_xfer -> does a pm_runtime_get_sync > dra7xxx_qspi_unprepare_xfer -> does a pm_runtime_mark_last_busy, > pm_runtime_put_autosuspend > In between these calls, you have the remaining xfer calls going on. > we are assuming here that autosuspend timeout should be greater than > the time to complete the worst case transfer. No, autosuspend will do nothing so long as there are references to the device held. The effect of autosuspend is to delay power down after the last reference has been dropped, otherwise things run normally. signature.asc Description: Digital signature
Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Hello.
On 09-07-2013 13:17, George Cherian wrote:
Adds device node for HS USB Host module for AM437x
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
Signed-off-by: George Cherian
---
arch/arm/boot/dts/am4372.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
compatible =
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+ usb_otg_hs1: am4372_dwc3@4838 {
See http://www.devicetree.org/Device_Tree_Usage, "Node Names" section.
+ compatible = "ti,am437x-dwc3";
+ reg = <0x4838 0x1ff>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ utmi-mode = <1>;
+ ranges;
+
+ dwc3@4839 {
The same comment.
+ compatible = "snps,dwc3";
+ reg = <0x4839 0xcfff>;
+ interrupts = ;
+ };
+
+ };
+
WBR, Sergei
--
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.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On 06/28/2013 10:06 PM, Alan Stern wrote: > On Fri, 28 Jun 2013, Roger Quadros wrote: > >>> That's not what I meant. Never mind the pinctrl; I was asking about >>> the EHCI controller itself. Under what circumstances does the >>> controller assert its wakeup signal? And how do you tell it to stop >>> asserting that signal? >> >> I believe this would be through the EHCI Interrupt enable register (USBINTR). >> I'm not aware of any other mechanism. > > That's strange, because ehci_suspend() sets the intr_enable register to > 0. So how do you ever get any wakeup interrupts at all? > >> Right. It seems the external hub has signaled remote wakeup but the kernel >> doesn't >> resume the root hub's port it is connected to. >> >> By observing the detailed logs below you can see that the root hub does not >> generate >> an INTerrupt transaction to notify the port status change event. I've >> captured the pstatus >> and GetPortStatus info as well. > > We don't need an interrupt. The driver is supposed to detect the > remote wakeup sent by the external hub all by itself. > >> Failing case >> >> >> [ 16.108032] usb usb1: usb auto-resume >> [ 16.108062] ehci-omap 48064800.ehci: resume root hub >> [ 16.108154] hub 1-0:1.0: hub_resume >> [ 16.108398] ehci_hub_control GetPortStatus, port 1 temp = 0x1000 >> [ 16.108459] ehci_hub_control GetPortStatus, port 2 temp = 0x14c5 > > Here's where we should detect it. Look at the GetPortStatus case in > ehci_hub_control(); the PORT_RESUME bit (0x0040) is set in temp, so the > "Remote Wakeup received?" code should run. In particular, these lines > should run: > > /* resume signaling for 20 msec */ > ehci->reset_done[wIndex] = jiffies > + msecs_to_jiffies(20); > usb_hcd_start_port_resume(&hcd->self, wIndex); > /* check the port again */ > mod_timer(&ehci_to_hcd(ehci)->rh_timer, > ehci->reset_done[wIndex]); > > Therefore 20 ms later, around timestamp 16.128459, > ehci_hub_status_data() should have been called. At that time, the > root-hub port should have been fully resumed. > >> [ 16.108551] hub 1-0:1.0: port 2: status 0507 change >> [ 16.108612] ehci_hub_control GetPortStatus, port 3 temp = 0x1000 >> [ 16.108642] hub 1-0:1.0: hub_activate submitting urb >> [ 16.109222] ehci_irq port 3 pstatus 0x1000 >> [ 16.109222] ehci_irq port 2 pstatus 0x14c5 >> [ 16.109252] ehci_irq port 1 pstatus 0x1000 >> [ 16.109374] hub 1-0:1.0: state 7 ports 3 chg evt > > But apparently nothing happened. Why not? Did the rh_timer get reset? > Maybe you can find out what went wrong. > > (Hmmm, we seem to be missing a > > set_bit(wIndex, &ehci->resuming_ports); > > line in there...) > Right. This is indeed the problem. I've cooked up a patch for that and will send it separately in a moment. cheers, -roger -- 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.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
Hi Stefan, On 07/09/2013 04:02 PM, Stefan Roese wrote: > Roger, > > On 04/15/2013 01:20 PM, Roger Quadros wrote: >> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is >> reversed when compared to other revisions i.e. it is >> active high instead of active low. >> >> Use the beagle_config.usb_pwr_level flag correctly so that >> the power regulator can be configured at runtime. >> >> Signed-off-by: Roger Quadros > > I'm currently trying to use an SMSC95xx USB ethernet adapter on the > OMAP3 Beagleboard (old one "Beagle Rev C1/C2/C3") via the OMAP EHCI > controller. And am testing this by trying to mount the rootfs via NFS. > What I see is that the NFS mounting stalls/hangs most of the time quite > early in the mount process: > > [6.425689] VFS: Mounted root (nfs filesystem) on device 0:12. > [6.435485] devtmpfs: mounted > [6.440002] Freeing unused kernel memory: 384K (c077a000 - c07da000) > INIT: version 2.88 booting > Starting udev > [ 188.311309] nfs: server 10.0.0.152 not responding, still trying > [ 188.317687] nfs: server 10.0.0.152 not responding, still trying > ... > > Only very seldom the rootfs can be mounted successfully to the prompt. > > I'm using latest kernel.org for this (git ID d2b4a646 also tested with > v3.10 release). This is with DT-enabled booting and without-DT (same > problem). I also tested some older Linux kernel versions and it fails > there as well. Only v3.2.40 seems to be able to mount this rootfs via > NFS reliably (approx. 10 times success). I can't really tell at the moment where the problem is. Did you compile in all the necessary drivers required for NFS booting? In the beagle case that would mean NOP_USB_XCEIV, USB_EHCI_HCD, USB_EHCI_HCD_OMAP and the smsc95xx driver. If you can paste your full kernel boot log we can check if all these show up before the kernel tries to look up for the NFS server. > > Is this a known issue on the Beagleboard? Do you have any ideas what > might cause such an issue (unreliable USB connection, hangup of NFS > mounting)? Any hints/links appretiated. > I have been too lazy to setup NFS :). But I will give it a shot soon to see what's going wrong. cheers, -roger -- 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.html
Re: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
Roger, On 04/15/2013 01:20 PM, Roger Quadros wrote: > On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is > reversed when compared to other revisions i.e. it is > active high instead of active low. > > Use the beagle_config.usb_pwr_level flag correctly so that > the power regulator can be configured at runtime. > > Signed-off-by: Roger Quadros I'm currently trying to use an SMSC95xx USB ethernet adapter on the OMAP3 Beagleboard (old one "Beagle Rev C1/C2/C3") via the OMAP EHCI controller. And am testing this by trying to mount the rootfs via NFS. What I see is that the NFS mounting stalls/hangs most of the time quite early in the mount process: [6.425689] VFS: Mounted root (nfs filesystem) on device 0:12. [6.435485] devtmpfs: mounted [6.440002] Freeing unused kernel memory: 384K (c077a000 - c07da000) INIT: version 2.88 booting Starting udev [ 188.311309] nfs: server 10.0.0.152 not responding, still trying [ 188.317687] nfs: server 10.0.0.152 not responding, still trying ... Only very seldom the rootfs can be mounted successfully to the prompt. I'm using latest kernel.org for this (git ID d2b4a646 also tested with v3.10 release). This is with DT-enabled booting and without-DT (same problem). I also tested some older Linux kernel versions and it fails there as well. Only v3.2.40 seems to be able to mount this rootfs via NFS reliably (approx. 10 times success). Is this a known issue on the Beagleboard? Do you have any ideas what might cause such an issue (unreliable USB connection, hangup of NFS mounting)? Any hints/links appretiated. Thanks, Stefan -- 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.html
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On 07/09/2013 01:51 AM, Felipe Balbi wrote:
On Mon, Jul 08, 2013 at 03:33:30PM -0500, Nishanth Menon wrote:
+static int dra7xxx_qspi_start_transfer_one(struct spi_master *master,
+ struct spi_message *m)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+ struct spi_device *spi = m->spi;
+ struct spi_transfer *t;
+ int status = 0;
+ int frame_length;
+
+ /* setup device control reg */
+ qspi->dc = 0;
+
+ if (spi->mode & SPI_CPHA)
+ qspi->dc |= QSPI_CKPHA(spi->chip_select);
+ if (spi->mode & SPI_CPOL)
+ qspi->dc |= QSPI_CKPOL(spi->chip_select);
+ if (spi->mode & SPI_CS_HIGH)
+ qspi->dc |= QSPI_CSPOL(spi->chip_select);
+
+ frame_length = DIV_ROUND_UP(m->frame_length * spi->bits_per_word,
+ spi->bits_per_word);
+
+ frame_length = clamp(frame_length, 0, QSPI_FRAME_MAX);
+
+ /* setup command reg */
+ qspi->cmd = 0;
+ qspi->cmd |= QSPI_EN_CS(spi->chip_select);
+ qspi->cmd |= QSPI_FLEN(frame_length);
+
how does one ensure pm runtime has not disabled clocks in
background? e.g. long latency between transfers.
because pm_runtime_put*() has not been called ?
There's no way clocks will be gated until we kick the pm autosuspend
timer, which is only done when the transfer is finished.
with this input and looking closer, I think I see what you are saying now:
dra7xxx_qspi_prepare_xfer -> does a pm_runtime_get_sync
dra7xxx_qspi_unprepare_xfer -> does a pm_runtime_mark_last_busy,
pm_runtime_put_autosuspend
In between these calls, you have the remaining xfer calls going on.
we are assuming here that autosuspend timeout should be greater than the
time to complete the worst case transfer.
Is that a valid assumption? would it not be better to mark_busy at other
points? my thought is that considering a threaded isr, if by any chance
you have a latency > autosuspend due to premption or some un-forseen
event, this could crash badly, no? mark_busy will atleast ensure that
runtime timer is reset. yep, we can also argue to converse, with a
autosuspend delay set to appropriate value, we should not see this
issue. pm_runtime_mark_last_busy() may be executed from interrupt
context as well. At least going with "marks the last time of the
device's busy state" we dont seem to mark them at all potential points?
ofcourse we can debate about how granular the marking should be, IMHO,
though, I like autosuspend, however, I like autosuspend as a way to
reduce transfer-to-transfer latency to re-enable the clocks. I however
am a bit gittery about autosuspend kicking inside required time
boundaries (especially considering the delay is upto user of the system).
Just my 2 cents.
[...]
+ qspi->base = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(qspi->base)) {
+ ret = -ENOMEM;
+ goto free_master;
+ }
why not use devm_request_and_ioremap? Lock that region down so that no
two drivers can manage the same region?
read devm_ioremap_resource() and look at the git log for all the
numerous drivers which were converted to devm_ioremap_resource() to find
the reason.
my bad. fair enough.
--
Regards,
Nishanth Menon
--
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.html
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On 07/09/2013 05:05 AM, Mark Brown wrote: On Tue, Jul 09, 2013 at 09:51:43AM +0300, Felipe Balbi wrote: Looks like a case to use regmap? Dumb q: why cant we use regmap_spi? worst case, you should be able to read regmap-spi and you'll see why it can't be used in this case. regmap-spi is for SPI clients who want to read their register map through SPI commands. This is a driver for the SPI master which has its registers memory mapped. Indeed, regmap-spi would be a client of this driver. Though there is regmap-mmio which may be helpful, on the other hand it's relatively heavyweight and SPI can be a bit performance sensitive so perhaps it's not awesome here. Russell did mention the idea of some helpers along a similar style though, they may be a good idea but nobody wrote them yet. Fair enough. I am starting to see at least a second driver (internally for DRA7 IRQ/DMA crossbar) doing the same handling for different bit sized registers. maybe now is the time for us to create a lighter version of mmio. mmio at least the last I looked uses spinlocks and is fairly fast. But, I agree, when the client of regmap uses locks to protect operations of their own, regmap might be a bit of an overhead. that said, replicating regmap logic in the driver looks a bit weird and might allow the basis for other drivers to do the same as well as some users of mmio would consider themselves performance sensitive :(. -- Regards, Nishanth Menon -- 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.html
Re: [PATCH 1/1] OMAPDSS: Add sil9022 driver
On Tue, Jul 9, 2013 at 12:56 PM, Sathya Prakash wrote: > Hi, > > > On Tuesday 09 July 2013 03:07 PM, Yegor Yefremov wrote: >> >> On Tue, Jul 9, 2013 at 11:07 AM, Sathya Prakash M R >> wrote: >>> >>> From: Srinivas Pulukuru >>> >>> Add driver for SIL9022 DPI-to-HDMI chip. >>> >>> Signed-off-by: Srinivas Pulukuru >>> [sath...@ti.com: Ported the driver from 2.6.32 based internal >>> kernel to v3.10 kernel] >>> Signed-off-by: Sathya Prakash M R >>> --- >>> This patch was tested using the legacy OMAP3630 based Zoom3 platform. >>> There is no DT support for Zoom , hence board file changes >>> made locally were used for validation purpose. >>> Further, DT support will be added for a newer SOC which uses >>> the sil9022 HDMI interface chip. >>> >>> drivers/video/omap2/displays/Kconfig |8 + >>> drivers/video/omap2/displays/Makefile|1 + >>> drivers/video/omap2/displays/panel-sil9022.c | 1274 >>> ++ >>> drivers/video/omap2/displays/panel-sil9022.h | 527 +++ >>> 4 files changed, 1810 insertions(+) >>> create mode 100644 drivers/video/omap2/displays/panel-sil9022.c >>> create mode 100644 drivers/video/omap2/displays/panel-sil9022.h >> >> What about making this driver more general. We've tested this HDMI >> chip on am335x and there are also Freescal based devices using this >> chip (http://www.genesi-tech.com/products/efika and kernel repo >> http://github.com/genesi/linux-legacy). > > Currently the panel driver is tied to the OMAPDSS and hence making > this driver more generic is a difficult job. > But the Common Display Framework (CDF) will surely help us in future > to get drivers like this easy to port across different platforms. > In the future, will make this driver part of CDF to help in making it more > general. O.K. Yegor -- 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.html
Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Hi, On Tue, Jul 09, 2013 at 05:22:43PM +0530, George Cherian wrote: > >>>Another thing: am437x has 4 instances of this IP, why are you adding > >>>only one ? > >>AM437x has got only 2 instances. I have verified only one on HAPS so > >>adding only one. > >weird, on my TRM I see for dwc3 but 2 PHYs. > > Please confirm whether you are looking at am437x TRM or dra7x TRM? > dra7x has 4 dwc3 and 2 internal phys and 2 external phys guilty as charged :-) > >>>And why aren't you pasing the PHY nodes here ? The device > >>>won't work without its PHYs. > >>Yes true, again in HAPS I didnt have any PHY configuration to be done. > >alright, but we should still pass the PHY right ? once silicon comes, > >we want this to work without any further changers. > > okay will add phy nodes and 2 instances of dwc3. thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 1/2] USB: PHY: Make PHY driver selection possible by controller drivers
On 07/09/2013 03:02 PM, Felipe Balbi wrote: > On Tue, Jul 09, 2013 at 03:01:14PM +0300, Roger Quadros wrote: >> On 07/09/2013 02:29 PM, Felipe Balbi wrote: >>> On Fri, Jun 14, 2013 at 12:51:41PM +0300, Roger Quadros wrote: Convert PHY Drivers from menuconfig to menu so that the PHY drivers can be explicitely selected by the controller drivers. USB_PHY is no longer a user visible option. It is upto to the PHY drivers to select it if needed. This patch does so for the existing PHY drivers that use the USB_PHY library. Doing so moves the USB_PHY and PHY driver selection problem from the end user to the PHY and controller driver developer. e.g. Earlier, a controller driver (e.g. EHCI_OMAP) that needs to select a PHY driver (e.g. NOP_PHY) couldn't do so because the PHY driver depended on USB_PHY. Making the controller driver depend on USB_PHY has a negative effect i.e. it becomes invisible to the user till USB_PHY is enabled. Most end users will not familiar with this. With this patch, the end user just needs to select the controller driver needed for his/her platform without worrying about which PHY driver to select. Also update USB_EHCI_MSM, USB_LPC32XX and USB_OMAP to not depend on USB_PHY any more. They can safely select the necessary PHY drivers. CC: Pavankumar Kondeti CC: Roland Stigge Signed-off-by: Roger Quadros [USB_LPC32XX part] Acked-by: Roland Stigge Signed-off-by: Roger Quadros >>> >>> There is one problem (?) with this: phy-core.ko will never be a module. >>> If that's not a problem for anyone, I guess this is safe to apply. I'll >>> wait a little longer until merge window closes to give people some extra >>> time to shout. >>> >> >> Is phy-core already meant to be loaded as a module already? >> >> At least with the old phy.c I was getting the following build errors if it >> was built as >> a module >> >> arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': >> /work/linux-2.6/arch/arm/mach-omap2/usb-host.c:652: undefined reference to >> `usb_bind_phy' >> arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': >> /work/linux-2.6/arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference >> to `usb_bind_phy' >> arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': >> /work/linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c:554: undefined >> reference to `usb_bind_phy' >> arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': >> /work/linux-2.6/arch/arm/mach-omap2/board-devkit8000.c:596: undefined >> reference to `usb_bind_phy' >> arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': >> /work/linux-2.6/arch/arm/mach-omap2/board-ldp.c:379: undefined reference to >> `usb_bind_phy' >> >> If we are sure it can be built as a module then we could just change "config >> USB_PHY" to tristate >> instead of bool. > > good point, board-files are using some of our symbols. Then we can apply > your patches. I'll wait a bit longer, though. > Thanks :) and no problem with the wait. cheers, -roger -- 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.html
Re: [PATCH v3 1/2] USB: PHY: Make PHY driver selection possible by controller drivers
On Tue, Jul 09, 2013 at 03:01:14PM +0300, Roger Quadros wrote: > On 07/09/2013 02:29 PM, Felipe Balbi wrote: > > On Fri, Jun 14, 2013 at 12:51:41PM +0300, Roger Quadros wrote: > >> Convert PHY Drivers from menuconfig to menu so that the PHY drivers > >> can be explicitely selected by the controller drivers. > >> > >> USB_PHY is no longer a user visible option. It is upto to the PHY > >> drivers to select it if needed. This patch does so for the existing > >> PHY drivers that use the USB_PHY library. > >> > >> Doing so moves the USB_PHY and PHY driver selection problem from the > >> end user to the PHY and controller driver developer. > >> > >> e.g. > >> > >> Earlier, a controller driver (e.g. EHCI_OMAP) that needs to select > >> a PHY driver (e.g. NOP_PHY) couldn't do so because the PHY driver > >> depended on USB_PHY. Making the controller driver depend on USB_PHY > >> has a negative effect i.e. it becomes invisible to the user till > >> USB_PHY is enabled. Most end users will not familiar with this. > >> > >> With this patch, the end user just needs to select the controller driver > >> needed for his/her platform without worrying about which PHY driver to > >> select. > >> > >> Also update USB_EHCI_MSM, USB_LPC32XX and USB_OMAP to not depend > >> on USB_PHY any more. They can safely select the necessary PHY drivers. > >> > >> CC: Pavankumar Kondeti > >> CC: Roland Stigge > >> Signed-off-by: Roger Quadros > >> [USB_LPC32XX part] Acked-by: Roland Stigge > >> > >> Signed-off-by: Roger Quadros > > > > There is one problem (?) with this: phy-core.ko will never be a module. > > If that's not a problem for anyone, I guess this is safe to apply. I'll > > wait a little longer until merge window closes to give people some extra > > time to shout. > > > > Is phy-core already meant to be loaded as a module already? > > At least with the old phy.c I was getting the following build errors if it > was built as > a module > > arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': > /work/linux-2.6/arch/arm/mach-omap2/usb-host.c:652: undefined reference to > `usb_bind_phy' > arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': > /work/linux-2.6/arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference > to `usb_bind_phy' > arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': > /work/linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c:554: undefined > reference to `usb_bind_phy' > arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': > /work/linux-2.6/arch/arm/mach-omap2/board-devkit8000.c:596: undefined > reference to `usb_bind_phy' > arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': > /work/linux-2.6/arch/arm/mach-omap2/board-ldp.c:379: undefined reference to > `usb_bind_phy' > > If we are sure it can be built as a module then we could just change "config > USB_PHY" to tristate > instead of bool. good point, board-files are using some of our symbols. Then we can apply your patches. I'll wait a bit longer, though. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 1/2] USB: PHY: Make PHY driver selection possible by controller drivers
On 07/09/2013 02:29 PM, Felipe Balbi wrote: > On Fri, Jun 14, 2013 at 12:51:41PM +0300, Roger Quadros wrote: >> Convert PHY Drivers from menuconfig to menu so that the PHY drivers >> can be explicitely selected by the controller drivers. >> >> USB_PHY is no longer a user visible option. It is upto to the PHY >> drivers to select it if needed. This patch does so for the existing >> PHY drivers that use the USB_PHY library. >> >> Doing so moves the USB_PHY and PHY driver selection problem from the >> end user to the PHY and controller driver developer. >> >> e.g. >> >> Earlier, a controller driver (e.g. EHCI_OMAP) that needs to select >> a PHY driver (e.g. NOP_PHY) couldn't do so because the PHY driver >> depended on USB_PHY. Making the controller driver depend on USB_PHY >> has a negative effect i.e. it becomes invisible to the user till >> USB_PHY is enabled. Most end users will not familiar with this. >> >> With this patch, the end user just needs to select the controller driver >> needed for his/her platform without worrying about which PHY driver to >> select. >> >> Also update USB_EHCI_MSM, USB_LPC32XX and USB_OMAP to not depend >> on USB_PHY any more. They can safely select the necessary PHY drivers. >> >> CC: Pavankumar Kondeti >> CC: Roland Stigge >> Signed-off-by: Roger Quadros >> [USB_LPC32XX part] Acked-by: Roland Stigge >> >> Signed-off-by: Roger Quadros > > There is one problem (?) with this: phy-core.ko will never be a module. > If that's not a problem for anyone, I guess this is safe to apply. I'll > wait a little longer until merge window closes to give people some extra > time to shout. > Is phy-core already meant to be loaded as a module already? At least with the old phy.c I was getting the following build errors if it was built as a module arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': /work/linux-2.6/arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': /work/linux-2.6/arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': /work/linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': /work/linux-2.6/arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': /work/linux-2.6/arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy' If we are sure it can be built as a module then we could just change "config USB_PHY" to tristate instead of bool. cheers, -roger -- 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.html
Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
On 7/9/2013 4:57 PM, Felipe Balbi wrote: Hi, On Tue, Jul 09, 2013 at 04:51:35PM +0530, George Cherian wrote: + compatible = "snps,dwc3"; + reg = <0x4839 0xcfff>; weird size, shouldn't this be 0xd000 then the size would be exactly 52KiB okay btw, the reason here is that when you call devm_ioremap_resource(), that will call resource_size() which does: size = res->end - res->start - 1; so you need this extra 1 on the size when passing it via DT. agreed. Another thing: am437x has 4 instances of this IP, why are you adding only one ? AM437x has got only 2 instances. I have verified only one on HAPS so adding only one. weird, on my TRM I see for dwc3 but 2 PHYs. Please confirm whether you are looking at am437x TRM or dra7x TRM? dra7x has 4 dwc3 and 2 internal phys and 2 external phys And why aren't you pasing the PHY nodes here ? The device won't work without its PHYs. Yes true, again in HAPS I didnt have any PHY configuration to be done. alright, but we should still pass the PHY right ? once silicon comes, we want this to work without any further changers. okay will add phy nodes and 2 instances of dwc3. -- -George -- 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.html
Re: [PATCH] jacinto6 : usb3_phy: Updated dpll M,N values.
On 07/08/2013 05:33 PM, Ruchika Kharwar wrote: > > On 07/08/2013 02:28 AM, Felipe Balbi wrote: >> On Fri, Jun 21, 2013 at 10:46:10AM -0500, Ruchika Kharwar wrote: >>> Addition of the M and N recommended values for the USB3 PHY DPLL. >>> Sysclk for DRA7xx is 20MHz. >>> This yields: >>> Clk = 20MHz * M/(N+1) = 20MHz * 1000 /(7+1) = 2.5 Ghz >>> >>> Signed-off-by: Nikhil Devshatwar >>> Signed-off-by: Ruchika Kharwar >> this won't apply since you had already sent me another version. Please >> send in a fix up patch if that's wrong. >> > I already did .. :-) > Sent 07/04/2013 FYI, I've just sent a better version to fix the root of the problem, i.e. use lookup table instead of index based lookup. That should avoid such problems in the future. cheers, -roger -- 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.html
Re: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
* Rajendra Nayak [130709 03:21]:
> On Tuesday 09 July 2013 02:01 PM, Tony Lindgren wrote:
> > * Rajendra Nayak [130709 00:39]:
> >> From: Ambresh K
> >
> >> --- /dev/null
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > ...
> >
> >> +/* dma_system */
> >> +static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
> >> + { .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
> >> + { .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
> >> + { .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
> >> + { .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
> >> + { .irq = -1 }
> >> +};
> >
> > I think these should no longer be needed?
>
> These are needed only for dma because mach-omap2/dma.c still creates
> devices from hmwod and which are used by plat/dma.c.
> These irqs for sdma exist even in the cleaned up omap4 and omap5 hmwod files.
> I'll try and get rid of that dependency of plat/dma on mach/dma to create
> devices.
OK great.
> > In general, we must move the hwmod stuff to drivers/bus and start
> > parsing the data from device tree along the lines Tero is doing
> > for the clock data.
>
> We already have irq/dma and iospace moved to DT (some iospace info still
> exists because of non-DT drivers). With Teros patches to move clock data we
> should be able to pass the main_clk and all interface level clock info too
> from DT.
OK.
Tony
--
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.html
Re: [PATCH 0/5] Add phy support for AM335X platform using Generic PHy framework
Hi, On Tuesday 09 July 2013 11:10 AM, George Cherian wrote: > On 7/9/2013 1:14 AM, Sebastian Andrzej Siewior wrote: >> On 07/08/2013 12:43 PM, George Cherian wrote: >>> This patch series adds phy support for AM335X platform. >>> This patch series is based on Generic PHY framework [1]. >>> >>> >>> This series has >>> - adds dual musb instances support for am335x platform (just for >>> testing) >>> - adds phy-am-usb driver used in AM platforms >>> - adds dt bindings for the phys >>> - removes usb-phy and replaced with generic phy apis in glue layer >> No, I don't like this all. You did the one thing I tried to avoid while >> posting my quick-and-dirty phy driver recently: You duplicated a lot of >> code which can be served by the nop driver and added only power >> on/power off callbacks. > I wanted to add phy wakeup control also, but currently phy_ops dont have an > op > for wkup_ctrl > Kishon, Can we add one? Since this should be a capability of the PHY, can't we have wkup_ctrl always enabled if the PHY has such a capability? or if it needs more user control, should we implement a sysfs entry to enable wakeup? Thanks Kishon -- 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.html
Re: [PATCH v3 4/4] USB: OMAP1: Tahvo USB transceiver driver
Hi,
On Mon, Jul 08, 2013 at 10:44:02PM +0300, Aaro Koskinen wrote:
> > > +static void tahvo_usb_become_host(struct tahvo_usb *tu)
> > > +{
> > > + struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
> > > +
> > > + extcon_set_cable_state(&tu->extcon, "USB-HOST", true);
> > > +
> > > + /* Power up the transceiver in USB host mode */
> > > + retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
> > > +USBR_MASTER_SW2 | USBR_MASTER_SW1);
> > > + tu->phy.state = OTG_STATE_A_IDLE;
> > > +
> > > + check_vbus_state(tu);
> > > +}
> > > +
> > > +static void tahvo_usb_stop_host(struct tahvo_usb *tu)
> > > +{
> > > + tu->phy.state = OTG_STATE_A_IDLE;
> >
> > shouldn't you undo tahvo_usb_become_host() here ? I mean, set the
> > transceiver to SLAVE ?
>
> tahvo_usb_become_peripheral() (or power_off) is always called after this
> function. Actually, these stop functions can be eliminated altogether
> as they are only called from a single place...
alright, I guess GCC is already inlining them anyway, your choice.
> > > +static int tahvo_usb_set_host(struct usb_otg *otg, struct usb_bus *host)
> > > +{
> > > + struct tahvo_usb *tu = container_of(otg->phy, struct tahvo_usb, phy);
> > > +
> > > + dev_dbg(&tu->pt_dev->dev, "%s %p\n", __func__, host);
> > > +
> > > + if (otg == NULL)
> > > + return -ENODEV;
> > > +
> > > + mutex_lock(&tu->serialize);
> > > +
> > > + if (host == NULL) {
> > > + if (tu->tahvo_mode == TAHVO_MODE_HOST)
> > > + tahvo_usb_power_off(tu);
> > > + otg->host = NULL;
> > > + mutex_unlock(&tu->serialize);
> > > + return 0;
> > > + }
> > > +
> > > + if (tu->tahvo_mode == TAHVO_MODE_HOST) {
> > > + otg->host = NULL;
> > > + tahvo_usb_become_host(tu);
> > > + }
> > > +
> > > + otg->host = host;
> > > +
> > > + mutex_unlock(&tu->serialize);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int tahvo_usb_set_peripheral(struct usb_otg *otg,
> > > + struct usb_gadget *gadget)
> >
> > I want to get rid of the extra 'gadget' and 'host' parameters on
> > ->set_host() and ->set_peripheral(). Nobody really uses them other than:
> >
> > my_phy->phy.otg->{gadget,host} = {gadget,host};
> >
> > For that, I need all other PHYs to stop relying on those parameters and
> > I'll cook patches for that for v3.12 merge window.
>
> How will the PHY know if there is a host/gadget driver present? I guess
> I will need to wait for those patches...
It won't. We're assuming that if the link asks to become a host, it
should already know that there is a host side available :-)
> > > +static int tahvo_usb_probe(struct platform_device *pdev)
> > > +{
> > > + struct retu_dev *rdev = dev_get_drvdata(pdev->dev.parent);
> > > + struct tahvo_usb *tu;
> > > + int ret;
> > > +
> > > + tu = devm_kzalloc(&pdev->dev, sizeof(*tu), GFP_KERNEL);
> > > + if (!tu)
> > > + return -ENOMEM;
> > > +
> > > + tu->phy.otg = devm_kzalloc(&pdev->dev, sizeof(*tu->phy.otg),
> > > +GFP_KERNEL);
> > > + if (!tu->phy.otg)
> > > + return -ENOMEM;
> > > +
> > > + tu->pt_dev = pdev;
> > > +
> > > + /* Default mode */
> > > +#ifdef CONFIG_TAHVO_USB_HOST_BY_DEFAULT
> > > + tu->tahvo_mode = TAHVO_MODE_HOST;
> > > +#else
> > > + tu->tahvo_mode = TAHVO_MODE_PERIPHERAL;
> > > +#endif
> >
> > should you call become_host()/become_peripheral() here ?
>
> Not needed. Once the PHY is registered, the framework will call set_host /
> set_peripheral and the HW gets set to correct state.
ok good, thanks
> > /Could also use devm_request_threaded_irq()
>
> Does not really help much, since the IRQ has to be freed manually anyway
> (to ensure it's disabled before usb_remove_phy(); also looks like it's
> currently enabled too early...).
you miss a free() in the error path. Switching to
devm_request_threaded_irq() would save you the trouble of having to call
that explicitly.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 1/2] USB: PHY: Make PHY driver selection possible by controller drivers
On Fri, Jun 14, 2013 at 12:51:41PM +0300, Roger Quadros wrote: > Convert PHY Drivers from menuconfig to menu so that the PHY drivers > can be explicitely selected by the controller drivers. > > USB_PHY is no longer a user visible option. It is upto to the PHY > drivers to select it if needed. This patch does so for the existing > PHY drivers that use the USB_PHY library. > > Doing so moves the USB_PHY and PHY driver selection problem from the > end user to the PHY and controller driver developer. > > e.g. > > Earlier, a controller driver (e.g. EHCI_OMAP) that needs to select > a PHY driver (e.g. NOP_PHY) couldn't do so because the PHY driver > depended on USB_PHY. Making the controller driver depend on USB_PHY > has a negative effect i.e. it becomes invisible to the user till > USB_PHY is enabled. Most end users will not familiar with this. > > With this patch, the end user just needs to select the controller driver > needed for his/her platform without worrying about which PHY driver to > select. > > Also update USB_EHCI_MSM, USB_LPC32XX and USB_OMAP to not depend > on USB_PHY any more. They can safely select the necessary PHY drivers. > > CC: Pavankumar Kondeti > CC: Roland Stigge > Signed-off-by: Roger Quadros > [USB_LPC32XX part] Acked-by: Roland Stigge > > Signed-off-by: Roger Quadros There is one problem (?) with this: phy-core.ko will never be a module. If that's not a problem for anyone, I guess this is safe to apply. I'll wait a little longer until merge window closes to give people some extra time to shout. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Hi, On Tue, Jul 09, 2013 at 04:51:35PM +0530, George Cherian wrote: > >>+ compatible = "snps,dwc3"; > >>+ reg = <0x4839 0xcfff>; > >weird size, shouldn't this be 0xd000 then the size would be exactly > >52KiB > > okay btw, the reason here is that when you call devm_ioremap_resource(), that will call resource_size() which does: size = res->end - res->start - 1; so you need this extra 1 on the size when passing it via DT. > >Another thing: am437x has 4 instances of this IP, why are you adding > >only one ? > > AM437x has got only 2 instances. I have verified only one on HAPS so > adding only one. weird, on my TRM I see for dwc3 but 2 PHYs. > >And why aren't you pasing the PHY nodes here ? The device > >won't work without its PHYs. > > Yes true, again in HAPS I didnt have any PHY configuration to be done. alright, but we should still pass the PHY right ? once silicon comes, we want this to work without any further changers. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
On 7/9/2013 3:50 PM, Felipe Balbi wrote:
On Tue, Jul 09, 2013 at 02:47:26PM +0530, George Cherian wrote:
Adds device node for HS USB Host module for AM437x
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
the patch revision changes don't need to go to the commit log,
they should be placed after the tearline (---) and before the diffstat.
Signed-off-by: George Cherian
---
arch/arm/boot/dts/am4372.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
compatible =
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+ usb_otg_hs1: am4372_dwc3@4838 {
dtsi should always have status = "disabled"; no ?
+ compatible = "ti,am437x-dwc3";
+ reg = <0x4838 0x1ff>;
weird size, shouldn't this be 0x200 ?
okay
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ utmi-mode = <1>;
+ ranges;
+
+ dwc3@4839 {
dtsi should always have status = "disabled"; no ?
okay
+ compatible = "snps,dwc3";
+ reg = <0x4839 0xcfff>;
weird size, shouldn't this be 0xd000 then the size would be exactly
52KiB
okay
+ interrupts = ;
+ };
+
+ };
+
there two trailing tabs on this line.
Another thing: am437x has 4 instances of this IP, why are you adding
only one ?
AM437x has got only 2 instances. I have verified only one on HAPS so
adding only one.
And why aren't you pasing the PHY nodes here ? The device
won't work without its PHYs.
Yes true, again in HAPS I didnt have any PHY configuration to be done.
--
-George
--
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.html
Re: [PATCH 1/1] OMAPDSS: Add sil9022 driver
Hi, On Tuesday 09 July 2013 03:07 PM, Yegor Yefremov wrote: On Tue, Jul 9, 2013 at 11:07 AM, Sathya Prakash M R wrote: From: Srinivas Pulukuru Add driver for SIL9022 DPI-to-HDMI chip. Signed-off-by: Srinivas Pulukuru [sath...@ti.com: Ported the driver from 2.6.32 based internal kernel to v3.10 kernel] Signed-off-by: Sathya Prakash M R --- This patch was tested using the legacy OMAP3630 based Zoom3 platform. There is no DT support for Zoom , hence board file changes made locally were used for validation purpose. Further, DT support will be added for a newer SOC which uses the sil9022 HDMI interface chip. drivers/video/omap2/displays/Kconfig |8 + drivers/video/omap2/displays/Makefile|1 + drivers/video/omap2/displays/panel-sil9022.c | 1274 ++ drivers/video/omap2/displays/panel-sil9022.h | 527 +++ 4 files changed, 1810 insertions(+) create mode 100644 drivers/video/omap2/displays/panel-sil9022.c create mode 100644 drivers/video/omap2/displays/panel-sil9022.h What about making this driver more general. We've tested this HDMI chip on am335x and there are also Freescal based devices using this chip (http://www.genesi-tech.com/products/efika and kernel repo http://github.com/genesi/linux-legacy). Currently the panel driver is tied to the OMAPDSS and hence making this driver more generic is a difficult job. But the Common Display Framework (CDF) will surely help us in future to get drivers like this easy to port across different platforms. In the future, will make this driver part of CDF to help in making it more general. Regards, Sathya Prakash M R Yegor -- 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.html
RE: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Hi George,
On Tue, Jul 09, 2013 at 14:47:26, Cherian, George wrote:
> + usb_otg_hs1: am4372_dwc3@4838 {
Wouldn't "usb" a better node name ?
> + compatible = "ti,am437x-dwc3";
Usage of wild card is discouraged per DT documentation.
Regards
Afzal
--
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.html
Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
On Tue, Jul 09, 2013 at 02:47:26PM +0530, George Cherian wrote:
> Adds device node for HS USB Host module for AM437x
>
> changes from v1
>
> renamed synopsis to snps
> removed flag tx-fifo-resize
the patch revision changes don't need to go to the commit log,
they should be placed after the tearline (---) and before the diffstat.
> Signed-off-by: George Cherian
> ---
> arch/arm/boot/dts/am4372.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index ddc1df7..c9e0da8 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -64,5 +64,23 @@
> compatible =
> "ti,am4372-counter32k","ti,omap-counter32k";
> reg = <0x44e86000 0x40>;
> };
> +
> + usb_otg_hs1: am4372_dwc3@4838 {
dtsi should always have status = "disabled"; no ?
> + compatible = "ti,am437x-dwc3";
> + reg = <0x4838 0x1ff>;
weird size, shouldn't this be 0x200 ?
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + utmi-mode = <1>;
> + ranges;
> +
> + dwc3@4839 {
dtsi should always have status = "disabled"; no ?
> + compatible = "snps,dwc3";
> + reg = <0x4839 0xcfff>;
weird size, shouldn't this be 0xd000 then the size would be exactly
52KiB
> + interrupts = ;
> + };
> +
> + };
> +
there two trailing tabs on this line.
Another thing: am437x has 4 instances of this IP, why are you adding
only one ? And why aren't you pasing the PHY nodes here ? The device
won't work without its PHYs.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
On Tuesday 09 July 2013 02:01 PM, Tony Lindgren wrote:
> * Rajendra Nayak [130709 00:39]:
>> From: Ambresh K
>
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> ...
>
>> +/* dma_system */
>> +static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
>> +{ .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
>> +{ .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
>> +{ .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
>> +{ .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
>> +{ .irq = -1 }
>> +};
>
> I think these should no longer be needed?
These are needed only for dma because mach-omap2/dma.c still creates
devices from hmwod and which are used by plat/dma.c.
These irqs for sdma exist even in the cleaned up omap4 and omap5 hmwod files.
I'll try and get rid of that dependency of plat/dma on mach/dma to create
devices.
>
> In general, we must move the hwmod stuff to drivers/bus and start
> parsing the data from device tree along the lines Tero is doing
> for the clock data.
We already have irq/dma and iospace moved to DT (some iospace info still
exists because of non-DT drivers). With Teros patches to move clock data we
should be able to pass the main_clk and all interface level clock info too
from DT.
>
> What's the plan for doing that?
>
> Regards,
>
> Tony
>
--
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.html
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On Tue, Jul 09, 2013 at 09:51:43AM +0300, Felipe Balbi wrote: > > Looks like a case to use regmap? > > Dumb q: why cant we use regmap_spi? worst case, you should be able to > read regmap-spi and you'll see why it can't be used in this case. > regmap-spi is for SPI clients who want to read their register map > through SPI commands. This is a driver for the SPI master which has its > registers memory mapped. Indeed, regmap-spi would be a client of this driver. Though there is regmap-mmio which may be helpful, on the other hand it's relatively heavyweight and SPI can be a bit performance sensitive so perhaps it's not awesome here. Russell did mention the idea of some helpers along a similar style though, they may be a good idea but nobody wrote them yet. signature.asc Description: Digital signature
Re: [PATCH 1/1] OMAPDSS: Add sil9022 driver
On Tue, Jul 9, 2013 at 11:07 AM, Sathya Prakash M R wrote: > From: Srinivas Pulukuru > > Add driver for SIL9022 DPI-to-HDMI chip. > > Signed-off-by: Srinivas Pulukuru > [sath...@ti.com: Ported the driver from 2.6.32 based internal > kernel to v3.10 kernel] > Signed-off-by: Sathya Prakash M R > --- > This patch was tested using the legacy OMAP3630 based Zoom3 platform. > There is no DT support for Zoom , hence board file changes > made locally were used for validation purpose. > Further, DT support will be added for a newer SOC which uses > the sil9022 HDMI interface chip. > > drivers/video/omap2/displays/Kconfig |8 + > drivers/video/omap2/displays/Makefile|1 + > drivers/video/omap2/displays/panel-sil9022.c | 1274 > ++ > drivers/video/omap2/displays/panel-sil9022.h | 527 +++ > 4 files changed, 1810 insertions(+) > create mode 100644 drivers/video/omap2/displays/panel-sil9022.c > create mode 100644 drivers/video/omap2/displays/panel-sil9022.h What about making this driver more general. We've tested this HDMI chip on am335x and there are also Freescal based devices using this chip (http://www.genesi-tech.com/products/efika and kernel repo http://github.com/genesi/linux-legacy). Yegor -- 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.html
[PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Adds device node for HS USB Host module for AM437x
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
Signed-off-by: George Cherian
---
arch/arm/boot/dts/am4372.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
compatible =
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+ usb_otg_hs1: am4372_dwc3@4838 {
+ compatible = "ti,am437x-dwc3";
+ reg = <0x4838 0x1ff>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ utmi-mode = <1>;
+ ranges;
+
+ dwc3@4839 {
+ compatible = "snps,dwc3";
+ reg = <0x4839 0xcfff>;
+ interrupts = ;
+ };
+
+ };
+
};
};
--
1.8.1.4
--
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.html
[PATCH 1/1] OMAPDSS: Add sil9022 driver
From: Srinivas Pulukuru
Add driver for SIL9022 DPI-to-HDMI chip.
Signed-off-by: Srinivas Pulukuru
[sath...@ti.com: Ported the driver from 2.6.32 based internal
kernel to v3.10 kernel]
Signed-off-by: Sathya Prakash M R
---
This patch was tested using the legacy OMAP3630 based Zoom3 platform.
There is no DT support for Zoom , hence board file changes
made locally were used for validation purpose.
Further, DT support will be added for a newer SOC which uses
the sil9022 HDMI interface chip.
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile|1 +
drivers/video/omap2/displays/panel-sil9022.c | 1274 ++
drivers/video/omap2/displays/panel-sil9022.h | 527 +++
4 files changed, 1810 insertions(+)
create mode 100644 drivers/video/omap2/displays/panel-sil9022.c
create mode 100644 drivers/video/omap2/displays/panel-sil9022.h
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index c3853c9..53d8bb7 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -39,6 +39,14 @@ config PANEL_NEC_NL8048HL11_01B
This NEC NL8048HL11-01B panel is TFT LCD
used in the Zoom2/3/3630 sdp boards.
+config PANEL_SIL9022
+ tristate "HDMI interface"
+depends on OMAP2_DSS_DPI
+ depends on I2C
+ help
+ Driver for SIL9022 DPI-to-HDMI chip
+ Driver uses i2c to read EDID information.
+
config PANEL_PICODLP
tristate "TI PICO DLP mini-projector"
depends on OMAP2_DSS_DPI && I2C
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 58a5176..34cfa8e 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PANEL_TFP410) += panel-tfp410.o
obj-$(CONFIG_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-nl8048hl11-01b.o
+obj-$(CONFIG_PANEL_SIL9022) += panel-sil9022.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
obj-$(CONFIG_PANEL_PICODLP) += panel-picodlp.o
diff --git a/drivers/video/omap2/displays/panel-sil9022.c
b/drivers/video/omap2/displays/panel-sil9022.c
new file mode 100644
index 000..3b5cb17
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-sil9022.c
@@ -0,0 +1,1274 @@
+/*
+ * drivers/video/omap2/panel-sil9022.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * SIL9022 hdmi driver
+ * Owner: kiran Chitriki
+ *
+ */
+
+/***/
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include "panel-sil9022.h"
+
+u16 current_descriptor_addrs;
+
+static struct i2c_client *sil9022_client;
+
+static struct omap_video_timings omap_dss_hdmi_timings = {
+ .x_res = HDMI_XRES,
+ .y_res = HDMI_YRES,
+ .pixel_clock= HDMI_PIXCLOCK_MAX,
+ .hfp= 110,
+ .hbp= 220,
+ .hsw= 40,
+ .vfp= 5,
+ .vbp= 20,
+ .vsw= 5,
+ .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+};
+
+static struct hdmi_reg_data hdmi_tpi_audio_config_data[] = {
+ /* Transmitter is brought to Full operation when value of power
+* state register is 0x0 */
+ { HDMI_TPI_POWER_STATE_CTRL_REG, TPI_AVI_POWER_STATE_D0 },
+ /* TMDS output lines active. bit 3 1:TMDS inactive, 0: TMDS active */
+ { HDMI_SYS_CTRL_DATA_REG, 0x01 },
+ /*HDCP Enable - Disable */
+ { HDMI_TPI_HDCP_CONTROLDATA_REG, 0 },
+ /* I2S mode , Mute Enabled , PCM */
+ { HDMI_TPI_AUDIO_CONFIG_BYTE2_REG, TPI_AUDIO_INTERFACE_I2S |
+ TPI_AUDIO_MUTE_ENABLE |
+ TPI_AUDIO_CODING_PCM },
+ /* I2S Input configuration register */
+ { HDMI_TPI_I2S_INPUT_CONFIG_REG, TPI_I2S_SCK_EDGE_RISING |
+ TPI_I2S_MCLK_MULTIPLIER_256 |
+ TPI_I2S_WS_POLARITY_HIGH |
+ TPI_I2S_SD_JUSTIFY_LEFT |
+ TPI_I2S_SD_DIRECTION_MSB_FIRST |
+ TPI
Re: [PATCH 2/8] ARM: DRA7: Update SRAM details
* Rajendra Nayak [130709 00:34]:
> DRA7xx devices have 512K of SRAM for both secure and non-secure
> devices.
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: R Sricharan
> ---
> arch/arm/mach-omap2/sram.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
> index 4bd0968..67d4277 100644
> --- a/arch/arm/mach-omap2/sram.c
> +++ b/arch/arm/mach-omap2/sram.c
> @@ -38,6 +38,7 @@
> #define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
> #endif
> #define OMAP5_SRAM_PA0x4030
> +#define DRA7_SRAM_PA OMAP4_SRAM_PA
>
> #define SRAM_BOOTLOADER_SZ 0x00
>
> @@ -111,6 +112,9 @@ static void __init omap_detect_sram(void)
> } else if (soc_is_omap54xx()) {
> omap_sram_start = OMAP5_SRAM_PA;
> omap_sram_size = SZ_128K; /* 128KB */
> + } else if (soc_is_dra7xx()) {
> + omap_sram_start = DRA7_SRAM_PA;
> + omap_sram_size = SZ_512K; /* 512KB */
> } else {
> omap_sram_start = OMAP2_SRAM_PUB_PA;
> omap_sram_size = 0x800; /* 2K */
> @@ -131,6 +135,9 @@ static void __init omap_detect_sram(void)
> } else if (soc_is_omap54xx()) {
> omap_sram_start = OMAP5_SRAM_PA;
> omap_sram_size = SZ_128K; /* 128KB */
> + } else if (soc_is_dra7xx()) {
> + omap_sram_start = DRA7_SRAM_PA;
> + omap_sram_size = SZ_512K; /* 512KB */
> } else {
> omap_sram_start = OMAP2_SRAM_PA;
> if (cpu_is_omap242x())
This again reminds me that we should move omaps to use
drivers/misc/sram.c. Other than that, this set looks good
to me.
Regards,
Tony
--
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.html
Re: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
* Rajendra Nayak [130709 00:39]:
> From: Ambresh K
> --- /dev/null
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
...
> +/* dma_system */
> +static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
> + { .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
> + { .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
> + { .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
> + { .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
> + { .irq = -1 }
> +};
I think these should no longer be needed?
In general, we must move the hwmod stuff to drivers/bus and start
parsing the data from device tree along the lines Tero is doing
for the clock data.
What's the plan for doing that?
Regards,
Tony
--
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.html
Re: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
* Russell King - ARM Linux [130708 07:27]: > On Mon, Jul 08, 2013 at 02:34:11AM -0700, Tony Lindgren wrote: > > > > Hey the good news is that you've updated your build system to support > > also appended dtb images, thanks for doing that! > > It was far from trivial - there's many places in the build process > which do things quite differently depending on whether it's a DTB > build or not. Yes that's too bad. We can make it slightly easier to update from custom .config files by always building in support for board-generic.c. > It seems that - yet again - the mmc devices have swapped themselves. Hmm they also seem to swap depending if there's a card plugged in. > Also looks like the nonfunctional video stuff is even more nonfunctional > than usual: > > omapdss DSI error: can't get VDDS_DSI regulator > omapdss HDMI error: can't get VDDA_HDMI_DAC regulator Tomi? > ASoC looks dead too: > > omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered > omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517 Peter, I think you've had audio working with devicetree for at least a year or something? Regards, Tony -- 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.html
Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
Hi, On Tue, Jul 09, 2013 at 12:49:10PM +0530, Rajendra Nayak wrote: > Right, but calling serial_omap_restore_context() even when the context > is not lost, should not ideally cause an issue. > >>> > >>> it does in one condition. If context hasn't been saved before. And that > >>> can happen in the case of wrong pm runtime status for that device. > >>> > >>> Imagine the device is marked as suspended even though it's fully enabled > >>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case > >>> your context structure is all zeroes (context has never been saved > >>> before) then when you call pm_runtime_get_sync() on probe() your > >>> ->runtime_resume() will get called, which will restore context, > >>> essentially undoing anything which was configured by u-boot. > >> > >> This could be a problem for drivers which do a save context in > >> ->runtime_suspend() > >> but from what I see with omap serial, there is no save context done as > >> part of > >> ->runtime_suspend. > > > > right, because context is "saved" in set_termios. probe() will get > > called much before set_termios() has a chance to run, right ? > > > > Same problem will trigger in that case. > > > > I still think patch below is necessary > > Right, I'll try some on those lines. Looks like a > pm_runtime_set_active() is done for the console in the non DT case in > omap_serial_init_port(). It seems to be missing in the DT case. yeah, based on conversation I had with Alan Stern a while back, pm_runtime_set_*() is best called by the underlying 'bus' and I tend to agree with him on that. Our HWMOD being our 'bus' (not really, but still), is the entity which knows if the device is powered or not and should make sure to call pm_runtime_set_*() for all devices. > Although I feel this should fix the issue we have right now, I wonder > if there could ever be a case with uart being suspended and having to > resume again before a set_termios? What I mean to ask is, if the omap > serial driver assuming a resume to happen only post a set_termios is > always valid. Meaning, probe() -> suspend() -> resume() ? I don't think that would ever happen. ->set_termios() would always get called and that's actually what triggers the resume. -- balbi signature.asc Description: Digital signature
[PATCH 02/12] ARM: DRA7: CM: Add DRA7XX register defines
From: Ambresh K Add the new defines for DRA7XX CM registers. Signed-off-by: Ambresh K Signed-off-by: Tero Kristo Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/cm1_7xx.h | 323 ++ arch/arm/mach-omap2/cm2_7xx.h | 512 + 2 files changed, 835 insertions(+) create mode 100644 arch/arm/mach-omap2/cm1_7xx.h create mode 100644 arch/arm/mach-omap2/cm2_7xx.h diff --git a/arch/arm/mach-omap2/cm1_7xx.h b/arch/arm/mach-omap2/cm1_7xx.h new file mode 100644 index 000..2aae8c2 --- /dev/null +++ b/arch/arm/mach-omap2/cm1_7xx.h @@ -0,0 +1,323 @@ +/* + * DRA7xx CM1 instance offset macros + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_CM1_7XX_H +#define __ARCH_ARM_MACH_OMAP2_CM1_7XX_H + +#include "cm_44xx_54xx.h" + +/* CM1 base address */ +#define DRA7XX_CM_CORE_AON_BASE0x4a005000 + +#define DRA7XX_CM_CORE_AON_REGADDR(inst, reg) \ + OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE + (inst) + (reg)) + +/* CM_CORE_AON instances */ +#define DRA7XX_CM_CORE_AON_OCP_SOCKET_INST 0x +#define DRA7XX_CM_CORE_AON_CKGEN_INST 0x0100 +#define DRA7XX_CM_CORE_AON_MPU_INST0x0300 +#define DRA7XX_CM_CORE_AON_DSP1_INST 0x0400 +#define DRA7XX_CM_CORE_AON_IPU_INST0x0500 +#define DRA7XX_CM_CORE_AON_DSP2_INST 0x0600 +#define DRA7XX_CM_CORE_AON_EVE1_INST 0x0640 +#define DRA7XX_CM_CORE_AON_EVE2_INST 0x0680 +#define DRA7XX_CM_CORE_AON_EVE3_INST 0x06c0 +#define DRA7XX_CM_CORE_AON_EVE4_INST 0x0700 +#define DRA7XX_CM_CORE_AON_RTC_INST0x0740 +#define DRA7XX_CM_CORE_AON_VPE_INST0x0760 +#define DRA7XX_CM_CORE_AON_RESTORE_INST0x0e00 +#define DRA7XX_CM_CORE_AON_INSTR_INST 0x0f00 + +/* CM_CORE_AON clockdomain register offsets (from instance start) */ +#define DRA7XX_CM_CORE_AON_MPU_MPU_CDOFFS 0x +#define DRA7XX_CM_CORE_AON_DSP1_DSP1_CDOFFS0x +#define DRA7XX_CM_CORE_AON_IPU_IPU1_CDOFFS 0x +#define DRA7XX_CM_CORE_AON_IPU_IPU_CDOFFS 0x0040 +#define DRA7XX_CM_CORE_AON_DSP2_DSP2_CDOFFS0x +#define DRA7XX_CM_CORE_AON_EVE1_EVE1_CDOFFS0x +#define DRA7XX_CM_CORE_AON_EVE2_EVE2_CDOFFS0x +#define DRA7XX_CM_CORE_AON_EVE3_EVE3_CDOFFS0x +#define DRA7XX_CM_CORE_AON_EVE4_EVE4_CDOFFS0x +#define DRA7XX_CM_CORE_AON_RTC_RTC_CDOFFS 0x +#define DRA7XX_CM_CORE_AON_VPE_VPE_CDOFFS 0x + +/* CM_CORE_AON */ + +/* CM_CORE_AON.OCP_SOCKET_CM_CORE_AON register offsets */ +#define DRA7XX_REVISION_CM_CORE_AON_OFFSET 0x +#define DRA7XX_CM_CM_CORE_AON_PROFILING_CLKCTRL_OFFSET 0x0040 +#define DRA7XX_CM_CM_CORE_AON_PROFILING_CLKCTRL DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_OCP_SOCKET_INST, 0x0040) +#define DRA7XX_CM_CORE_AON_DEBUG_OUT_OFFSET0x00ec +#define DRA7XX_CM_CORE_AON_DEBUG_CFG0_OFFSET 0x00f0 +#define DRA7XX_CM_CORE_AON_DEBUG_CFG1_OFFSET 0x00f4 +#define DRA7XX_CM_CORE_AON_DEBUG_CFG2_OFFSET 0x00f8 +#define DRA7XX_CM_CORE_AON_DEBUG_CFG3_OFFSET 0x00fc + +/* CM_CORE_AON.CKGEN_CM_CORE_AON register offsets */ +#define DRA7XX_CM_CLKSEL_CORE_OFFSET 0x +#define DRA7XX_CM_CLKSEL_CORE DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x) +#define DRA7XX_CM_CLKSEL_ABE_OFFSET0x0008 +#define DRA7XX_CM_CLKSEL_ABE DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0008) +#define DRA7XX_CM_DLL_CTRL_OFFSET 0x0010 +#define DRA7XX_CM_CLKMODE_DPLL_CORE_OFFSET 0x0020 +#define DRA7XX_CM_CLKMODE_DPLL_CORE DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0020) +#define DRA7XX_CM_IDLEST_DPLL_CORE_OFFSET 0x0024 +#define DRA7XX_CM_IDLEST_DPLL_CORE DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0024) +#define DRA7XX_CM_AUTOIDLE_DPLL_CORE_OFFSET0x0028 +#define DRA7XX_CM_AUTOIDLE_DPLL_CORE DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0028) +#define DRA7XX_CM_CLKSEL_DPLL_CORE_OFFSET 0x002c +#define DR
[PATCH 08/12] ARM: DRA7: Reuse the omap44xx_restart and fix the device instance
The omap44xx_restart used on omap4 and omap5 devices can be reused
on dra7 devices as well. The device instance however is different
across omap5 and dra7 as compared to omap4. So fix this for omap5
as well as dra7.
Signed-off-by: Rajendra Nayak
Signed-off-by: R Sricharan
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/prminst44xx.c | 20
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d0a9d15..137c9e4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_SOC_AM33XX) += am33xx-restart.o
obj-$(CONFIG_ARCH_OMAP3) += omap3-restart.o
obj-$(CONFIG_ARCH_OMAP4) += omap4-restart.o
obj-$(CONFIG_SOC_OMAP5)+= omap4-restart.o
+obj-$(CONFIG_SOC_DRA7XX) += omap4-restart.o
# Pin multiplexing
obj-$(CONFIG_SOC_OMAP2420) += mux2420.o
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 92f8dd3..55d3ee8 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -217,5 +217,6 @@ DT_MACHINE_START(DRA7XX_DT, "Generic DRA7XX (Flattened
Device Tree)")
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
.dt_compat = dra7xx_boards_compat,
+ .restart= omap44xx_restart,
MACHINE_END
#endif
diff --git a/arch/arm/mach-omap2/prminst44xx.c
b/arch/arm/mach-omap2/prminst44xx.c
index c12320c..6334b96 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -20,10 +20,13 @@
#include "common.h"
#include "prcm-common.h"
#include "prm44xx.h"
+#include "prm54xx.h"
+#include "prm7xx.h"
#include "prminst44xx.h"
#include "prm-regbits-44xx.h"
#include "prcm44xx.h"
#include "prcm_mpu44xx.h"
+#include "soc.h"
static void __iomem *_prm_bases[OMAP4_MAX_PRCM_PARTITIONS];
@@ -165,10 +168,19 @@ int omap4_prminst_deassert_hardreset(u8 shift, u8 part,
s16 inst,
void omap4_prminst_global_warm_sw_reset(void)
{
u32 v;
-
- v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
- OMAP4_PRM_RSTCTRL_OFFSET);
+ s16 dev_inst;
+
+ if (cpu_is_omap44xx())
+ dev_inst = OMAP4430_PRM_DEVICE_INST;
+ else if (soc_is_omap54xx())
+ dev_inst = OMAP54XX_PRM_DEVICE_INST;
+ else if (soc_is_dra7xx())
+ dev_inst = DRA7XX_PRM_DEVICE_INST;
+ else
+ return;
+
+ v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION, dev_inst,
+ OMAP4_PRM_RSTCTRL_OFFSET);
v |= OMAP4430_RST_GLOBAL_WARM_SW_MASK;
omap4_prminst_write_inst_reg(v, OMAP4430_PRM_PARTITION,
OMAP4430_PRM_DEVICE_INST,
--
1.7.9.5
--
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.html
[PATCH 05/12] ARM: DRA7: clockdomain: Add DRA7XX data and update header
From: Ambresh K
Add the data file to describe all clock domains inside the DRA7XX SoC
Signed-off-by: Ambresh K
Signed-off-by: Tero Kristo
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/clockdomain.h |1 +
arch/arm/mach-omap2/clockdomains7xx_data.c | 739
3 files changed, 741 insertions(+)
create mode 100644 arch/arm/mach-omap2/clockdomains7xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index dbcd73f..f5576e0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -170,6 +170,7 @@ obj-$(CONFIG_SOC_AM43XX)+= $(clockdomain-common)
obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common)
obj-$(CONFIG_SOC_OMAP5)+= clockdomains54xx_data.o
obj-$(CONFIG_SOC_DRA7XX) += $(clockdomain-common)
+obj-$(CONFIG_SOC_DRA7XX) += clockdomains7xx_data.o
# Clock framework
obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index daeecf1..4b03394 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -217,6 +217,7 @@ extern void __init omap3xxx_clockdomains_init(void);
extern void __init am33xx_clockdomains_init(void);
extern void __init omap44xx_clockdomains_init(void);
extern void __init omap54xx_clockdomains_init(void);
+extern void __init dra7xx_clockdomains_init(void);
extern void clkdm_add_autodeps(struct clockdomain *clkdm);
extern void clkdm_del_autodeps(struct clockdomain *clkdm);
diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c
b/arch/arm/mach-omap2/clockdomains7xx_data.c
new file mode 100644
index 000..a7d25d3
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -0,0 +1,739 @@
+/*
+ * DRA7xx Clock domains framework
+ *
+ * Copyright (C) 2009-2013 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Nokia Corporation
+ *
+ * Abhijit Pagare (abhijitpag...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Paul Walmsley (p...@pwsan.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap@vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "clockdomain.h"
+#include "cm1_7xx.h"
+#include "cm2_7xx.h"
+
+#include "cm-regbits-7xx.h"
+#include "prm7xx.h"
+#include "prcm44xx.h"
+#include "prcm_mpu7xx.h"
+
+/* Static Dependencies for DRA7xx Clock Domains */
+
+static struct clkdm_dep cam_wkup_sleep_deps[] = {
+ { .clkdm_name = "emif_clkdm" },
+ { NULL },
+};
+
+static struct clkdm_dep dma_wkup_sleep_deps[] = {
+ { .clkdm_name = "dss_clkdm" },
+ { .clkdm_name = "emif_clkdm" },
+ { .clkdm_name = "ipu_clkdm" },
+ { .clkdm_name = "ipu1_clkdm" },
+ { .clkdm_name = "ipu2_clkdm" },
+ { .clkdm_name = "iva_clkdm" },
+ { .clkdm_name = "l3init_clkdm" },
+ { .clkdm_name = "l4cfg_clkdm" },
+ { .clkdm_name = "l4per_clkdm" },
+ { .clkdm_name = "l4per2_clkdm" },
+ { .clkdm_name = "l4per3_clkdm" },
+ { .clkdm_name = "l4sec_clkdm" },
+ { .clkdm_name = "pcie_clkdm" },
+ { .clkdm_name = "wkupaon_clkdm" },
+ { NULL },
+};
+
+static struct clkdm_dep dsp1_wkup_sleep_deps[] = {
+ { .clkdm_name = "atl_clkdm" },
+ { .clkdm_name = "cam_clkdm" },
+ { .clkdm_name = "dsp2_clkdm" },
+ { .clkdm_name = "dss_clkdm" },
+ { .clkdm_name = "emif_clkdm" },
+ { .clkdm_name = "eve1_clkdm" },
+ { .clkdm_name = "eve2_clkdm" },
+ { .clkdm_name = "eve3_clkdm" },
+ { .clkdm_name = "eve4_clkdm" },
+ { .clkdm_name = "gmac_clkdm" },
+ { .clkdm_name = "gpu_clkdm" },
+ { .clkdm_name = "ipu_clkdm" },
+ { .clkdm_name = "ipu1_clkdm" },
+ { .clkdm_name = "ipu2_clkdm" },
+ { .clkdm_name = "iva_clkdm" },
+ { .clkdm_name = "l3init_clkdm" },
+ { .clkdm_name = "l4per_clkdm" },
+ { .clkdm_name = "l4per2_clkdm" },
+ { .clkdm_name = "l4per3_clkdm" },
+ { .clkdm_name = "l4sec_clkdm" },
+ { .clkdm_name = "pcie_clkdm" },
+ { .clkdm_name = "vpe_clkdm" },
+ { .clkdm_name = "wkupaon_clkdm" },
+ { NULL },
+};
+
+static struct clkdm_dep dsp2_wkup_sleep_deps[] = {
+ { .clkdm_name = "atl_clkdm" },
+ { .clkdm_name = "cam_clkdm" },
+ { .clkdm_name = "dsp1_clkdm" },
+ { .clkdm_name = "dss_clkdm" },
+ { .clkdm_name = "emif_clkdm" },
+ { .clkdm_name = "eve1_cl
[PATCH 12/12] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
From: R Sricharan
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved.
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts | 20 ++
arch/arm/boot/dts/dra7.dtsi| 488
3 files changed, 510 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/dra7-evm.dts
create mode 100644 arch/arm/boot/dts/dra7.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..e2f8566 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
- am43x-epos-evm.dtb
+ am43x-epos-evm.dtb \
+ dra7-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
new file mode 100644
index 000..cb0703c
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -0,0 +1,20 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "dra7.dtsi"
+
+/ {
+ model = "TI DRA7";
+ compatible = "ti,dra7-evm", "ti,dra7";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x6000>; /* 1536 MB */
+ };
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
new file mode 100644
index 000..8a0c08e
--- /dev/null
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -0,0 +1,488 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on "omap4.dtsi"
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "ti,dra7xx";
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ serial3 = &uart4;
+ serial4 = &uart5;
+ serial5 = &uart6;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a15";
+ timer {
+ compatible = "arm,armv7-timer";
+ /*
+* PPI secure/nonsecure IRQ,
+* active low level-sensitive
+*/
+ interrupts = <1 13 0x308>,
+<1 14 0x308>;
+ clock-frequency = <6144000>;
+ };
+ };
+ cpu@1 {
+ compatible = "arm,cortex-a15";
+ timer {
+ compatible = "arm,armv7-timer";
+ /*
+* PPI secure/nonsecure IRQ,
+* active low level-sensitive
+*/
+ interrupts = <1 13 0x308>,
+<1 14 0x308>;
+ clock-frequency = <6144000>;
+ };
+ };
+ };
+
+ gic: interrupt-controller@48211000 {
+ compatible = "arm,cortex-a15-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x48211000 0x1000>,
+ <0x48212000 0x1000>;
+ };
+
+ /*
+* The soc node represents the soc top level view. It is uses for IPs
+* that are not memory mapped in the MPU view or for the MPU itself.
+*/
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap5-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ /*
+* XXX: Use a flat representation of the SOC interconnect.
+* The real OMAP interconnect network is quite complex.
+* Since that will not bring real advantage to represent that in DT for
+* the moment, just use a fake OCP bus entry to represent the whole bus
+* hierarchy.
+*/
+ ocp {
+ compatible = "ti,omap4-l3-noc", "simple-bus";
+
[PATCH 11/12] ARM: DRA7: Add the build support in omap2plus
From: R Sricharan Now that all the needed pieces for DRA7 based SoCs' is present, enable the build support in omap2plus_defconfig Signed-off-by: R Sricharan Signed-off-by: Rajendra Nayak --- arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap2/Kconfig | 10 +- arch/arm/plat-omap/Kconfig |2 +- 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 2ac0ffb..8b17466 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -286,3 +286,4 @@ CONFIG_SOC_OMAP5=y CONFIG_TI_DAVINCI_MDIO=y CONFIG_TI_DAVINCI_CPDMA=y CONFIG_TI_CPSW=y +CONFIG_SOC_DRA7XX=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bd34483..e85d430 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -36,7 +36,7 @@ config ARCH_OMAP2PLUS_TYPICAL select I2C select I2C_OMAP select MENELAUS if ARCH_OMAP2 - select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5 + select NEON if CPU_V7 select PM_RUNTIME select REGULATOR select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 @@ -115,6 +115,14 @@ config SOC_OMAP5 select COMMON_CLK select HAVE_ARM_ARCH_TIMER +config SOC_DRA7XX + bool "TI DRA7XX" + select ARM_ARCH_TIMER + select CPU_V7 + select ARM_GIC + select HAVE_SMP + select COMMON_CLK + comment "OMAP Core Type" depends on ARCH_OMAP2 diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index f82bae2..436ea97 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -106,7 +106,7 @@ config OMAP_32K_TIMER This timer saves power compared to the OMAP_MPU_TIMER, and has support for no tick during idle. The 32KHz timer provides less intra-tick resolution than OMAP_MPU_TIMER. The 32KHz timer is - currently only available for OMAP16XX, 24XX, 34XX and OMAP4/5. + currently only available for OMAP16XX, 24XX, 34XX, OMAP4/5 and DRA7XX. On OMAP2PLUS this value is only used for CONFIG_HZ and CLOCK_TICK_RATE compile time calculation. -- 1.7.9.5 -- 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.html
[PATCH 10/12] ARM: DRA7: Enable PM framework initializations
From: Ambresh K
Initialise powerdomains, clockdomains, and hwmod frameworks.
Signed-off-by: Ambresh K
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/io.c |5 +
arch/arm/mach-omap2/prm44xx.c |2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 542e6bd..09115e7 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -667,6 +667,11 @@ void __init dra7xx_init_early(void)
omap_prm_base_init();
omap_cm_base_init();
dra7xx_check_revision();
+ omap44xx_prm_init();
+ dra7xx_powerdomains_init();
+ dra7xx_clockdomains_init();
+ dra7xx_hwmod_init();
+ omap_hwmod_init_postsetup();
}
#endif
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 15271b6..03a6034 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -660,7 +660,7 @@ static struct prm_ll_data omap44xx_prm_ll_data = {
int __init omap44xx_prm_init(void)
{
- if (!cpu_is_omap44xx() && !soc_is_omap54xx())
+ if (!cpu_is_omap44xx() && !soc_is_omap54xx() && !soc_is_dra7xx())
return 0;
return prm_register(&omap44xx_prm_ll_data);
--
1.7.9.5
--
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.html
[PATCH 07/12] ARM: DRA7: powerdomain: Handle missing vc/vp
DRA7 belongs to the omap4plus devices which reuse the omap4_pwrdm_operations
ops for powerdomain control. DRA7 however has no VC/VP while all the
earlier omap4plus devices did.
So use the .pwrdm_has_voltdm() ops to pass this info on to the core.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/prm44xx.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 415c7e0..15271b6 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -620,6 +620,15 @@ static int omap4_pwrdm_wait_transition(struct powerdomain
*pwrdm)
return 0;
}
+static int omap4_check_vcvp(void)
+{
+ /* No VC/VP on dra7xx devices */
+ if (soc_is_dra7xx())
+ return 0;
+
+ return 1;
+}
+
struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_set_next_pwrst = omap4_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst = omap4_pwrdm_read_next_pwrst,
@@ -637,6 +646,7 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
+ .pwrdm_has_voltdm = omap4_check_vcvp,
};
/*
--
1.7.9.5
--
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.html
[PATCH 06/12] ARM: DRA7: powerdomain: Add DRA7XX data and update header
From: Ambresh K
Add the data file to describe all power domains inside the DRA7XX SoC.
Signed-off-by: Ambresh K
Signed-off-by: Tero Kristo
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/powerdomain.h |1 +
arch/arm/mach-omap2/powerdomains7xx_data.c | 453
3 files changed, 455 insertions(+)
create mode 100644 arch/arm/mach-omap2/powerdomains7xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f5576e0..d0a9d15 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_SOC_AM43XX)+= $(powerdomain-common)
obj-$(CONFIG_SOC_OMAP5)+= $(powerdomain-common)
obj-$(CONFIG_SOC_OMAP5)+= powerdomains54xx_data.o
obj-$(CONFIG_SOC_DRA7XX) += $(powerdomain-common)
+obj-$(CONFIG_SOC_DRA7XX) += powerdomains7xx_data.o
# PRCM clockdomain control
clockdomain-common += clockdomain.o
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index e4d7bd6..baf3d8b 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -256,6 +256,7 @@ extern void omap3xxx_powerdomains_init(void);
extern void am33xx_powerdomains_init(void);
extern void omap44xx_powerdomains_init(void);
extern void omap54xx_powerdomains_init(void);
+extern void dra7xx_powerdomains_init(void);
extern struct pwrdm_ops omap2_pwrdm_operations;
extern struct pwrdm_ops omap3_pwrdm_operations;
diff --git a/arch/arm/mach-omap2/powerdomains7xx_data.c
b/arch/arm/mach-omap2/powerdomains7xx_data.c
new file mode 100644
index 000..882b794
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains7xx_data.c
@@ -0,0 +1,453 @@
+/*
+ * DRA7xx Power domains framework
+ *
+ * Copyright (C) 2009-2013 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Nokia Corporation
+ *
+ * Abhijit Pagare (abhijitpag...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Paul Walmsley (p...@pwsan.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap@vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "powerdomain.h"
+
+#include "prcm-common.h"
+#include "prcm44xx.h"
+#include "prm7xx.h"
+#include "prcm_mpu7xx.h"
+
+/* iva_7xx_pwrdm: IVA-HD power domain */
+static struct powerdomain iva_7xx_pwrdm = {
+ .name = "iva_pwrdm",
+ .prcm_offs= DRA7XX_PRM_IVA_INST,
+ .prcm_partition = DRA7XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF,
+ .banks= 4,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* hwa_mem */
+ [1] = PWRSTS_OFF_RET, /* sl2_mem */
+ [2] = PWRSTS_OFF_RET, /* tcm1_mem */
+ [3] = PWRSTS_OFF_RET, /* tcm2_mem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_OFF_RET, /* hwa_mem */
+ [1] = PWRSTS_OFF_RET, /* sl2_mem */
+ [2] = PWRSTS_OFF_RET, /* tcm1_mem */
+ [3] = PWRSTS_OFF_RET, /* tcm2_mem */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* rtc_7xx_pwrdm: */
+static struct powerdomain rtc_7xx_pwrdm = {
+ .name = "rtc_pwrdm",
+ .prcm_offs= DRA7XX_PRM_RTC_INST,
+ .prcm_partition = DRA7XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+};
+
+/* custefuse_7xx_pwrdm: Customer efuse controller power domain */
+static struct powerdomain custefuse_7xx_pwrdm = {
+ .name = "custefuse_pwrdm",
+ .prcm_offs= DRA7XX_PRM_CUSTEFUSE_INST,
+ .prcm_partition = DRA7XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_ON,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* ipu_7xx_pwrdm: Audio back end power domain */
+static struct powerdomain ipu_7xx_pwrdm = {
+ .name = "ipu_pwrdm",
+ .prcm_offs= DRA7XX_PRM_IPU_INST,
+ .prcm_partition = DRA7XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF,
+ .banks= 2,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* aessmem */
+ [1] = PWRSTS_OFF_RET, /* periphmem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_OFF_RET, /* aessmem */
+ [1] = PWRSTS_OFF_RET, /* periphmem */
+
[PATCH 04/12] ARM: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters
From: Ambresh K Add the PRCM MPU registers for DRA7XX platforms Signed-off-by: Ambresh K Signed-off-by: Tero Kristo Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/prcm44xx.h|5 +++ arch/arm/mach-omap2/prcm_mpu7xx.h | 77 + 2 files changed, 82 insertions(+) create mode 100644 arch/arm/mach-omap2/prcm_mpu7xx.h diff --git a/arch/arm/mach-omap2/prcm44xx.h b/arch/arm/mach-omap2/prcm44xx.h index f429cdd..4fea2cf 100644 --- a/arch/arm/mach-omap2/prcm44xx.h +++ b/arch/arm/mach-omap2/prcm44xx.h @@ -38,6 +38,11 @@ #define OMAP54XX_SCRM_PARTITION4 #define OMAP54XX_PRCM_MPU_PARTITION5 +#define DRA7XX_PRM_PARTITION 1 +#define DRA7XX_CM_CORE_AON_PARTITION 2 +#define DRA7XX_CM_CORE_PARTITION 3 +#define DRA7XX_MPU_PRCM_PARTITION 5 + /* * OMAP4_MAX_PRCM_PARTITIONS: set to the highest value of the PRCM partition * IDs, plus one diff --git a/arch/arm/mach-omap2/prcm_mpu7xx.h b/arch/arm/mach-omap2/prcm_mpu7xx.h new file mode 100644 index 000..67c4b6b --- /dev/null +++ b/arch/arm/mach-omap2/prcm_mpu7xx.h @@ -0,0 +1,77 @@ +/* + * DRA7xx PRCM MPU instance offset macros + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_MPU7XX_H +#define __ARCH_ARM_MACH_OMAP2_PRCM_MPU7XX_H + +#include "prcm_mpu_44xx_54xx.h" + +#define DRA7XX_PRCM_MPU_BASE 0x48243000 + +#define DRA7XX_PRCM_MPU_REGADDR(inst, reg) \ + OMAP2_L4_IO_ADDRESS(DRA7XX_PRCM_MPU_BASE + (inst) + (reg)) + +/* MPU_PRCM instances */ +#define DRA7XX_MPU_PRCM_OCP_SOCKET_INST0x +#define DRA7XX_MPU_PRCM_DEVICE_INST0x0200 +#define DRA7XX_MPU_PRCM_PRM_C0_INST0x0400 +#define DRA7XX_MPU_PRCM_CM_C0_INST 0x0600 +#define DRA7XX_MPU_PRCM_PRM_C1_INST0x0800 +#define DRA7XX_MPU_PRCM_CM_C1_INST 0x0a00 + +/* PRCM_MPU clockdomain register offsets (from instance start) */ +#define DRA7XX_MPU_PRCM_CM_C0_CPU0_CDOFFS 0x +#define DRA7XX_MPU_PRCM_CM_C1_CPU1_CDOFFS 0x + + +/* MPU_PRCM */ + +/* MPU_PRCM.PRCM_MPU_OCP_SOCKET register offsets */ +#define DRA7XX_REVISION_PRCM_MPU_OFFSET0x + +/* MPU_PRCM.PRCM_MPU_DEVICE register offsets */ +#define DRA7XX_PRM_FRAC_INCREMENTER_NUMERATOR_OFFSET 0x0010 +#define DRA7XX_PRM_FRAC_INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x0014 + +/* MPU_PRCM.PRCM_MPU_PRM_C0 register offsets */ +#define DRA7XX_PM_CPU0_PWRSTCTRL_OFFSET0x +#define DRA7XX_PM_CPU0_PWRSTST_OFFSET 0x0004 +#define DRA7XX_RM_CPU0_CPU0_RSTCTRL_OFFSET 0x0010 +#define DRA7XX_RM_CPU0_CPU0_RSTST_OFFSET 0x0014 +#define DRA7XX_RM_CPU0_CPU0_CONTEXT_OFFSET 0x0024 + +/* MPU_PRCM.PRCM_MPU_CM_C0 register offsets */ +#define DRA7XX_CM_CPU0_CLKSTCTRL_OFFSET0x +#define DRA7XX_CM_CPU0_CPU0_CLKCTRL_OFFSET 0x0020 +#define DRA7XX_CM_CPU0_CPU0_CLKCTRL DRA7XX_MPU_PRCM_REGADDR(DRA7XX_MPU_PRCM_CM_C0_INST, 0x0020) + +/* MPU_PRCM.PRCM_MPU_PRM_C1 register offsets */ +#define DRA7XX_PM_CPU1_PWRSTCTRL_OFFSET0x +#define DRA7XX_PM_CPU1_PWRSTST_OFFSET 0x0004 +#define DRA7XX_RM_CPU1_CPU1_RSTCTRL_OFFSET 0x0010 +#define DRA7XX_RM_CPU1_CPU1_RSTST_OFFSET 0x0014 +#define DRA7XX_RM_CPU1_CPU1_CONTEXT_OFFSET 0x0024 + +/* MPU_PRCM.PRCM_MPU_CM_C1 register offsets */ +#define DRA7XX_CM_CPU1_CLKSTCTRL_OFFSET0x +#define DRA7XX_CM_CPU1_CPU1_CLKCTRL_OFFSET 0x0020 +#define DRA7XX_CM_CPU1_CPU1_CLKCTRL DRA7XX_MPU_PRCM_REGADDR(DRA7XX_MPU_PRCM_CM_C1_INST, 0x0020) + +#endif -- 1.7.9.5 -- 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.html
[PATCH 00/12] DRA7xx PRCM, hwmod and DT data
This series adds the data files for DRA7xx devices for PRCM, hwmod and DT. This is dependent on the core support [1] patches for DRA7xx and leaves out the clock data since its on its way to DT [2] The regbit headers for prm and cm are cleaned up post the autogeneration as 95% was seen to be currently unused (prm-regbits-7xx.h was 100% unused and hence removed) These patches along with the core support patches are available at: git://github.com/rrnayak/linux.git for-3.12/dra-core-data [1] http://marc.info/?l=linux-omap&m=137335492102004&w=2 [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg91318.html Ambresh K (7): ARM: DRA7: PRM: Add DRA7XX register definitions ARM: DRA7: CM: Add DRA7XX register defines ARM: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters ARM: DRA7: clockdomain: Add DRA7XX data and update header ARM: DRA7: powerdomain: Add DRA7XX data and update header ARM: DRA7: hwmod: Create initial DRA7XX SoC data ARM: DRA7: Enable PM framework initializations R Sricharan (2): ARM: DRA7: Add the build support in omap2plus ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board Rajendra Nayak (3): ARM: DRA7: CM: Add minimal regbit shifts ARM: DRA7: powerdomain: Handle missing vc/vp ARM: DRA7: Reuse the omap44xx_restart and fix the device instance arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts | 20 + arch/arm/boot/dts/dra7.dtsi| 488 + arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap2/Kconfig| 10 +- arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/board-generic.c|1 + arch/arm/mach-omap2/clockdomain.h |1 + arch/arm/mach-omap2/clockdomains7xx_data.c | 739 arch/arm/mach-omap2/cm-regbits-7xx.h | 50 + arch/arm/mach-omap2/cm1_7xx.h | 323 arch/arm/mach-omap2/cm2_7xx.h | 512 ++ arch/arm/mach-omap2/io.c |5 + arch/arm/mach-omap2/omap_hwmod.h |1 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2724 arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains7xx_data.c | 453 + arch/arm/mach-omap2/prcm44xx.h |5 + arch/arm/mach-omap2/prcm_mpu7xx.h | 77 + arch/arm/mach-omap2/prm44xx.c | 12 +- arch/arm/mach-omap2/prm7xx.h | 677 +++ arch/arm/mach-omap2/prminst44xx.c | 20 +- arch/arm/plat-omap/Kconfig |2 +- 23 files changed, 6121 insertions(+), 8 deletions(-) create mode 100644 arch/arm/boot/dts/dra7-evm.dts create mode 100644 arch/arm/boot/dts/dra7.dtsi create mode 100644 arch/arm/mach-omap2/clockdomains7xx_data.c create mode 100644 arch/arm/mach-omap2/cm-regbits-7xx.h create mode 100644 arch/arm/mach-omap2/cm1_7xx.h create mode 100644 arch/arm/mach-omap2/cm2_7xx.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_7xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains7xx_data.c create mode 100644 arch/arm/mach-omap2/prcm_mpu7xx.h create mode 100644 arch/arm/mach-omap2/prm7xx.h -- 1.7.9.5 -- 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.html
[PATCH 03/12] ARM: DRA7: CM: Add minimal regbit shifts
This header contains minimal regbits that are currently used in code. This header has traditionally been autogenerated on OMAP4+ devices but the autogenerated contents are largely (95%) unused and hence to reduce unsued data in the kernel this header has been cut down (from the autogen output) to whatever is currently needed. This is done by running a cleanup script on top of the existing autogen script. Signed-off-by: Rajendra Nayak Signed-off-by: Ambresh K --- arch/arm/mach-omap2/cm-regbits-7xx.h | 50 ++ 1 file changed, 50 insertions(+) create mode 100644 arch/arm/mach-omap2/cm-regbits-7xx.h diff --git a/arch/arm/mach-omap2/cm-regbits-7xx.h b/arch/arm/mach-omap2/cm-regbits-7xx.h new file mode 100644 index 000..674c9f4 --- /dev/null +++ b/arch/arm/mach-omap2/cm-regbits-7xx.h @@ -0,0 +1,50 @@ +/* + * DRA7xx Clock Management register bits + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_CM_REGBITS_7XX_H +#define __ARCH_ARM_MACH_OMAP2_CM_REGBITS_7XX_H + +#define DRA7XX_ATL_STATDEP_SHIFT 30 +#define DRA7XX_CAM_STATDEP_SHIFT 9 +#define DRA7XX_DSP1_STATDEP_SHIFT 1 +#define DRA7XX_DSP2_STATDEP_SHIFT 18 +#define DRA7XX_DSS_STATDEP_SHIFT 8 +#define DRA7XX_EMIF_STATDEP_SHIFT 4 +#define DRA7XX_EVE1_STATDEP_SHIFT 19 +#define DRA7XX_EVE2_STATDEP_SHIFT 20 +#define DRA7XX_EVE3_STATDEP_SHIFT 21 +#define DRA7XX_EVE4_STATDEP_SHIFT 22 +#define DRA7XX_GMAC_STATDEP_SHIFT 25 +#define DRA7XX_GPU_STATDEP_SHIFT 10 +#define DRA7XX_IPU1_STATDEP_SHIFT 23 +#define DRA7XX_IPU2_STATDEP_SHIFT 0 +#define DRA7XX_IPU_STATDEP_SHIFT 24 +#define DRA7XX_IVA_STATDEP_SHIFT 2 +#define DRA7XX_L3INIT_STATDEP_SHIFT7 +#define DRA7XX_L3MAIN1_STATDEP_SHIFT 5 +#define DRA7XX_L4CFG_STATDEP_SHIFT 12 +#define DRA7XX_L4PER2_STATDEP_SHIFT26 +#define DRA7XX_L4PER3_STATDEP_SHIFT27 +#define DRA7XX_L4PER_STATDEP_SHIFT 13 +#define DRA7XX_L4SEC_STATDEP_SHIFT 14 +#define DRA7XX_PCIE_STATDEP_SHIFT 29 +#define DRA7XX_VPE_STATDEP_SHIFT 28 +#define DRA7XX_WKUPAON_STATDEP_SHIFT 15 +#endif -- 1.7.9.5 -- 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.html
[PATCH 01/12] ARM: DRA7: PRM: Add DRA7XX register definitions
From: Ambresh K Add the new defines for DRA7xx prm module registers. Signed-off-by: Ambresh K Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/prm7xx.h | 677 ++ 1 file changed, 677 insertions(+) create mode 100644 arch/arm/mach-omap2/prm7xx.h diff --git a/arch/arm/mach-omap2/prm7xx.h b/arch/arm/mach-omap2/prm7xx.h new file mode 100644 index 000..6c6db25 --- /dev/null +++ b/arch/arm/mach-omap2/prm7xx.h @@ -0,0 +1,677 @@ +/* + * DRA7xx PRM instance offset macros + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRM7XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM7XX_H + +#include "prm44xx_54xx.h" +#include "prcm-common.h" +#include "prm.h" + +#define DRA7XX_PRM_BASE0x4ae06000 + +#define DRA7XX_PRM_REGADDR(inst, reg) \ + OMAP2_L4_IO_ADDRESS(DRA7XX_PRM_BASE + (inst) + (reg)) + + +/* PRM instances */ +#define DRA7XX_PRM_OCP_SOCKET_INST 0x +#define DRA7XX_PRM_CKGEN_INST 0x0100 +#define DRA7XX_PRM_MPU_INST0x0300 +#define DRA7XX_PRM_DSP1_INST 0x0400 +#define DRA7XX_PRM_IPU_INST0x0500 +#define DRA7XX_PRM_COREAON_INST0x0628 +#define DRA7XX_PRM_CORE_INST 0x0700 +#define DRA7XX_PRM_IVA_INST0x0f00 +#define DRA7XX_PRM_CAM_INST0x1000 +#define DRA7XX_PRM_DSS_INST0x1100 +#define DRA7XX_PRM_GPU_INST0x1200 +#define DRA7XX_PRM_L3INIT_INST 0x1300 +#define DRA7XX_PRM_L4PER_INST 0x1400 +#define DRA7XX_PRM_CUSTEFUSE_INST 0x1600 +#define DRA7XX_PRM_WKUPAON_INST0x1724 +#define DRA7XX_PRM_WKUPAON_CM_INST 0x1800 +#define DRA7XX_PRM_EMU_INST0x1900 +#define DRA7XX_PRM_EMU_CM_INST 0x1a00 +#define DRA7XX_PRM_DSP2_INST 0x1b00 +#define DRA7XX_PRM_EVE1_INST 0x1b40 +#define DRA7XX_PRM_EVE2_INST 0x1b80 +#define DRA7XX_PRM_EVE3_INST 0x1bc0 +#define DRA7XX_PRM_EVE4_INST 0x1c00 +#define DRA7XX_PRM_RTC_INST0x1c60 +#define DRA7XX_PRM_VPE_INST0x1c80 +#define DRA7XX_PRM_DEVICE_INST 0x1d00 +#define DRA7XX_PRM_INSTR_INST 0x1f00 + +/* PRM clockdomain register offsets (from instance start) */ +#define DRA7XX_PRM_WKUPAON_CM_WKUPAON_CDOFFS 0x +#define DRA7XX_PRM_EMU_CM_EMU_CDOFFS 0x + +/* PRM */ + +/* PRM.OCP_SOCKET_PRM register offsets */ +#define DRA7XX_REVISION_PRM_OFFSET 0x +#define DRA7XX_PRM_IRQSTATUS_MPU_OFFSET0x0010 +#define DRA7XX_PRM_IRQSTATUS_MPU_2_OFFSET 0x0014 +#define DRA7XX_PRM_IRQENABLE_MPU_OFFSET0x0018 +#define DRA7XX_PRM_IRQENABLE_MPU_2_OFFSET 0x001c +#define DRA7XX_PRM_IRQSTATUS_IPU2_OFFSET 0x0020 +#define DRA7XX_PRM_IRQENABLE_IPU2_OFFSET 0x0028 +#define DRA7XX_PRM_IRQSTATUS_DSP1_OFFSET 0x0030 +#define DRA7XX_PRM_IRQENABLE_DSP1_OFFSET 0x0038 +#define DRA7XX_CM_PRM_PROFILING_CLKCTRL_OFFSET 0x0040 +#define DRA7XX_CM_PRM_PROFILING_CLKCTRL DRA7XX_PRM_REGADDR(DRA7XX_PRM_OCP_SOCKET_INST, 0x0040) +#define DRA7XX_PRM_IRQENABLE_DSP2_OFFSET 0x0044 +#define DRA7XX_PRM_IRQENABLE_EVE1_OFFSET 0x0048 +#define DRA7XX_PRM_IRQENABLE_EVE2_OFFSET 0x004c +#define DRA7XX_PRM_IRQENABLE_EVE3_OFFSET 0x0050 +#define DRA7XX_PRM_IRQENABLE_EVE4_OFFSET 0x0054 +#define DRA7XX_PRM_IRQENABLE_IPU1_OFFSET 0x0058 +#define DRA7XX_PRM_IRQSTATUS_DSP2_OFFSET 0x005c +#define DRA7XX_PRM_IRQSTATUS_EVE1_OFFSET 0x0060 +#define DRA7XX_PRM_IRQSTATUS_EVE2_OFFSET 0x0064 +#define DRA7XX_PRM_IRQSTATUS_EVE3_OFFSET 0x0068 +#define DRA7XX_PRM_IRQSTATUS_EVE4_OFFSET 0x006c +#define DRA7XX_PRM_IRQSTATUS_IPU1_OFFSET 0x0070 +#define DRA7XX_PRM_DEBUG_CFG1_OFFSET 0x00e4 +#define DRA7XX_PRM_DEBUG_CFG2_OFFSET 0x00e8 +#define DRA7XX_PRM_DEBUG_CF
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On Monday 08 July 2013 08:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 07:12:59PM +0530, Sourav Poddar wrote:
+static inline unsigned long dra7xxx_readl(struct dra7xxx_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi->base + reg);
+}
+
+static inline void dra7xxx_writel(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi->base + reg);
+}
+
+static inline unsigned long dra7xxx_readl_data(struct dra7xxx_qspi *qspi,
+ unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ return readw(qspi->base + reg);
+ break;
+ case 16:
+ return readb(qspi->base + reg);
+ break;
+ case 32:
+ return readl(qspi->base + reg);
+ break;
+ default:
+ return -1;
return -EINVAL ? or some other error code ?
Ok.will change.
+ }
+}
+
+static inline void dra7xxx_writel_data(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ writew(val, qspi->base + reg);
+ break;
+ case 16:
+ writeb(val, qspi->base + reg);
+ break;
+ case 32:
+ writeb(val, qspi->base + reg);
+ break;
+ default:
+ dev_dbg(qspi->dev, "word lenght out of range");
+ break;
+ }
+}
+
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(spi->master);
+ int clk_div = 0;
+ u32 clk_ctrl_reg, clk_rate;
+
+ clk_rate = clk_get_rate(qspi->fclk);
+
+ if (!qspi->spi_max_frequency) {
+ dev_err(qspi->dev, "spi max frequency not defined\n");
+ return -1;
same here
Ok.
+ } else
this needs to have curly braces too, per CodingStyle
hmm..will change.
+ clk_div = (clk_rate / qspi->spi_max_frequency) - 1;
+
+ dev_dbg(qspi->dev, "%s: hz: %d, clock divider %d\n", __func__,
+ qspi->spi_max_frequency, clk_div);
+
+ pm_runtime_get_sync(qspi->dev);
+
+ clk_ctrl_reg = dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ clk_ctrl_reg&= ~QSPI_CLK_EN;
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, clk_ctrl_reg, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div< 0) {
+ dev_dbg(qspi->dev, "%s: clock divider< 0, using /1 divider\n",
+ __func__);
+ clk_div = 1;
+ }
+
+ if (clk_div> QSPI_CLK_DIV_MAX) {
+ dev_dbg(qspi->dev, "%s: clock divider>%d , using /%d divider\n",
+ __func__, QSPI_CLK_DIV_MAX, QSPI_CLK_DIV_MAX + 1);
+ clk_div = QSPI_CLK_DIV_MAX;
+ }
+
+ /* enable SCLK */
+ dra7xxx_writel(qspi, QSPI_CLK_EN | clk_div, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ pm_runtime_mark_last_busy(qspi->dev);
+ pm_runtime_put_autosuspend(qspi->dev);
+
+ return 0;
+}
+
+static int dra7xxx_qspi_prepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_get_sync(qspi->dev);
not going to check return value ?
Will add.
+ return 0;
+}
+
+static int dra7xxx_qspi_unprepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_mark_last_busy(qspi->dev);
+ pm_runtime_put_autosuspend(qspi->dev);
what about on these two ?
Yes, will add error checking.
+ return 0;
+}
+
+static int qspi_write_msg(struct dra7xxx_qspi *qspi, struct spi_transfer *t)
+{
+ const u8 *txbuf;
+ int wlen, count;
+
+ count = t->len;
+ txbuf = t->tx_buf;
+ wlen = t->bits_per_word;
+
+ while (count--) {
+ dev_dbg(qspi->dev, "tx cmd %08x dc %08x data %02x\n",
+ qspi->cmd | QSPI_WR_SNGL, qspi->dc, *txbuf);
+ dra7xxx_writel(qspi, QSPI_WC_INT_EN, QSPI_INTR_ENABLE_SET_REG);
you should enable the interrupt as the last step. Also, why aren't you
using frame interrupt ?
+ dra7xxx_writel_data(qspi, *txbuf++, QSPI_SPI_DATA_REG, wlen);
+ dra7xxx_writel(qspi, qspi->dc, QSPI_SPI_DC_REG);
+ dra7xxx_writel(qspi, qspi->cmd | QSPI_WR_SNGL,
+ QSPI_SPI_CMD_REG);
+ wait_for_completion(&qspi->word_complete);
+ }
+
+ return 0;
+}
+
+static int qspi_read_msg(struct dra7xxx_qspi *qspi, struct spi_transfer *t)
+{
+ u8 *rxbuf;
+ int wlen, count;
+
+ count = t->len;
+ rxbuf = t->rx_buf;
+ wlen = t->bits_per_word;
+
+ while (count--) {
+ dev_dbg(qspi->dev, "rx cmd %08x dc %08x\n",
+ qspi->cmd | QSPI_RD_SNGL, qspi->dc);
+ dra7xxx_writel(qspi, QSPI_WC_
[PATCH 8/8] ARM: DRA7: Kconfig: Increase the default gpio count
From: R Sricharan DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs. In order for the gpiolib to detect and initialize these additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set to 512 instead of present 256. Signed-off-by: R Sricharan Signed-off-by: Rajendra Nayak --- arch/arm/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5ef7af0..9faed52 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1599,7 +1599,7 @@ config LOCAL_TIMERS config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA - default 512 if SOC_OMAP5 + default 512 if SOC_OMAP5 || SOC_DRA7XX default 512 if ARCH_KEYSTONE default 392 if ARCH_U8500 default 352 if ARCH_VT8500 -- 1.7.9.5 -- 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.html
[PATCH 6/8] ARM: DRA7: Resue the clocksource, clockevent support
From: R Sricharan All of OMAP5 timer support for clocksource and clockevent is completely reused across DRA7. Signed-off-by: R Sricharan Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/Kconfig |2 +- arch/arm/mach-omap2/timer.c |3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index c7b32a9..bd34483 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -50,7 +50,7 @@ config SOC_HAS_OMAP2_SDRC config SOC_HAS_REALTIME_COUNTER bool "Real time free running counter" - depends on SOC_OMAP5 + depends on SOC_OMAP5 || SOC_DRA7XX default y config ARCH_OMAP2 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 29ac667..fc01704 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -594,7 +594,8 @@ OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, 1, "timer_sys_ck", "ti,timer-alwon"); #endif -#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) +#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \ + defined(CONFIG_SOC_DRA7XX) static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon", 2, "sys_clkin_ck", NULL); #endif -- 1.7.9.5 -- 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.html
[PATCH 0/8] DRA7xx core support
DRA7xx based SoCs' are high-performance, infotainment application devices, based on enhanced OMAP architecture integrated on a 28nm technology. The DRA7xx family is composed of DRA75x and DRA74x devices. The current device for which the patches add support is the DRA752 SoC. Most of the core IPs are similar to those found on the OMAP5 devices, including the dual cortex-A15 based MPU subsystem, which has helped quite some reuse from existing OMAP5 support. This series contains only core support patches and the PRCM, DT and hwmod data needed for the device will be posted as a seperate patch series. The bootloader support for the platform is already available in mainline u-boot. The patches are available at: git://github.com/rrnayak/linux.git for-3.12/dra-core R Sricharan (6): ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs' ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra ARM: DRA7: Reuse io tables and add a new .init_early ARM: DRA7: Resue the clocksource, clockevent support ARM: DRA7: board-generic: Add basic DT support ARM: DRA7: Kconfig: Increase the default gpio count Rajendra Nayak (2): ARM: DRA7: Update SRAM details ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5 .../devicetree/bindings/arm/omap/omap.txt |3 ++ arch/arm/Kconfig |2 +- arch/arm/mach-omap1/include/mach/soc.h |1 + arch/arm/mach-omap2/Kconfig|2 +- arch/arm/mach-omap2/Makefile |8 arch/arm/mach-omap2/board-generic.c| 18 + arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/id.c | 30 ++- arch/arm/mach-omap2/io.c | 22 ++- arch/arm/mach-omap2/omap54xx.h |4 ++ arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/soc.h | 39 arch/arm/mach-omap2/sram.c |7 arch/arm/mach-omap2/timer.c|3 +- 14 files changed, 134 insertions(+), 8 deletions(-) -- 1.7.9.5 -- 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.html
[PATCH 4/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
From: R Sricharan The PRCM and MPUSS parts of DRA7 devices are quite identical to OMAP5 so as to reuse all the existing infrastructure around it. Makefile updates to do just that. Signed-off-by: R Sricharan Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/Makefile |8 1 file changed, 8 insertions(+) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index ea5a27f..dbcd73f 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common) obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) obj-$(CONFIG_SOC_AM43XX) += $(hwmod-common) $(secure-common) +obj-$(CONFIG_SOC_DRA7XX) += prm44xx.o $(hwmod-common) $(secure-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -39,6 +40,7 @@ omap-4-5-common = omap4-common.o omap-wakeupgen.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) $(smp-y) sleep44xx.o obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-common) $(smp-y) sleep44xx.o obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) @@ -87,6 +89,7 @@ obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o +obj-$(CONFIG_SOC_DRA7XX) += omap-mpuss-lowpower.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o @@ -118,6 +121,7 @@ omap-prcm-4-5-common= cminst44xx.o cm44xx.o prm44xx.o \ vc44xx_data.o vp44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -147,6 +151,7 @@ obj-$(CONFIG_SOC_AM33XX)+= powerdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(powerdomain-common) obj-$(CONFIG_SOC_OMAP5)+= $(powerdomain-common) obj-$(CONFIG_SOC_OMAP5)+= powerdomains54xx_data.o +obj-$(CONFIG_SOC_DRA7XX) += $(powerdomain-common) # PRCM clockdomain control clockdomain-common += clockdomain.o @@ -164,6 +169,7 @@ obj-$(CONFIG_SOC_AM33XX)+= clockdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(clockdomain-common) obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common) obj-$(CONFIG_SOC_OMAP5)+= clockdomains54xx_data.o +obj-$(CONFIG_SOC_DRA7XX) += $(clockdomain-common) # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o @@ -185,6 +191,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_AM33XX) += cclock33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX) += $(clock-common) +obj-$(CONFIG_SOC_DRA7XX) += dpll3xxx.o dpll44xx.o # OMAP2 clock rate set data (old "OPP" data) obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o -- 1.7.9.5 -- 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.html
[PATCH 2/8] ARM: DRA7: Update SRAM details
DRA7xx devices have 512K of SRAM for both secure and non-secure
devices.
Signed-off-by: Rajendra Nayak
Signed-off-by: R Sricharan
---
arch/arm/mach-omap2/sram.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 4bd0968..67d4277 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -38,6 +38,7 @@
#define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
#endif
#define OMAP5_SRAM_PA 0x4030
+#define DRA7_SRAM_PA OMAP4_SRAM_PA
#define SRAM_BOOTLOADER_SZ 0x00
@@ -111,6 +112,9 @@ static void __init omap_detect_sram(void)
} else if (soc_is_omap54xx()) {
omap_sram_start = OMAP5_SRAM_PA;
omap_sram_size = SZ_128K; /* 128KB */
+ } else if (soc_is_dra7xx()) {
+ omap_sram_start = DRA7_SRAM_PA;
+ omap_sram_size = SZ_512K; /* 512KB */
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
@@ -131,6 +135,9 @@ static void __init omap_detect_sram(void)
} else if (soc_is_omap54xx()) {
omap_sram_start = OMAP5_SRAM_PA;
omap_sram_size = SZ_128K; /* 128KB */
+ } else if (soc_is_dra7xx()) {
+ omap_sram_start = DRA7_SRAM_PA;
+ omap_sram_size = SZ_512K; /* 512KB */
} else {
omap_sram_start = OMAP2_SRAM_PA;
if (cpu_is_omap242x())
--
1.7.9.5
--
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.html
[PATCH 3/8] ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5
The soc_ops for dra7xx devices can be completed reused
from the ones used for omap4 and omap5 devices.
Signed-off-by: Rajendra Nayak
Signed-off-by: R Sricharan
---
arch/arm/mach-omap2/omap_hwmod.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..f6eb29b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4113,7 +4113,7 @@ void __init omap_hwmod_init(void)
soc_ops.assert_hardreset = _omap2_assert_hardreset;
soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
- } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+ } else if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
--
1.7.9.5
--
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.html
[PATCH 7/8] ARM: DRA7: board-generic: Add basic DT support
From: R Sricharan
Describe minimal DT boot machine details for DRA7xx based SoC's. DRA7xx
family is based on dual core ARM CORTEX A15 using GIC as the interrupt
controller.
The PRCM and timer infrastructure is reused from OMAP5 and so are the io
descriptor tables.
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
---
.../devicetree/bindings/arm/omap/omap.txt |3 +++
arch/arm/mach-omap2/board-generic.c| 18 ++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 6d498c7..91b7049 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -59,3 +59,6 @@ Boards:
- AM43x EPOS EVM
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
+
+- DRA7 EVM: Software Developement Board for DRA7XX
+ compatible = "ti,dra7-evm", "ti,dra7"
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e5fbfed..92f8dd3 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -201,3 +201,21 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device
Tree)")
.dt_compat = am43_boards_compat,
MACHINE_END
#endif
+
+#ifdef CONFIG_SOC_DRA7XX
+static const char *dra7xx_boards_compat[] __initdata = {
+ "ti,dra7",
+ NULL,
+};
+
+DT_MACHINE_START(DRA7XX_DT, "Generic DRA7XX (Flattened Device Tree)")
+ .reserve= omap_reserve,
+ .smp= smp_ops(omap4_smp_ops),
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+ .init_time = omap5_realtime_timer_init,
+ .dt_compat = dra7xx_boards_compat,
+MACHINE_END
+#endif
--
1.7.9.5
--
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.html
[PATCH 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
From: R Sricharan
The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture integrated on a 28-nm technology.
DRA7xx family is composed of DRA75x and DRA74x devices.
Adding the DRA752 ES1.0 cpu revision detection support.
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap1/include/mach/soc.h |1 +
arch/arm/mach-omap2/id.c | 30 ++--
arch/arm/mach-omap2/soc.h | 39
3 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/include/mach/soc.h
b/arch/arm/mach-omap1/include/mach/soc.h
index 6cf9c1c..612bd1c 100644
--- a/arch/arm/mach-omap1/include/mach/soc.h
+++ b/arch/arm/mach-omap1/include/mach/soc.h
@@ -195,6 +195,7 @@ IS_OMAP_TYPE(1710, 0x1710)
#define cpu_is_omap34xx() 0
#define cpu_is_omap44xx() 0
#define soc_is_omap54xx() 0
+#define soc_is_dra7xx()0
#define soc_is_am33xx()0
#define cpu_class_is_omap1() 1
#define cpu_class_is_omap2() 0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..332ae95 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -61,7 +61,7 @@ int omap_type(void)
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
- } else if (soc_is_omap54xx()) {
+ } else if (soc_is_omap54xx() || soc_is_dra7xx()) {
val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
val &= OMAP5_DEVICETYPE_MASK;
val >>= 6;
@@ -116,7 +116,7 @@ static u16 tap_prod_id;
void omap_get_die_id(struct omap_die_id *odi)
{
- if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+ if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -606,6 +606,32 @@ void __init omap5xxx_check_revision(void)
pr_info("%s %s\n", soc_name, soc_rev);
}
+void __init dra7xx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode >> 12) & 0x;
+ rev = (idcode >> 28) & 0xff;
+ switch (hawkeye) {
+ case 0xb990:
+ switch (rev) {
+ case 0:
+ default:
+ omap_revision = DRA752_REV_ES1_0;
+ }
+ break;
+ default:
+ /* Unknown. Default to latest silicon revision */
+ omap_revision = DRA752_REV_ES1_0;
+ }
+
+ pr_info("DRA%03x ES%d.%d\n", omap_rev() >> 16,
+ ((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf));
+}
+
/*
* Set up things for map_io and processor detection later on. Gets called
* pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..0d242f1 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -8,6 +8,7 @@
* Written by Tony Lindgren
*
* Added OMAP4/5 specific defines - Santosh Shilimkar
+ * Added DRA7xxx specific defines - Sricharan R
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -105,6 +106,15 @@
# endif
#endif
+#ifdef CONFIG_SOC_DRA7XX
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME DRA7XX
+# endif
+#endif
+
/*
* Omap device type i.e. EMU/HS/TST/GP/BAD
*/
@@ -145,6 +155,7 @@ static inline int soc_is_omap(void)
* cpu_is_omap446x(): True for OMAP4460
* cpu_is_omap447x(): True for OMAP4470
* soc_is_omap543x(): True for OMAP5430, OMAP5432
+ * soc_is_dra75x():True for DRA752, DRA754, DRA756
*/
#define GET_OMAP_CLASS (omap_rev() & 0xff)
@@ -170,6 +181,12 @@ static inline int is_ti ##class (void) \
return (GET_TI_CLASS == (id)) ? 1 : 0; \
}
+#define IS_DRA_CLASS(class, id)\
+static inline int is_dra ##class(void) \
+{ \
+ return (GET_OMAP_CLASS == (id)) ? 1 : 0;\
+}
+
#define GET_OMAP_SUBCLASS ((omap_rev() >> 20) & 0x0fff)
#define IS_OMAP_SUBCLASS(subclass, id) \
@@ -190,6 +207,12 @@ static inline int is_am ##subclass (void) \
return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0; \
}
+#define IS_DRA_SUBCLASS(subclass, id) \
+static inline int is_dra ##subclass(void) \
+{ \
+
[PATCH 5/8] ARM: DRA7: Reuse io tables and add a new .init_early
From: R Sricharan
The IO descriptor tables for DRA7 are a complete reuse from OMAP5.
A new dra7xx_init_early() does the base address inits.
Signed-off-by: R Sricharan
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c | 22 --
arch/arm/mach-omap2/omap54xx.h |4
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 72cab3f..d226661 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -109,6 +109,7 @@ void omap3630_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
int omap2_common_pm_late_init(void);
+void dra7xx_init_early(void);
#ifdef CONFIG_SOC_BUS
void omap_soc_device_init(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index fe3253a..542e6bd 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -251,7 +251,7 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
};
#endif
-#ifdef CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
static struct map_desc omap54xx_io_desc[] __initdata = {
{
.virtual= L3_54XX_VIRT,
@@ -333,7 +333,7 @@ void __init omap4_map_io(void)
}
#endif
-#ifdef CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
void __init omap5_map_io(void)
{
iotable_init(omap54xx_io_desc, ARRAY_SIZE(omap54xx_io_desc));
@@ -653,6 +653,24 @@ void __init omap5_init_early(void)
}
#endif
+#ifdef CONFIG_SOC_DRA7XX
+void __init dra7xx_init_early(void)
+{
+ omap2_set_globals_tap(DRA7XX_CLASS,
+ OMAP2_L4_IO_ADDRESS(DRA7XX_TAP_BASE));
+ omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ OMAP2_L4_IO_ADDRESS(DRA7XX_CTRL_BASE));
+ omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
+ omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE),
+OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
+ omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+ omap_prm_base_init();
+ omap_cm_base_init();
+ dra7xx_check_revision();
+}
+#endif
+
+
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
diff --git a/arch/arm/mach-omap2/omap54xx.h b/arch/arm/mach-omap2/omap54xx.h
index a086ba1..2d35c57 100644
--- a/arch/arm/mach-omap2/omap54xx.h
+++ b/arch/arm/mach-omap2/omap54xx.h
@@ -30,4 +30,8 @@
#define OMAP54XX_CTRL_BASE 0x4a002800
#define OMAP54XX_SAR_RAM_BASE 0x4ae26000
+#define DRA7XX_CM_CORE_AON_BASE0x4a005000
+#define DRA7XX_CTRL_BASE 0x4a003400
+#define DRA7XX_TAP_BASE0x4ae0c000
+
#endif /* __ASM_SOC_OMAP54XX_H */
--
1.7.9.5
--
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.html
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On Tuesday 09 July 2013 02:03 AM, Nishanth Menon wrote:
On 19:12-20130708, Sourav Poddar wrote:
[..]
generic comment, given our historical mistakes of making drivers
specific to a SoC family, it never is.
Now, ti-qspi in file name is a step in the right direction, but, rest
of the code(function names etc) is just married to DRA7 family of
processor, when it should not be.
Make sense. Will change apis accordingly.
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
new file mode 100644
index 000..430de9c
--- /dev/null
+++ b/drivers/spi/spi-ti-qspi.c
[...]
+static inline unsigned long dra7xxx_readl(struct dra7xxx_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi->base + reg);
+}
+
+static inline void dra7xxx_writel(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi->base + reg);
+}
+
+static inline unsigned long dra7xxx_readl_data(struct dra7xxx_qspi *qspi,
+ unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ return readw(qspi->base + reg);
+ break;
+ case 16:
+ return readb(qspi->base + reg);
+ break;
+ case 32:
+ return readl(qspi->base + reg);
+ break;
+ default:
+ return -1;
+ }
+}
+
+static inline void dra7xxx_writel_data(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ writew(val, qspi->base + reg);
+ break;
+ case 16:
+ writeb(val, qspi->base + reg);
+ break;
+ case 32:
+ writeb(val, qspi->base + reg);
+ break;
+ default:
+ dev_dbg(qspi->dev, "word lenght out of range");
+ break;
+ }
+}
Looks like a case to use regmap?
Dumb q: why cant we use regmap_spi? worst case, you should be able to
use mmio if regmap_spi cant be used. The commit message was not clear
about this.
MMIO can be used as this controller supports memory mapped port, but that
will be addition/enhancement on top of this.
This driver is adding qspi controller read/write support in SPI mode.
+
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(spi->master);
+ int clk_div = 0;
+ u32 clk_ctrl_reg, clk_rate;
+
+ clk_rate = clk_get_rate(qspi->fclk);
+
+ if (!qspi->spi_max_frequency) {
+ dev_err(qspi->dev, "spi max frequency not defined\n");
+ return -1;
+ } else
+ clk_div = (clk_rate / qspi->spi_max_frequency) - 1;
did you run checkpatch --strict here?
Didn,t do the strict, yes will add braces.
Also, would you prefer to use DIV_ROUND_UP?
Ok.
+
+ dev_dbg(qspi->dev, "%s: hz: %d, clock divider %d\n", __func__,
+ qspi->spi_max_frequency, clk_div);
+
+ pm_runtime_get_sync(qspi->dev);
error check?
Will add.
+
+ clk_ctrl_reg = dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ clk_ctrl_reg&= ~QSPI_CLK_EN;
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, clk_ctrl_reg, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div< 0) {
+ dev_dbg(qspi->dev, "%s: clock divider< 0, using /1 divider\n",
+ __func__);
+ clk_div = 1;
should you not fail here?
May be yes.
+ }
+
+ if (clk_div> QSPI_CLK_DIV_MAX) {
+ dev_dbg(qspi->dev, "%s: clock divider>%d , using /%d divider\n",
+ __func__, QSPI_CLK_DIV_MAX, QSPI_CLK_DIV_MAX + 1);
+ clk_div = QSPI_CLK_DIV_MAX;
should you not fail here?
Yup.
+ }
+
+ /* enable SCLK */
+ dra7xxx_writel(qspi, QSPI_CLK_EN | clk_div, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ pm_runtime_mark_last_busy(qspi->dev);
+ pm_runtime_put_autosuspend(qspi->dev);
error check?
Will add.
+
+ return 0;
+}
+
+static int dra7xxx_qspi_prepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_get_sync(qspi->dev);
error check?
Will add.
+
+ return 0;
+}
+
+static int dra7xxx_qspi_unprepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_mark_last_busy(qspi->dev);
+ pm_runtime_put_autosuspend(qspi->dev);
error check?
Will add.
+
+ return 0;
+}
+
+static int qspi_write_msg(struct dra7xxx_qspi *qspi, struct spi_transfer *t)
+{
+ const u8 *txbuf;
+ int wlen, count;
+
+ count = t->len;
+ txbuf = t->tx_buf;
+ wlen = t->bits_per_word;
+
+ while (count--) {
+ dev_dbg(qspi->dev, "tx cmd %08x dc %08x data %02x\n",
+ qspi->cmd | QSPI_WR_SNGL, qspi->dc, *txbuf);
+ dra7xxx_writel
Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
On Tuesday 09 July 2013 12:12 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
>> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>> I wonder if this is because the timeouts get now initialized to 0
>> instead
>> of -1 for the serial driver?
>>
>
> You meant initialized to -1, right? There's an additional check for
> timeout being 0. Unless i
> am missing something DT-boot will start off with timeout set to 0 and
> then get forced to -1.
>>>
>>> OK
>>
>> Issue 2: Causing boot to stop when serial driver is initialized.
>> (After Issue 1 is fixed)
>>
>> I could narrow this down to the change done to return -EINVAL
>> instead of 0 in serial_omap_get_context_loss_count() as part of
>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>> Fix device tree based PM runtime"
>>
>> What this change in turn seems to do is cause a
>> serial_omap_restore_context() to get called as part of
>> serial_omap_runtime_resume() which was not the case when
>> serial_omap_get_context_loss_count() returned 0
>>
>> from serial_omap_runtime_resume():
>> -
>> int loss_cnt = serial_omap_get_context_loss_count(up);
>>
>> if (loss_cnt < 0) {
>> dev_dbg(dev, "serial_omap_get_context_loss_count failed
>> : %d\n",
>> loss_cnt);
>> serial_omap_restore_context(up);
>> } else if (up->context_loss_cnt != loss_cnt) {
>> serial_omap_restore_context(up);
>> }
>> -
>>
>> I am still working on why a serial_omap_restore_context() could
>> have caused console to die. I will work with Sourav on this and
>> post the fixes for both issue 1 and issue2 once its clear on whats
>> really causing issue 2.
>
> That's because we don't have the omap specific pdata callbacks for
> context loss any longer. We may be able to detect when the context
> was really lost in the serial driver, and only then call the
> serial_omap_restore_context().
Right, but calling serial_omap_restore_context() even when the context
is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>
>> This could be a problem for drivers which do a save context in
>> ->runtime_suspend()
>> but from what I see with omap serial, there is no save context done as part
>> of
>> ->runtime_suspend.
>
> right, because context is "saved" in set_termios. probe() will get
> called much before set_termios() has a chance to run, right ?
>
> Same problem will trigger in that case.
>
> I still think patch below is necessary
Right, I'll try some on those lines. Looks like a pm_runtime_set_active() is
done
for the console in the non DT case in omap_serial_init_port(). It seems to be
missing in the DT case.
Although I feel this should fix the issue we have right now, I wonder if there
could
ever be a case with uart being suspended and having to resume again before a
set_termios? What I mean to ask is, if the omap serial driver assuming a resume
to
happen only post a set_termios is always valid.
>
>>> (completely untested, didn't even try to compile, just to illustrate)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>>> b/arch/arm/mach-omap2/omap_hwmod.c
>>> index 7341eff..d8dca68 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct
>>> omap_hwmod *oh)
>>> (postsetup_state == _HWMOD_STATE_IDLE)) {
>>> oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>> postsetup_state = _HWMOD_STATE_ENABLED;
>>> +
>>> + /* tell pm_runtime this device is already active */
>>> + pm_runtime_set_active(&oh->od->pdev->dev);
>>> + } else {
>>> + /* tell pm_runtime this device is trully suspended */
>>> + pm_runtime_set_suspended(&oh->od->pdev->dev);
>>> }
>>>
>>> if (postsetup_state == _HWMOD_STATE_IDLE)
>
--
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.kerne
Re: [PATCH 0/5] Add phy support for AM335X platform using Generic PHy framework
On 07/08/2013 10:34 PM, Ezequiel Garcia wrote: > Hi, Hi, > On Mon, Jul 08, 2013 at 09:44:33PM +0200, Sebastian Andrzej Siewior wrote: > >> We need two nodes each one with a glue layer and a musb child node. The >> instances crap in kernel has to vanish. Also that means your phy nodes >> are wrong. This is not musb with two ports but two musb instances each >> with one port. >> > > I agree completely. The current DT representation looks definitely odd, > and we should be looking at improving it. > > I wonder if this is now possible, given the DT is supposed to be stable ABI. I posted this [0] and Felipe + Benoit were pro change. I am still not sure if this is okay or just one glue layer per instance so I delay this until I am sure. Stable or not, what currently have in is beyond broken and it can't be fixed in kernel. I would add some code to check for the old nodes and give a proper warning and how to react. This should reduce the pain full search. [0] http://git.breakpoint.cc/cgit.cgi/bigeasy/linux.git/commit/?h=am335x_usb&id=0a60cd77ee50edd8cd07cbd699ed67b2c4b2ab93 Sebastian -- 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.html
