On Wed, 19 Oct 2011 17:18:54 +1100
"Paul Chiha" wrote:
> Hi,
>
> I need to write a simple driver sends and receives packets over McBSP3
> on the DM3730 processor, and was wondering if anyone has already this.
> I understand that the functions in arch/arm/plat-omap/mcbsp.c need to be
> used, and
Hi Govindraj,
On Wed, Oct 19, 2011 at 11:05:02, Mohammed, Afzal wrote:
> Hi Govindraj,
>
> On Tue, Oct 18, 2011 at 21:05:41, R, Govindraj wrote:
> > If OMAP UART is used as console uart and debug is enabled,
> > avoid gating of uart clocks to print all debug prints.
> :
> :
> >
Hi,
I need to write a simple driver sends and receives packets over McBSP3
on the DM3730 processor, and was wondering if anyone has already this.
I understand that the functions in arch/arm/plat-omap/mcbsp.c need to be
used, and so I would like to see an example driver which uses them that
I can b
Hi Govindraj,
On Tue, Oct 18, 2011 at 21:05:41, R, Govindraj wrote:
> If OMAP UART is used as console uart and debug is enabled,
> avoid gating of uart clocks to print all debug prints.
:
:
> console_uart_id = uart->num;
>
> + if (cmdline_find_option("d
On Tue, Oct 18, 2011 at 05:00:46PM +0100, Mark Brown wrote:
> On Tue, Oct 18, 2011 at 07:58:37PM +0800, Shawn Guo wrote:
>
> > I understand that ideally device tree is supposed to describe pure
> > hardware configurations. But practically, when migrating a driver
> > to device tree probe, we are
Greetings Kevin/Paul,
We have been working to understand omap powerdomain concepts. We used a couple
of use cases (i.e. cpuidle, cpufreq etc.) to see how omap handles them. We saw
that the leaf functions in such use cases interact with defined
powerdomain/clockdomain that talks with hardware di
On Tue, Oct 18, 2011 at 8:36 PM, Kyle Manna wrote:
> Looks like you're missing one more section for OMAP3. Will reply with
> a complete patch I was about to submit.
>
Yes, I added all the ones I need to compile my board correctly, but I
could have missed one of them.
Perfect, feel free to add th
Depending on the archs defined in the config, some functions are
referenced without being defined. This fixes compile time errors that
would otherwise result.
Signed-off-by: Kyle Manna
---
arch/arm/mach-omap2/io.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --gi
Add hwmod support to enable access to UART4 of the AM35xx series of
chips. The UART4 device referenced from the TRM will show up as ttyO3.
This was tested on an AM3505.
Signed-off-by: Kyle Manna
---
arch/arm/mach-omap2/clock3xxx_data.c | 11 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_d
Looks like you're missing one more section for OMAP3. Will reply with
a complete patch I was about to submit.
@@ -382,11 +387,14 @@ void __init omap2430_init_early(void)
omap_hwmod_init_postsetup();
omap2430_clk_init();
}
+#endif
/*
* Currently only board-omap3beagle.c should
On Tue, Oct 18, 2011 at 07:58:37PM +0800, Shawn Guo wrote:
> I understand that ideally device tree is supposed to describe pure
> hardware configurations. But practically, when migrating a driver
> to device tree probe, we are trying to move the configurations
> described by platform_data into de
From: Jon Hunter
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
The secound timeou
The custom hwmod activate and deactivate funcs does hwmod_enable
and idle same can be done with omap_device generic API's.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c | 18 ++
1 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/se
If no_console_suspend is used we have prevent uart idling during suspend
to provide debug prints.
Power domain hooks can idle uarts if left enabled during system wide suspend
so re-use the omap_device_disable_idle_on_suspend API's to ensure console_uart
is not idled during suspend.
omap_device_di
If OMAP UART is used as console uart and debug is enabled,
avoid gating of uart clocks to print all debug prints.
If uart clocks are gated then the debug prints from omap_device
framework or hwmod framework can cause uart to enter recursive
pm_runtime calls, which can cause a deadlock over power l
Omap-uart can be used as console uart to print early boot
messages using earlyprintk so for console uart prevent
hwmod reset or idling during bootup.
Identify the console_uart set the id and use the custom
pm_latency ops for console uart for the first time
to idle console uart left enabled from bo
Reuse the num_uarts variable itself to count number of uarts.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 55ce950..e1eba7f 100644
--- a
Omap_uart_can_sleep function blocks system wide low power state until
uart is active remove this func and add qos requests to prevent
MPU from transitioning while uart is active and remove qos request
if uart is auto-idled.
qos requests are blocking notifier calls so put these requests to
work que
From: Deepak K
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The auto suspend delay th
Add missing uart regs to uart_port structure which can be used in
context restore. Store dll, dlh, mdr1, scr, efr, lcr, mcr reg values
into uart_port structure while configuring individual port in termios
function.
Signed-off-by: Govindraj.R
---
arch/arm/plat-omap/include/plat/omap-serial.h |
With runtime adaptation done remove clock_enable/disbale API's
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c | 36
1 files changed, 0 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
inde
>From the runtime callbacks enable hwmod wakeups for uart which will
internally enable io-pad wakeups for uarts if they have rx-pad pins
set as wakeup capabale.
Use the io-ring wakeup mechanism after uart clock gating and leave
the PM_WKST set for uart to default reset values cleanup the
code in s
Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.
Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as from on errata will be handled in driver file itself.
Correc
Adapts omap-serial driver to use pm_runtime API's.
Use runtime runtime API's to handle uart clocks and obtain
device_usage statics. Set runtime API's usage to irq_safe so that
we can use get_sync from irq context. Auto-suspend for port specific
activities and put for reg access. Moving suspend/resu
Avoid unconditional context restore every time we gate uart
clocks. Check whether context loss happened based on which
we can context restore uart regs from uart_port structure.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c |2 ++
arch/arm/plat-omap/include/pla
Remove the uart reset function which is configuring the
TX empty irq which can now be handled within omap-serial driver.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c | 14 --
arch/arm/plat-omap/include/plat/omap-serial.h |2 ++
drivers/tty/serial
Remove context save function from serial.c and move context restore
function to omap-serial. Remove all regs stored in omap_uart_state
for contex_save/restore, reg read write funcs used in context_save/restore,
io_addresses populated for read/write funcs.
Clock gating mechanism was done in serial.
Padconf wakeup is used to wakeup uart after uart fclks/iclks are gated.
Rx-Pad wakeup was done by writing to rx-pad offset value populated in
serial.c idle_init. Remove the direct reading and writing into rx pad.
Remove the padconf field part of omap_uart_state struct and pad offsets
populated.
No
We had been using traditional 8250 driver as uart console driver
prior to omap-serial driver. Since we have omap-serial driver
in mainline kernel for some time now it has been used as default
uart console driver on omap2+ platforms. Remove 8250 support for
omap-uarts.
Serial_in and serial_out over
In preparation to UART runtime conversion remove uart specific calls
from pm24xx/34xx files and their definition from serial.c
These func calls will no more be used with upcoming uart runtime design.
1.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks.
2.) omap_uart_enable
The mapbase (start_address), membase(io_remap cookie) part of
pdata struct omap_uart_port_info are removed as this should be
derived within driver.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c |2 --
arch/arm/plat-omap/include/plat/omap-serial.h |2 --
dri
Currently we use a shared irq handler to identify uart activity and then
trigger a timer. By default the timeout value is zero and can be set or
modified from sysfs. If there was no uart activity for the period set
through sysfs, the timer will expire and call timer handler this will
set a flag can
Converting uart driver to adapt to pm runtime API's.
Code re-org + cleanup.
Moving some functionality from serial.c to omap-serial.c
Changes involves:
1.) Cleaning up certain uart calls from sram_idle func.
2.) Removed all types of uart clock handling code from serial.c
3.) Using
On Mon, Oct 10, 2011 at 09:49:38PM +0530, Rajendra Nayak wrote:
> Device nodes in DT can associate themselves with one or more
> regulators/supply by providing a list of phandles (to regulator nodes)
> and corresponding supply names.
>
> For Example:
> devicenode: node@0x0 {
>
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> The helper routine is meant to be used by regulator drivers
> to extract the regulator_init_data structure from the data
> that is passed from device tree.
> 'consumer_supplies' which is part of regulator_init_data is not extracted
>
Hi,
On Tue, Oct 18 2011, Subhash Jadavani wrote:
> Chris,
>
> I had already posted the proper patch with signed off:
> http://permalink.gmane.org/gmane.linux.ports.arm.msm/1875
Thanks, you're right. I've pushed it to mmc-next for 3.2 now,
after changing the 0x2 over to UHS_SDR50_BUS_SPEED.
- Ch
On Mon, Oct 17, 2011 at 09:47:17AM +0530, Rajendra Nayak wrote:
>
> >I do not see that of_get_regulation_constraints() covers the following
> >fields. We do not support them for DT probe?
>
> I left these out as I wasn't sure how such (if at all) Linux
> specific params should be passed through
Hi Keshava,
On Tue, Oct 18, 2011 at 11:37:28AM +0530, Munegowda, Keshava wrote:
> On Thu, Oct 13, 2011 at 11:02 PM, Felipe Balbi wrote:
> > On Tue, Oct 11, 2011 at 01:23:29PM +0530, Keshava Munegowda wrote:
> >> From: Keshava Munegowda
> >>
> >> The usbhs core driver does not enable/disable the
38 matches
Mail list logo
