Re: [PATCH 00/15] OMAPDSS: remove old panel model code
On 29/08/13 17:35, Archit Taneja wrote: On Thursday 29 August 2013 07:01 PM, Tomi Valkeinen wrote: Here's a series removing all the old panel model code from the omapdss driver. This series depends on the series that changes the board files to use the new panel drivers. There's nothing much special in this series, as it's mostly removing code that is not used. There are also related cleanups, like making functions static if they are no longer called from outside the file, and such. Tested on OMAP4 SDP, OMAP4 Panda, OMAP3 Beagle, OMAP3 Beagle xM. This series can also be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 3.12/dss-legacy-removal For the series: Reviewed-by: Archit Taneja arc...@ti.com Acked-by: Archit Taneja arc...@ti.com Thanks for review. I've updated the branch in my git tree. You may want to rebase your HDMI work on top of this branch at some point. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
Hi Chanwoo,
On 8/30/2013 5:41 AM, Chanwoo Choi wrote:
Hi George,
On 08/29/2013 10:45 PM, George Cherian wrote:
Hi Chanwoo,
On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
I tested various development board based on Samsung Exynos series SoC.
Although some gpio of Exynos series SoC set high state(non zero, 1) as default
value,
this gpio state could mean off state, disconnected or un-powered state
according to gpio.
Of course, above explanation about specific gpio don't include all gpios.
This is meaning that there is possibility.
okay then how about adding a flag for inverted logic too. something like this
if(of_property_read_bool(np,inverted_gpio))
gpio_usbvid-gpio_inv = 1;
And always check on this before deciding?
Is this fine ?
OK.
But, as Stephen commented on other mail, you should use proper DT helper
function.
okay
Second,
gpio_usbvid_set_initial_state() dertermine both USB-HOST and USB cable
state at same time
in 'case ID_DETCT' according to 'gpio_usbvid-id_gpio'. But, I think that other
extcon devices
would not control both USB-HOST and USB cable state at same time.
Other extcon devices would support either USB-HOST or USB cable.
The driver has 2 configurations.
1) supports implementations with both VBUS and ID pin are routed via gpio's for
swicthing roles(compatible gpio-usb-vid).
As you explained about case 1, it is only used on dra7x SoC.
No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via gpio.
Other SoC could not wish to control both USB-HOST and USB cable at same
time.
I could'nt actually parse this. You meant since the id_irq_handler handles both
USB and USB-HOST cable
its not proper?
It's not proper in general case. The generic driver must guarantee all of
extcon device using gpio.
As far as I know, the generic driver cannot direclty control gpio pin and get
value from gpio pin.
Almost device driver including in kernel/drivers control gpio pin on specific
device driver
instead of generic driver.
But without reading the gpio value how can we set the cable states? for
this driver the assumption is the dedicated gpio
is always DIR_IN and in the driver we just read the value.
I need your answer about above my opinion for other SoC.
So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
{
int id_current, vbus_current;
id_current = gpio_get_value_cansleep(gpio_usbvid-id_gpio);
if (!!id_current == ID_FLOAT)
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST, false);
else
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST, true);
vbus_current = gpio_get_value_cansleep(gpio_usbvid-vbus_gpio);
if (!!vbus_current == VBUS_ON)
extcon_set_cable_state(gpio_usbvid-edev, USB, true);
else
extcon_set_cable_state(gpio_usbvid-edev, USB, false);
}
and the irq handlers like this
static irqreturn_t id_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int id_current;
id_current = gpio_get_value_cansleep(gpio_usbvid-id_gpio);
if (id_current == ID_GND)
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST, true);
else
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST, false);
return IRQ_HANDLED;
}
static irqreturn_t vbus_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int vbus_current;
vbus_current = gpio_get_value_cansleep(gpio_usbvid-vbus_gpio);
if (vbus_current == VBUS_OFF)
extcon_set_cable_state(gpio_usbvid-edev, USB, false);
else
extcon_set_cable_state(gpio_usbvid-edev, USB, true);
return IRQ_HANDLED;
}
I know your intention dividing interrupt handler for each cable.
But I don't think this driver must guarantee all of extcon device using gpio.
For example,
below three SoC wish to detect USB/USB-HOST cable with each different methods.
SoC A wish to detect USB/USB-HOST cable through only one gpio pin.
You mean to say that both USB ID pin and VBUS are connected to same gpio?
If so that is a really bad h/w design and it will not fly.
Or, you meant that only USB ID pin is connected to single gpio and it
controls the state of the USB/USB-HOST cables?
If so thats what exactly the v3 driver did with compatible gpio-usb-id.
SoC B wish to detect USB/USB-HOST cable through ADC value instead of gpio pin.
Via ADC this driver should never be used , it should be
extcon-adc-usbvid driver and not extcon-gpio-usbvid driver.
SoC C wish to detect USB/USB-HOST cable through two gpio pin because USB
connected on gpio an USB-HOST connected on another.
Whatever modifications above should meet this need in combination with
named gpios (id_gpio and vbus_gpio in dt)as stephen pointed.
But still i feel the above
omap: panda rcu stall on 3.10.1
This also went to: linaro-ker...@lists.linaro.org
Hi,
current linaro kernel on 13.07 (3.10.1.0-1-linaro-omap) shows stack
below. System is generally quite unstable. Light usage (postfix+dovecot...)
Full dmesg here:
https://dl.dropboxusercontent.com/u/21820416/rcu.stall.panda
Rgds,
Chris
[ 4538.880432] INFO: rcu_sched detected stalls on CPUs/tasks: { 1}
(detected by 0, t=2103 jiffies, g=1649, c=1648, q=18)
[ 4538.891723] Backtrace for cpu 0 (current):
[ 4538.891723] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
[ 4538.891754] [c001175d] (unwind_backtrace+0x1/0x9c) from
[c000f625] (show_stack+0x11/0x14)
[ 4538.891815] [c000f625] (show_stack+0x11/0x14) from [c00106d5]
(smp_send_all_cpu_backtrace+0x49/0x98)
[ 4538.891815] [c00106d5] (smp_send_all_cpu_backtrace+0x49/0x98) from
[c007c755] (rcu_check_callbacks+0x439/0x4ac)
[ 4538.891815] [c007c755] (rcu_check_callbacks+0x439/0x4ac) from
[c0036599] (update_process_times+0x2d/0x4c)
[ 4538.891876] [c0036599] (update_process_times+0x2d/0x4c) from
[c005fcfd] (tick_sched_handle+0x35/0x40)
[ 4538.891906] [c005fcfd] (tick_sched_handle+0x35/0x40) from
[c005feed] (tick_sched_timer+0x31/0x54)
[ 4538.891937] [c005feed] (tick_sched_timer+0x31/0x54) from
[c004532b] (__run_hrtimer+0x5b/0x138)
[ 4538.891937] [c004532b] (__run_hrtimer+0x5b/0x138) from [c0045bcb]
(hrtimer_interrupt+0xdb/0x22c)
[ 4538.891967] [c0045bcb] (hrtimer_interrupt+0xdb/0x22c) from
[c0010e13] (twd_handler+0x1b/0x28)
[ 4538.891998] [c0010e13] (twd_handler+0x1b/0x28) from [c00783b9]
(handle_percpu_devid_irq+0x4d/0xac)
[ 4538.891998] [c00783b9] (handle_percpu_devid_irq+0x4d/0xac) from
[c0075ead] (generic_handle_irq+0x19/0x24)
[ 4538.892028] [c0075ead] (generic_handle_irq+0x19/0x24) from
[c000d16d] (handle_IRQ+0x29/0x68)
[ 4538.892059] [c000d16d] (handle_IRQ+0x29/0x68) from [c00084db]
(gic_handle_irq+0x27/0x50)
[ 4538.892059] [c00084db] (gic_handle_irq+0x27/0x50) from [c045315b]
(__irq_svc+0x3b/0x5c)
[ 4538.892059] Exception stack(0xc06e3f68 to 0xc06e3fb0)
[ 4538.892059] 3f60:
c06e2000 c075f130
[ 4538.892120] 3f80: c06e2000 c075ea93 c075f130 c06ea594 c045c2e0
c06e2000 c0fe5908 c06e3fb0
[ 4538.892120] 3fa0: c007bab1 c0058b48 400f0133
[ 4538.892120] [c045315b] (__irq_svc+0x3b/0x5c) from [c0058b48]
(cpu_startup_entry+0xbc/0x164)
[ 4538.892120] [c0058b48] (cpu_startup_entry+0xbc/0x164) from
[c06735f9] (start_kernel+0x251/0x2ac)
[ 4538.892120]
[ 4538.892120] sending IPI to all other CPUs:
[ 4538.892211] IPI backtrace for cpu 1
[ 4538.892211]
[ 4538.892242] CPU: 1 PID: 2064 Comm: clamd Not tainted
3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
[ 4538.892242] task: edb09500 ti: ec91e000 task.ti: ec91e000
[ 4538.892272] PC is at 0xb6e2f0d4
[ 4538.892272] LR is at 0xb6eeec01
[ 4538.892272] pc : [b6e2f0d4]lr : [b6eeec01]psr: 000f0130
[ 4538.892272] sp : be8b472c ip : 62323337 fp : 684a
[ 4538.892303] r10: 0084d750 r9 : 0200 r8 : e86d6a2f
[ 4538.892303] r7 : 0a0a0a0a r6 : 69393e32 r5 : 0080bf24 r4 : 0080bf28
[ 4538.892333] r3 : 81010100 r2 : 6438 r1 : 000a r0 : 0080bf24
[ 4538.892333] Flags: nzcv IRQs on FIQs on Mode USER_32 ISA Thumb
Segment user
[ 4538.892333] Control: 50c5387d Table: acbd404a DAC:
[ 4538.892364]
[ 4538.892364] R8: 0xe86d69af:
[ 4538.892364] 69ac 6a6f7254 412e6e61 746e6567 3939332d 00303934
b1aa3270 2506 47a83ca7
[ 4538.892395] 69cc e4ebc453 91ad979e 23363f8b fd49d9d0 773b48ba
ad58f7d3 04c351eb 96e4414f
[ 4538.892395] 69ec 7e1a3ac7 f39072a5 e362cedb b119b3e0 b595375e
b2137762 b19f99a8 b10dc638
[ 4538.892395] 6a0c 1806 2e6e6957 6a6f7254 412e6e61 746e6567
3939332d 00303534 b23ade28
[ 4538.892395] 6a2c 1806 2e6e6957 6a6f7254 462e6e61 61656b61
37342d76 00373131 ac58376e
[ 4538.892395] 6a4c 72542e6e 6e616a6f 3434382e 35313336 3e55c600
412e6eb2 72617764 61472e65
[ 4538.892517] 6a6c 6176656d 2d65636e 34393132 55b20037 1604b173
2e6e6957 6a6f7254 462e6e61
[ 4538.892547] 6a8c 61656b61 37342d76 00343131 b652e2c0 72542e6e
6e616a6f 7075532e 756a7265
[ 4538.892547] 6aac 322d6e61 fb003731 15b23a2b 2e6e6957 6a6f7254
412e6e61 746e6567 3939332d
[ 4538.892547] CPU: 1 PID: 2064 Comm: clamd Not tainted
3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
[ 4538.892547] [c001175d] (unwind_backtrace+0x1/0x9c) from
[c000f625] (show_stack+0x11/0x14)
[ 4538.892639] [c000f625] (show_stack+0x11/0x14) from [c0010819]
(handle_IPI+0xd5/0x158)
[ 4538.892669] [c0010819] (handle_IPI+0xd5/0x158) from [c00084ff]
(gic_handle_irq+0x4b/0x50)
[ 4538.892669] [c00084ff] (gic_handle_irq+0x4b/0x50) from [c0453369]
(__irq_usr+0x49/0x60)
[ 4538.892700] Exception stack(0xec91ffb0 to 0xec91fff8)
[ 4538.892700] ffa0: 0080bf24
000a 6438 81010100
[ 4538.892730] ffc0: 0080bf28 0080bf24 69393e32 0a0a0a0a e86d6a2f
0200 0084d750 684a
[ 4538.892730] ffe0: 62323337 be8b472c b6eeec01 b6e2f0d4 000f0130
Re: [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver
On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote:
On Thu 29 August 2013 14:32:49 Archit Taneja wrote:
VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.
We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.
Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are added.
Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and stores
them in the buffer. There are also some VPDMA parameters like frame start and
line mode which needs to be configured, these are configured by direct register
writes via the VPDMA helper functions.
The driver's device_run() mem2mem op will add each descriptor based on how the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
upload MMR registers, start DMA of video buffers on the various input and output
clients/ports.
When the list is parsed completely(and the DMAs on all the output ports done),
an interrupt is generated which we use to notify that the source and destination
buffers are done.
The rest of the driver is quite similar to other mem2mem drivers, we use the
multiplane v4l2 ioctls as the HW support coplanar formats.
Signed-off-by: Archit Taneja arc...@ti.com
Thanks for the patch. Just a few small comments below...
---
drivers/media/platform/Kconfig | 16 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/ti-vpe/Makefile |5 +
drivers/media/platform/ti-vpe/vpe.c | 1740 ++
drivers/media/platform/ti-vpe/vpe_regs.h | 496 +
5 files changed, 2259 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/Makefile
create mode 100644 drivers/media/platform/ti-vpe/vpe.c
create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
new file mode 100644
index 000..85b0880
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/vpe.c
snip
+static int vpe_enum_fmt(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if (V4L2_TYPE_IS_OUTPUT(f-type))
+ return __enum_fmt(f, VPE_FMT_TYPE_OUTPUT);
+ else
The line above isn't necessary.
Oh right, thanks for spotting that.
+ return __enum_fmt(f, VPE_FMT_TYPE_CAPTURE);
+}
+
snip
+
+ pix-field = V4L2_FIELD_NONE;
+
+ v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
+ pix-height, MIN_H, MAX_H, H_ALIGN,
+ S_ALIGN);
+
+ pix-num_planes = fmt-coplanar ? 2 : 1;
+ pix-pixelformat = fmt-fourcc;
+ pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?
+ V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
pix-priv should be set to NULL as well.
I'll fix this.
snip
+}
+
+#define V4L2_CID_TRANS_NUM_BUFS(V4L2_CID_USER_BASE + 0x1000)
Reserve a control range for this driver in include/uapi/linux/v4l2-controls.h.
Similar to the ones already defined there.
That will ensure that controls for this driver have unique IDs.
Thanks, I took this from the mem2mem-testdev driver, a test driver
doesn't need to worry about this I suppose.
I had a query regarding this. I am planning to add a capture driver in
the future for a similar IP which can share some of the control IDs with
VPE. Is it possible for 2 different drivers to share the IDs?
Also, I noticed in the header that most drivers reserve space for 16
IDs. The current driver just has one, but there will be more custom ones
in the future. Is it fine if I reserve 16 for this driver too?
snip
+
+static int queue_init(void *priv, struct vb2_queue *src_vq,
+ struct vb2_queue *dst_vq)
+{
+ struct vpe_ctx *ctx = priv;
+ int ret;
+
+ memset(src_vq, 0, sizeof(*src_vq));
+ src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
+ src_vq-io_modes = VB2_MMAP;
+ src_vq-drv_priv = ctx;
+ src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
+ src_vq-ops = vpe_qops;
+ src_vq-mem_ops = vb2_dma_contig_memops;
+ src_vq-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
Shouldn't this be TIMESTAMP_COPY?
Right, it should be, I'll fix
Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
Hi George,
On 08/30/2013 03:15 PM, George Cherian wrote:
Hi Chanwoo,
On 8/30/2013 5:41 AM, Chanwoo Choi wrote:
Hi George,
On 08/29/2013 10:45 PM, George Cherian wrote:
Hi Chanwoo,
On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
I tested various development board based on Samsung Exynos series SoC.
Although some gpio of Exynos series SoC set high state(non zero, 1) as
default value,
this gpio state could mean off state, disconnected or un-powered state
according to gpio.
Of course, above explanation about specific gpio don't include all gpios.
This is meaning that there is possibility.
okay then how about adding a flag for inverted logic too. something like
this
if(of_property_read_bool(np,inverted_gpio))
gpio_usbvid-gpio_inv = 1;
And always check on this before deciding?
Is this fine ?
OK.
But, as Stephen commented on other mail, you should use proper DT helper
function.
okay
Second,
gpio_usbvid_set_initial_state() dertermine both USB-HOST and USB
cable state at same time
in 'case ID_DETCT' according to 'gpio_usbvid-id_gpio'. But, I think
that other extcon devices
would not control both USB-HOST and USB cable state at same time.
Other extcon devices would support either USB-HOST or USB cable.
The driver has 2 configurations.
1) supports implementations with both VBUS and ID pin are routed via
gpio's for swicthing roles(compatible gpio-usb-vid).
As you explained about case 1, it is only used on dra7x SoC.
No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via
gpio.
Other SoC could not wish to control both USB-HOST and USB cable at
same time.
I could'nt actually parse this. You meant since the id_irq_handler handles
both USB and USB-HOST cable
its not proper?
It's not proper in general case. The generic driver must guarantee all of
extcon device using gpio.
As far as I know, the generic driver cannot direclty control gpio pin and
get value from gpio pin.
Almost device driver including in kernel/drivers control gpio pin on
specific device driver
instead of generic driver.
But without reading the gpio value how can we set the cable states? for this
driver the assumption is the dedicated gpio
is always DIR_IN and in the driver we just read the value.
I need your answer about above my opinion for other SoC.
So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
{
int id_current, vbus_current;
id_current = gpio_get_value_cansleep(gpio_usbvid-id_gpio);
if (!!id_current == ID_FLOAT)
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST, false);
else
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST, true);
vbus_current = gpio_get_value_cansleep(gpio_usbvid-vbus_gpio);
if (!!vbus_current == VBUS_ON)
extcon_set_cable_state(gpio_usbvid-edev, USB, true);
else
extcon_set_cable_state(gpio_usbvid-edev, USB, false);
}
and the irq handlers like this
static irqreturn_t id_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int id_current;
id_current = gpio_get_value_cansleep(gpio_usbvid-id_gpio);
if (id_current == ID_GND)
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST,
true);
else
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST,
false);
return IRQ_HANDLED;
}
static irqreturn_t vbus_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int vbus_current;
vbus_current = gpio_get_value_cansleep(gpio_usbvid-vbus_gpio);
if (vbus_current == VBUS_OFF)
extcon_set_cable_state(gpio_usbvid-edev, USB, false);
else
extcon_set_cable_state(gpio_usbvid-edev, USB, true);
return IRQ_HANDLED;
}
I know your intention dividing interrupt handler for each cable.
But I don't think this driver must guarantee all of extcon device using gpio.
For example,
below three SoC wish to detect USB/USB-HOST cable with each different
methods.
SoC A wish to detect USB/USB-HOST cable through only one gpio pin.
You mean to say that both USB ID pin and VBUS are connected to same gpio?
If so that is a really bad h/w design and it will not fly.
Or, you meant that only USB ID pin is connected to single gpio and it
controls the state of the USB/USB-HOST cables?
If so thats what exactly the v3 driver did with compatible gpio-usb-id.
My original question intention,
I'd like you to answer that this driver can support all case of SoC A/SoC
B/SoC C without othe implementation?
SoC B wish to detect USB/USB-HOST cable through ADC value instead of gpio
pin.
Via ADC this driver should never be used , it should be extcon-adc-usbvid
driver and not extcon-gpio-usbvid
Fwd: Re: current panda omap kernel stacks
Hi, please see the current issues I found on panda running 3.10.1.0-1-linaro-omap https://dl.dropboxusercontent.com/u/21820416/panda.syslog.gz https://dl.dropboxusercontent.com/u/21820416/panda-dmesg System is generally very unstable. RCU stall sent in different thread Chris Original Message Subject:Re: current panda omap kernel stacks Date: Tue, 27 Aug 2013 21:11:12 +0200 From: Christian Hoffmann chrmhoffm...@gmail.com To: linaro-ker...@lists.linaro.org Forgot to attach syslog here: https://dl.dropboxusercontent.com/u/21820416/panda.syslog.gz On Tue, Aug 27, 2013 at 9:09 PM, Christian Hoffmann chrmhoffm...@gmail.com mailto:chrmhoffm...@gmail.com wrote: Sorry to reply to myself, but after a while the panda doesn't reply any more over network and the syslog has lots of entries like this one: Aug 27 13:00:38 panda kernel: [87136.303894] [c044c1e9] (__schedule_bug+0x39/0x50) from [c045219f] (__schedule+0x51f/0x5c4) Aug 27 13:00:38 panda kernel: [87136.303924] [c045219f] (__schedule+0x51f/0x5c4) from [c045250b] (schedule_preempt_disabled+0xf/0x10) Aug 27 13:00:38 panda kernel: [87136.303924] [c045250b] (schedule_preempt_disabled+0xf/0x10) from [c0058bbb] (cpu_startup_entry+0x12f/0x164) Aug 27 13:00:38 panda kernel: [87136.303955] [c0058bbb] (cpu_startup_entry+0x12f/0x164) from [80448ea9] (0x80448ea9) Aug 27 13:00:38 panda kernel: [87136.307403] BUG: scheduling while atomic: swapper/1/0/0x Aug 27 13:00:38 panda kernel: [87136.313781] Modules linked in: snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040 snd_soc_omap snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd_pcm snd_page_alloc snd_timer snd soundcore gator Aug 27 13:00:38 panda kernel: [87136.313842] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu Aug 27 13:00:38 panda kernel: [87136.313842] [c001175d] (unwind_backtrace+0x1/0x9c) from [c000f625] (show_stack+0x11/0x14) Aug 27 13:00:38 panda kernel: [87136.313873] [c000f625] (show_stack+0x11/0x14) from [c044c1e9] (__schedule_bug+0x39/0x50) Aug 27 13:00:38 panda kernel: [87136.313903] [c044c1e9] (__schedule_bug+0x39/0x50) from [c045219f] (__schedule+0x51f/0x5c4) Aug 27 13:00:38 panda kernel: [87136.313934] [c045219f] (__schedule+0x51f/0x5c4) from [c045250b] (schedule_preempt_disabled+0xf/0x10) Aug 27 13:00:38 panda kernel: [87136.313934] [c045250b] (schedule_preempt_disabled+0xf/0x10) from [c0058bbb] (cpu_startup_entry+0x12f/0x164) Aug 27 13:00:38 panda kernel: [87136.313964] [c0058bbb] (cpu_startup_entry+0x12f/0x164) from [80448ea9] (0x80448ea9) Aug 27 13:00:38 panda kernel: [87136.317382] BUG: scheduling while atomic: swapper/1/0/0x Aug 27 13:00:38 panda kernel: [87136.323760] Modules linked in: snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040 snd_soc_omap snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd_pcm snd_page_alloc snd_timer snd soundcore gator Aug 27 13:00:38 panda kernel: [87136.323822] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu Aug 27 13:00:38 panda kernel: [87136.323822] [c001175d] (unwind_backtrace+0x1/0x9c) from [c000f625] (show_stack+0x11/0x14) Aug 27 13:00:38 panda kernel: [87136.323822] [c000f625] (show_stack+0x11/0x14) from [c044c1e9] (__schedule_bug+0x39/0x50) Aug 27 13:00:38 panda kernel: [87136.323883] [c044c1e9] (__schedule_bug+0x39/0x50) from [c045219f] (__schedule+0x51f/0x5c4) Aug 27 13:00:38 panda kernel: [87136.323913] [c045219f] (__schedule+0x51f/0x5c4) from [c045250b] (schedule_preempt_disabled+0xf/0x10) Aug 27 13:00:38 panda kernel: [87136.323913] [c045250b] (schedule_preempt_disabled+0xf/0x10) from [c0058bbb] (cpu_startup_entry+0x12f/0x164) Aug 27 13:00:38 panda kernel: [87136.323944] [c0058bbb] (cpu_startup_entry+0x12f/0x164) from [80448ea9] (0x80448ea9) Aug 27 13:00:38 panda kernel: [87136.327392] BUG: scheduling while atomic: swapper/1/0/0x Aug 27 13:00:38 panda kernel: [87136.333770] Modules linked in: snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040 snd_soc_omap snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd_pcm snd_page_alloc snd_timer snd soundcore gator Rgds, Chris On Tue, Aug 27, 2013 at 8:50 AM, Christian Hoffmann chrmhoffm...@gmail.com mailto:chrmhoffm...@gmail.com wrote: Hi, running the current panda linaro kernel 3.10.1.0-1-linaro-omap from linaro release 13.07, I run into a few kernel stacks. Eg.: [33222.473022] [ cut here ] [33222.473052] WARNING: at /build/buildd/linux-linaro-omap-3.10.1-3.10.1.0/kernel/timer.c:1122
Re: [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver
On 08/30/2013 08:47 AM, Archit Taneja wrote:
On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote:
On Thu 29 August 2013 14:32:49 Archit Taneja wrote:
VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color
space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.
We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.
Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are
added.
Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and
stores
them in the buffer. There are also some VPDMA parameters like frame start
and
line mode which needs to be configured, these are configured by direct
register
writes via the VPDMA helper functions.
The driver's device_run() mem2mem op will add each descriptor based on how
the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA
will
upload MMR registers, start DMA of video buffers on the various input and
output
clients/ports.
When the list is parsed completely(and the DMAs on all the output ports
done),
an interrupt is generated which we use to notify that the source and
destination
buffers are done.
The rest of the driver is quite similar to other mem2mem drivers, we use the
multiplane v4l2 ioctls as the HW support coplanar formats.
Signed-off-by: Archit Taneja arc...@ti.com
Thanks for the patch. Just a few small comments below...
---
drivers/media/platform/Kconfig | 16 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/ti-vpe/Makefile |5 +
drivers/media/platform/ti-vpe/vpe.c | 1740
++
drivers/media/platform/ti-vpe/vpe_regs.h | 496 +
5 files changed, 2259 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/Makefile
create mode 100644 drivers/media/platform/ti-vpe/vpe.c
create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
new file mode 100644
index 000..85b0880
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/vpe.c
snip
+static int vpe_enum_fmt(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if (V4L2_TYPE_IS_OUTPUT(f-type))
+ return __enum_fmt(f, VPE_FMT_TYPE_OUTPUT);
+ else
The line above isn't necessary.
Oh right, thanks for spotting that.
+ return __enum_fmt(f, VPE_FMT_TYPE_CAPTURE);
+}
+
snip
+
+ pix-field = V4L2_FIELD_NONE;
+
+ v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
+ pix-height, MIN_H, MAX_H, H_ALIGN,
+ S_ALIGN);
+
+ pix-num_planes = fmt-coplanar ? 2 : 1;
+ pix-pixelformat = fmt-fourcc;
+ pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?
+ V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
pix-priv should be set to NULL as well.
I'll fix this.
snip
+}
+
+#define V4L2_CID_TRANS_NUM_BUFS(V4L2_CID_USER_BASE + 0x1000)
Reserve a control range for this driver in
include/uapi/linux/v4l2-controls.h.
Similar to the ones already defined there.
That will ensure that controls for this driver have unique IDs.
Thanks, I took this from the mem2mem-testdev driver, a test driver
doesn't need to worry about this I suppose.
I had a query regarding this. I am planning to add a capture driver in
the future for a similar IP which can share some of the control IDs with
VPE. Is it possible for 2 different drivers to share the IDs?
Certainly. There are three levels of controls:
1) Standard controls: can be used by any driver and are documented in the spec.
2) IP-specific controls: controls specific for a commonly used IP.
These can be used by any driver containing that IP and are documented as well
in the spec. Good examples are the MFC and CX2341x MPEG controls.
3) Driver-specific controls: these are specific to a driver and do not have to
be
documented in the spec, only in the header/source specifying them. A range
of controls needs to be assigned to such a driver in v4l2-dv-controls.h.
In your case it looks like the controls would fall into category 2.
Also, I noticed in the header that most drivers reserve space for 16
IDs. The current
Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
Hi George,
In addition, I add answer about that device driver control gpio pin directly.
On 08/30/2013 03:15 PM, George Cherian wrote:
Hi Chanwoo,
On 8/30/2013 5:41 AM, Chanwoo Choi wrote:
Hi George,
On 08/29/2013 10:45 PM, George Cherian wrote:
Hi Chanwoo,
On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
I tested various development board based on Samsung Exynos series SoC.
Although some gpio of Exynos series SoC set high state(non zero, 1) as
default value,
this gpio state could mean off state, disconnected or un-powered state
according to gpio.
Of course, above explanation about specific gpio don't include all gpios.
This is meaning that there is possibility.
okay then how about adding a flag for inverted logic too. something like
this
if(of_property_read_bool(np,inverted_gpio))
gpio_usbvid-gpio_inv = 1;
And always check on this before deciding?
Is this fine ?
OK.
But, as Stephen commented on other mail, you should use proper DT helper
function.
okay
Second,
gpio_usbvid_set_initial_state() dertermine both USB-HOST and USB
cable state at same time
in 'case ID_DETCT' according to 'gpio_usbvid-id_gpio'. But, I think
that other extcon devices
would not control both USB-HOST and USB cable state at same time.
Other extcon devices would support either USB-HOST or USB cable.
The driver has 2 configurations.
1) supports implementations with both VBUS and ID pin are routed via
gpio's for swicthing roles(compatible gpio-usb-vid).
As you explained about case 1, it is only used on dra7x SoC.
No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via
gpio.
Other SoC could not wish to control both USB-HOST and USB cable at
same time.
I could'nt actually parse this. You meant since the id_irq_handler handles
both USB and USB-HOST cable
its not proper?
It's not proper in general case. The generic driver must guarantee all of
extcon device using gpio.
As far as I know, the generic driver cannot direclty control gpio pin and
get value from gpio pin.
Almost device driver including in kernel/drivers control gpio pin on
specific device driver
instead of generic driver.
But without reading the gpio value how can we set the cable states?
hmm. I mentioned above my answer as following:
As far as I know, the generic driver cannot direclty control gpio
pin and get value from gpio pin.
Almost device driver including in kernel/drivers control gpio pin on
specific device driver
Because your extcon driver directly control gpio pin so I think your extcon
driver isn't generic.
for this driver the assumption is the dedicated gpio
is always DIR_IN and in the driver we just read the value.
What is DIR_IN?
I need your answer about above my opinion for other SoC.
So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
{
int id_current, vbus_current;
id_current = gpio_get_value_cansleep(gpio_usbvid-id_gpio);
if (!!id_current == ID_FLOAT)
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST, false);
else
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST, true);
vbus_current = gpio_get_value_cansleep(gpio_usbvid-vbus_gpio);
if (!!vbus_current == VBUS_ON)
extcon_set_cable_state(gpio_usbvid-edev, USB, true);
else
extcon_set_cable_state(gpio_usbvid-edev, USB, false);
}
and the irq handlers like this
static irqreturn_t id_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int id_current;
id_current = gpio_get_value_cansleep(gpio_usbvid-id_gpio);
if (id_current == ID_GND)
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST,
true);
else
extcon_set_cable_state(gpio_usbvid-edev, USB-HOST,
false);
return IRQ_HANDLED;
}
static irqreturn_t vbus_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int vbus_current;
vbus_current = gpio_get_value_cansleep(gpio_usbvid-vbus_gpio);
if (vbus_current == VBUS_OFF)
extcon_set_cable_state(gpio_usbvid-edev, USB, false);
else
extcon_set_cable_state(gpio_usbvid-edev, USB, true);
return IRQ_HANDLED;
}
I know your intention dividing interrupt handler for each cable.
But I don't think this driver must guarantee all of extcon device using gpio.
For example,
below three SoC wish to detect USB/USB-HOST cable with each different
methods.
SoC A wish to detect USB/USB-HOST cable through only one gpio pin.
You mean to say that both USB ID pin and VBUS are connected to same gpio?
If so that is a really bad h/w design and it will not fly.
Or, you meant that only USB ID pin is connected to single gpio and it
controls the
Re: [PATCH] omap2: panel-generic: Added panel parameters for ortus-com37h3m05dtc/99dtc and sharp-lq070y3dg3b.
On 29/08/13 15:35, Marek Belisko wrote:
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
drivers/video/omap2/displays/panel-generic-dpi.c | 53
1 file changed, 53 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index bebebd4..d573291 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -107,6 +107,33 @@ static struct panel_config generic_dpi_panels[] = {
.name = sharp_ls,
},
The drivers in drivers/video/omap2/displays/ are on their way out, and
will probably be removed for 3.12. Please look at the new one at
drivers/video/omap2/displays-new/panel-dpi.c.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: omap: panda rcu stall on 3.10.1
2013/8/30 Christian Hoffmann chrmhoffm...@gmail.com:
This also went to: linaro-ker...@lists.linaro.org
Hi,
current linaro kernel on 13.07 (3.10.1.0-1-linaro-omap) shows stack below.
System is generally quite unstable. Light usage (postfix+dovecot...)
Full dmesg here:
https://dl.dropboxusercontent.com/u/21820416/rcu.stall.panda
Hi,
Does it happen when run with nohlt in the kernel command line ?
Rgds,
Chris
[ 4538.880432] INFO: rcu_sched detected stalls on CPUs/tasks: { 1}
(detected by 0, t=2103 jiffies, g=1649, c=1648, q=18)
[ 4538.891723] Backtrace for cpu 0 (current):
[ 4538.891723] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
[ 4538.891754] [c001175d] (unwind_backtrace+0x1/0x9c) from
[c000f625] (show_stack+0x11/0x14)
[ 4538.891815] [c000f625] (show_stack+0x11/0x14) from [c00106d5]
(smp_send_all_cpu_backtrace+0x49/0x98)
[ 4538.891815] [c00106d5] (smp_send_all_cpu_backtrace+0x49/0x98) from
[c007c755] (rcu_check_callbacks+0x439/0x4ac)
[ 4538.891815] [c007c755] (rcu_check_callbacks+0x439/0x4ac) from
[c0036599] (update_process_times+0x2d/0x4c)
[ 4538.891876] [c0036599] (update_process_times+0x2d/0x4c) from
[c005fcfd] (tick_sched_handle+0x35/0x40)
[ 4538.891906] [c005fcfd] (tick_sched_handle+0x35/0x40) from
[c005feed] (tick_sched_timer+0x31/0x54)
[ 4538.891937] [c005feed] (tick_sched_timer+0x31/0x54) from
[c004532b] (__run_hrtimer+0x5b/0x138)
[ 4538.891937] [c004532b] (__run_hrtimer+0x5b/0x138) from [c0045bcb]
(hrtimer_interrupt+0xdb/0x22c)
[ 4538.891967] [c0045bcb] (hrtimer_interrupt+0xdb/0x22c) from
[c0010e13] (twd_handler+0x1b/0x28)
[ 4538.891998] [c0010e13] (twd_handler+0x1b/0x28) from [c00783b9]
(handle_percpu_devid_irq+0x4d/0xac)
[ 4538.891998] [c00783b9] (handle_percpu_devid_irq+0x4d/0xac) from
[c0075ead] (generic_handle_irq+0x19/0x24)
[ 4538.892028] [c0075ead] (generic_handle_irq+0x19/0x24) from
[c000d16d] (handle_IRQ+0x29/0x68)
[ 4538.892059] [c000d16d] (handle_IRQ+0x29/0x68) from [c00084db]
(gic_handle_irq+0x27/0x50)
[ 4538.892059] [c00084db] (gic_handle_irq+0x27/0x50) from [c045315b]
(__irq_svc+0x3b/0x5c)
[ 4538.892059] Exception stack(0xc06e3f68 to 0xc06e3fb0)
[ 4538.892059] 3f60:
c06e2000 c075f130
[ 4538.892120] 3f80: c06e2000 c075ea93 c075f130 c06ea594 c045c2e0
c06e2000 c0fe5908 c06e3fb0
[ 4538.892120] 3fa0: c007bab1 c0058b48 400f0133
[ 4538.892120] [c045315b] (__irq_svc+0x3b/0x5c) from [c0058b48]
(cpu_startup_entry+0xbc/0x164)
[ 4538.892120] [c0058b48] (cpu_startup_entry+0xbc/0x164) from
[c06735f9] (start_kernel+0x251/0x2ac)
[ 4538.892120]
[ 4538.892120] sending IPI to all other CPUs:
[ 4538.892211] IPI backtrace for cpu 1
[ 4538.892211]
[ 4538.892242] CPU: 1 PID: 2064 Comm: clamd Not tainted
3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
[ 4538.892242] task: edb09500 ti: ec91e000 task.ti: ec91e000
[ 4538.892272] PC is at 0xb6e2f0d4
[ 4538.892272] LR is at 0xb6eeec01
[ 4538.892272] pc : [b6e2f0d4]lr : [b6eeec01]psr: 000f0130
[ 4538.892272] sp : be8b472c ip : 62323337 fp : 684a
[ 4538.892303] r10: 0084d750 r9 : 0200 r8 : e86d6a2f
[ 4538.892303] r7 : 0a0a0a0a r6 : 69393e32 r5 : 0080bf24 r4 : 0080bf28
[ 4538.892333] r3 : 81010100 r2 : 6438 r1 : 000a r0 : 0080bf24
[ 4538.892333] Flags: nzcv IRQs on FIQs on Mode USER_32 ISA Thumb
Segment user
[ 4538.892333] Control: 50c5387d Table: acbd404a DAC:
[ 4538.892364]
[ 4538.892364] R8: 0xe86d69af:
[ 4538.892364] 69ac 6a6f7254 412e6e61 746e6567 3939332d 00303934
b1aa3270 2506 47a83ca7
[ 4538.892395] 69cc e4ebc453 91ad979e 23363f8b fd49d9d0 773b48ba
ad58f7d3 04c351eb 96e4414f
[ 4538.892395] 69ec 7e1a3ac7 f39072a5 e362cedb b119b3e0 b595375e
b2137762 b19f99a8 b10dc638
[ 4538.892395] 6a0c 1806 2e6e6957 6a6f7254 412e6e61 746e6567
3939332d 00303534 b23ade28
[ 4538.892395] 6a2c 1806 2e6e6957 6a6f7254 462e6e61 61656b61
37342d76 00373131 ac58376e
[ 4538.892395] 6a4c 72542e6e 6e616a6f 3434382e 35313336 3e55c600
412e6eb2 72617764 61472e65
[ 4538.892517] 6a6c 6176656d 2d65636e 34393132 55b20037 1604b173
2e6e6957 6a6f7254 462e6e61
[ 4538.892547] 6a8c 61656b61 37342d76 00343131 b652e2c0 72542e6e
6e616a6f 7075532e 756a7265
[ 4538.892547] 6aac 322d6e61 fb003731 15b23a2b 2e6e6957 6a6f7254
412e6e61 746e6567 3939332d
[ 4538.892547] CPU: 1 PID: 2064 Comm: clamd Not tainted
3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
[ 4538.892547] [c001175d] (unwind_backtrace+0x1/0x9c) from
[c000f625] (show_stack+0x11/0x14)
[ 4538.892639] [c000f625] (show_stack+0x11/0x14) from [c0010819]
(handle_IPI+0xd5/0x158)
[ 4538.892669] [c0010819] (handle_IPI+0xd5/0x158) from [c00084ff]
(gic_handle_irq+0x4b/0x50)
[ 4538.892669] [c00084ff] (gic_handle_irq+0x4b/0x50) from [c0453369]
(__irq_usr+0x49/0x60)
[ 4538.892700] Exception stack(0xec91ffb0 to 0xec91fff8)
[ 4538.892700] ffa0:
Re: [PATCH 1/3] crypto: omap-des: Add omap-des driver for OMAP4/AM43xx
[]..
+
+#define pr_fmt(fmt) %s: fmt, __func__
+
+#ifdef DEBUG
+#define prn(num) printk(#num =%d\n, num)
+#define prx(num) printk(#num =%x\n, num)
+#else
+#define prn(num) do { } while (0)
+#define prx(num) do { } while (0)
+#endif
+
+#include linux/err.h
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/io.h
+#include linux/crypto.h
+#include linux/interrupt.h
+#include crypto/scatterwalk.h
+#include crypto/des.h
+
+#define DST_MAXBURST 2
+
+#define DES_BLOCK_WORDS (DES_BLOCK_SIZE 2)
+
+#define _calc_walked(inout) (dd-inout##_walk.offset -
dd-inout##_sg-offset)
+
+#define DES_REG_KEY(dd, x) ((dd)-pdata-key_ofs - \
+ ((x ^ 0x01) * 0x04))
+
+#define DES_REG_IV(dd, x)((dd)-pdata-iv_ofs + ((x) * 0x04))
+
+#define DES_REG_CTRL(dd) ((dd)-pdata-ctrl_ofs)
+#define DES_REG_CTRL_CBC (1 4)
+#define DES_REG_CTRL_TDES(1 3)
+#define DES_REG_CTRL_DIRECTION (1 2)
+#define DES_REG_CTRL_INPUT_READY (1 1)
+#define DES_REG_CTRL_OUTPUT_READY(1 0)
Why not use bitops like you have done below.
+
+#define DES_REG_DATA_N(dd, x)((dd)-pdata-data_ofs + ((x) *
0x04))
+
+#define DES_REG_REV(dd) ((dd)-pdata-rev_ofs)
+
+#define DES_REG_MASK(dd) ((dd)-pdata-mask_ofs)
+
+#define DES_REG_LENGTH_N(x) (0x24 + ((x) * 0x04))
+
+#define DES_REG_IRQ_STATUS(dd) ((dd)-pdata-irq_status_ofs)
+#define DES_REG_IRQ_ENABLE(dd) ((dd)-pdata-irq_enable_ofs)
+#define DES_REG_IRQ_DATA_INBIT(1)
+#define DES_REG_IRQ_DATA_OUT BIT(2)
+
+#define FLAGS_MODE_MASK 0x000f
+#define FLAGS_ENCRYPTBIT(0)
+#define FLAGS_CBCBIT(1)
+#define FLAGS_INIT BIT(4)
+#define FLAGS_BUSY BIT(6)
+
[]..
+struct omap_des_pdata {
+ struct omap_des_algs_info *algs_info;
+ unsigned intalgs_info_size;
+
+ void(*trigger)(struct omap_des_dev *dd, int length);
Is this really used? How does a DT platform pass function pointers?
+
+ u32 key_ofs;
+ u32 iv_ofs;
+ u32 ctrl_ofs;
+ u32 data_ofs;
+ u32 rev_ofs;
+ u32 mask_ofs;
+ u32 irq_enable_ofs;
+ u32 irq_status_ofs;
+
+ u32 dma_enable_in;
+ u32 dma_enable_out;
+ u32 dma_start;
+
+ u32 major_mask;
+ u32 major_shift;
+ u32 minor_mask;
+ u32 minor_shift;
+};
+
+struct omap_des_dev {
+ struct list_headlist;
+ unsigned long phys_base;
+ void __iomem*io_base;
+ struct omap_des_ctx *ctx;
+ struct device *dev;
+ unsigned long flags;
+ int err;
+
+ /* spinlock used for queues */
+ spinlock_t lock;
+ struct crypto_queue queue;
+
+ struct tasklet_struct done_task;
+ struct tasklet_struct queue_task;
+
+ struct ablkcipher_request *req;
+ /*
+ * total is used by PIO mode for book keeping so introduce
+ * variable total_save as need it to calc page_order
+ */
+ size_t total;
+ size_t total_save;
+
+ struct scatterlist *in_sg;
+ struct scatterlist *out_sg;
+
+ /* Buffers for copying for unaligned cases */
+ struct scatterlist in_sgl;
+ struct scatterlist out_sgl;
+ struct scatterlist *orig_out;
+ int sgs_copied;
+
+ struct scatter_walk in_walk;
+ struct scatter_walk out_walk;
+ int dma_in;
+ struct dma_chan *dma_lch_in;
+ int dma_out;
+ struct dma_chan *dma_lch_out;
+ int in_sg_len;
+ int out_sg_len;
+ int pio_only;
+ const struct omap_des_pdata *pdata;
+};
+
+/* keep registered devices data here */
+static LIST_HEAD(dev_list);
+static DEFINE_SPINLOCK(list_lock);
+
[]..
+
+static int omap_des_crypt_dma_start(struct omap_des_dev *dd)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(
+ crypto_ablkcipher_reqtfm(dd-req));
+ int err;
+
+
Re: [PATCH v2 3/3] ARM: OMAP4+: Remove static iotable mappings for SRAM
On Thursday 29 August 2013 10:50 PM, Kevin Hilman wrote:
Rajendra Nayak rna...@ti.com writes:
In order to handle errata I688, a page of sram was reserved by doing a
static iotable map. Now that we use gen_pool to manage sram, we can
completely remove all of these static mappings and use gen_pool_alloc()
to get the one page of sram space needed to implement errata I688.
Suggested-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
[...]
@@ -71,6 +72,21 @@ void omap_bus_sync(void)
}
EXPORT_SYMBOL(omap_bus_sync);
+static int __init omap4_sram_init(void)
+{
+struct device_node *np;
+struct gen_pool *sram_pool;
+
+np = of_find_compatible_node(NULL, NULL, ti,omap4-mpu);
+if (!np)
+pr_warn(%s:Unable to allocate sram needed to handle errata
I688\n,
+ __func__);
+sram_pool = of_get_named_gen_pool(np, sram, 0);
I haven't actually tested this, but if there is no 'sram' property defined...
+sram_sync = (void *)gen_pool_alloc(sram_pool, PAGE_SIZE);
... does this still behave properly?
I guess not :(
of_get_named_gen_pool() ends up returning NULL, but passing NULL to
gen_pool_alloc()
crashes. Will fix with the additional check for non-NULL sram_pool, thanks.
regards,
Rajendra
+return 0;
+}
Kevin
--
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 00/22] OMAPDSS: DT support
On 13/08/13 10:54, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [130809 01:46]: So as is evident, I have things in my mind that should be improved. Maybe the most important question for short term future is: Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us some proper testing of the related code, and would also allow us to remove the related hacks (which don't even work quite right). However, I have no idea yet when the unstable DSS bindings would turn stable. If we shouldn't add the bindings as unstable, when should the bindings be added? Wait until CDF is in the mainline, and use that? I don't think we should add any temporary bindings as it's going to be a pain to support those in the long run. I suggest you initially just stick to established bindings for the basic hardware IO address and interrupts etc, then those should still be valid with the generic panel bindings later on. I don't understand what does it matter if the bindings are temporary, or basic established bindings. In both cases the DT data needs to be changed when the CDF is taken into use. Well, one difference is that the temporary bindings would give us working display, but having only basic bindings would not. So I don't see any reason to add only the basic bindings. Or how would it work? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver
Hi, On Friday 30 August 2013 12:37 PM, Hans Verkuil wrote: On 08/30/2013 08:47 AM, Archit Taneja wrote: On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote: On Thu 29 August 2013 14:32:49 Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. snip +} + +#define V4L2_CID_TRANS_NUM_BUFS(V4L2_CID_USER_BASE + 0x1000) Reserve a control range for this driver in include/uapi/linux/v4l2-controls.h. Similar to the ones already defined there. That will ensure that controls for this driver have unique IDs. Thanks, I took this from the mem2mem-testdev driver, a test driver doesn't need to worry about this I suppose. I had a query regarding this. I am planning to add a capture driver in the future for a similar IP which can share some of the control IDs with VPE. Is it possible for 2 different drivers to share the IDs? Certainly. There are three levels of controls: 1) Standard controls: can be used by any driver and are documented in the spec. 2) IP-specific controls: controls specific for a commonly used IP. These can be used by any driver containing that IP and are documented as well in the spec. Good examples are the MFC and CX2341x MPEG controls. 3) Driver-specific controls: these are specific to a driver and do not have to be documented in the spec, only in the header/source specifying them. A range of controls needs to be assigned to such a driver in v4l2-dv-controls.h. In your case it looks like the controls would fall into category 2. For 2), by commonly used IP, do you mean a commonly used class of IPs like MPEG decoder, FM and camera? Or do you mean a specific vendor IP like say a camera subsystem found on different SoCs. I think the controls in my case are very specific to the VPE and VIP IPs. These 2 IPs have some components like scaler, color space converter, chrominance up/downsampler in common. The controls will be specific to how these components behave. For example, a control can tell what value of frequency of Luminance peaking the scaler needs to perform. I don't think all scalers would provide Luma peaking. This holds for other controls too. So if I understood your explanation correctly, I think 3) might make more sense. Also, I noticed in the header that most drivers reserve space for 16 IDs. The current driver just has one, but there will be more custom ones in the future. Is it fine if I reserve 16 for this driver too? Sure, that's no problem. Make sure you reserve enough space for future expansion, i.e. IDs are cheap, so no need to be conservative when defining the range. Thanks for the clarification. Archit -- 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 2/3] gpio: pcf857x: remove the irq_demux_work
Now that we are using devm_request_threaded_irq no need for
irq_demux_work. Remove all its references.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/gpio/gpio-pcf857x.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 4d0d28c..4890e97 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -30,7 +30,6 @@
#include linux/of_device.h
#include linux/slab.h
#include linux/spinlock.h
-#include linux/workqueue.h
static const struct i2c_device_id pcf857x_id[] = {
@@ -89,7 +88,6 @@ struct pcf857x {
struct gpio_chipchip;
struct i2c_client *client;
struct mutexlock; /* protect 'out' */
- struct work_struct work; /* irq demux work */
struct irq_domain *irq_domain;/* for irq demux */
spinlock_t slock; /* protect irq demux */
unsignedout;/* software latch */
@@ -210,38 +208,6 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
return IRQ_HANDLED;
}
-static void pcf857x_irq_demux_work(struct work_struct *work)
-{
- struct pcf857x *gpio = container_of(work,
- struct pcf857x,
- work);
- unsigned long change, i, status, flags;
-
- status = gpio-read(gpio-client);
-
- spin_lock_irqsave(gpio-slock, flags);
-
- change = gpio-status ^ status;
- for_each_set_bit(i, change, gpio-chip.ngpio)
- generic_handle_irq(irq_find_mapping(gpio-irq_domain, i));
- gpio-status = status;
-
- spin_unlock_irqrestore(gpio-slock, flags);
-}
-
-static irqreturn_t pcf857x_irq_demux(int irq, void *data)
-{
- struct pcf857x *gpio = data;
-
- /*
-* pcf857x can't read/write data here,
-* since i2c data access might go to sleep.
-*/
- schedule_work(gpio-work);
-
- return IRQ_HANDLED;
-}
-
static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hw)
{
@@ -284,7 +250,6 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
goto fail;
/* enable gpio_to_irq() */
- INIT_WORK(gpio-work, pcf857x_irq_demux_work);
gpio-chip.to_irq = pcf857x_to_irq;
gpio-irq = client-irq;
--
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 v2 0/3] cleanup of gpio_pcf857x.c
This patch series - removes the irq_demux_work - Uses devm_request_threaded_irq - Call the user handler iff gpio_to_irq is done. v1 -- v2 Split v1 to 3 patches George Cherian (3): gpio: pcf857x: change to devm_request_threaded_irq gpio: pcf857x: remove the irq_demux_work gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done arch/arm/boot/dts/dra7-evm.dts | 6 ++--- drivers/gpio/gpio-pcf857x.c| 51 +- 2 files changed, 29 insertions(+), 28 deletions(-) -- 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 v2 3/3] gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done
For pcf857x driver if the initial state is not set properly (proper
n_latch is not passed), we get bad irq prints on console.
We get this only for the first interrupt and doesnot repeat for further
interrupts unles and until there are other gpio pins which are not flipping
continously.
following prints are seen on console.
[ 40.983924] irq 0, desc: ce004080, depth: 1, count: 0, unhandled: 0
[ 40.990511] -handle_irq(): c00aa538, handle_bad_irq+0x0/0x260
[ 40.996768] -irq_data.chip(): c080b6ec, no_irq_chip+0x0/0x60
[ 41.002842] -action(): (null)
[ 41.006242]IRQ_NOPROBE set
[ 41.009465] IRQ_NOREQUEST set
Signed-off-by: George Cherian george.cher...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 4 ++--
drivers/gpio/gpio-pcf857x.c| 22 +++---
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 39b44bc..00fb0df 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -50,7 +50,7 @@
gpio20: pcf8575@20 {
compatible = ti,pcf8575;
reg = 0x20;
- n_latch = 0x4000;
+ n_latch = 0x;
gpio-controller;
#gpio-cells = 2;
interrupt-parent = gpio6;
@@ -62,7 +62,7 @@
gpio21: pcf8575@21 {
compatible = ti,pcf8575;
reg = 0x21;
- n_latch = 0x1408;
+ /*n_latch = 0x1408;*/
gpio-controller;
#gpio-cells = 2;
interrupt-parent = gpio20;
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 4890e97..578d93f 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -93,6 +93,7 @@ struct pcf857x {
unsignedout;/* software latch */
unsignedstatus; /* current status */
int irq;/* real irq number */
+ unsignedirq_mapped; /* mapped gpio irqs */
int (*write)(struct i2c_client *client, unsigned data);
int (*read)(struct i2c_client *client);
@@ -185,8 +186,13 @@ static void pcf857x_set(struct gpio_chip *chip, unsigned
offset, int value)
static int pcf857x_to_irq(struct gpio_chip *chip, unsigned offset)
{
struct pcf857x *gpio = container_of(chip, struct pcf857x, chip);
+ int ret;
- return irq_create_mapping(gpio-irq_domain, offset);
+ ret = irq_create_mapping(gpio-irq_domain, offset);
+ if (ret 0)
+ gpio-irq_mapped |= (1 offset);
+
+ return ret;
}
static irqreturn_t pcf857x_irq(int irq, void *data)
@@ -198,7 +204,12 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
spin_lock_irqsave(gpio-slock, flags);
- change = gpio-status ^ status;
+ /*
+* call the interrupt handler iff gpio is used as
+* interrupt source, just to avoid bad irqs
+*/
+
+ change = ((gpio-status ^ status) gpio-irq_mapped);
for_each_set_bit(i, change, gpio-chip.ngpio)
generic_handle_irq(irq_find_mapping(gpio-irq_domain, i));
gpio-status = status;
@@ -211,9 +222,14 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hw)
{
+ struct pcf857x *gpio = domain-host_data;
+
irq_set_chip_and_handler(virq,
dummy_irq_chip,
handle_level_irq);
+ set_irq_flags(virq, IRQF_VALID);
+ gpio-irq_mapped |= (1 hw);
+
return 0;
}
@@ -236,7 +252,7 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
gpio-irq_domain = irq_domain_add_linear(client-dev.of_node,
gpio-chip.ngpio,
pcf857x_irq_domain_ops,
-NULL);
+gpio);
if (!gpio-irq_domain)
goto fail;
--
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 v2 1/3] gpio: pcf857x: change to devm_request_threaded_irq
Remove the request_irq and use devm_request_threaded_irq
also cleanup free_irq. devm_* takes care of that.
Signed-off-by: George Cherian george.cher...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 2 +-
drivers/gpio/gpio-pcf857x.c| 28
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 8b0738a..39b44bc 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -65,7 +65,7 @@
n_latch = 0x1408;
gpio-controller;
#gpio-cells = 2;
- interrupt-parent = pcf_20;
+ interrupt-parent = gpio20;
interrupts = 14 2;
interrupt-controller;
#interrupt-cells = 2;
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 947cff4..4d0d28c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -191,6 +191,25 @@ static int pcf857x_to_irq(struct gpio_chip *chip, unsigned
offset)
return irq_create_mapping(gpio-irq_domain, offset);
}
+static irqreturn_t pcf857x_irq(int irq, void *data)
+{
+ struct pcf857x *gpio = data;
+ unsigned long change, i, status, flags;
+
+ status = gpio-read(gpio-client);
+
+ spin_lock_irqsave(gpio-slock, flags);
+
+ change = gpio-status ^ status;
+ for_each_set_bit(i, change, gpio-chip.ngpio)
+ generic_handle_irq(irq_find_mapping(gpio-irq_domain, i));
+ gpio-status = status;
+
+ spin_unlock_irqrestore(gpio-slock, flags);
+
+ return IRQ_HANDLED;
+}
+
static void pcf857x_irq_demux_work(struct work_struct *work)
{
struct pcf857x *gpio = container_of(work,
@@ -241,8 +260,6 @@ static void pcf857x_irq_domain_cleanup(struct pcf857x *gpio)
if (gpio-irq_domain)
irq_domain_remove(gpio-irq_domain);
- if (gpio-irq)
- free_irq(gpio-irq, gpio);
}
static int pcf857x_irq_domain_init(struct pcf857x *gpio,
@@ -258,8 +275,11 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
goto fail;
/* enable real irq */
- status = request_irq(client-irq, pcf857x_irq_demux, 0,
-dev_name(client-dev), gpio);
+ status = devm_request_threaded_irq(client-dev, client-irq,
+ NULL, pcf857x_irq, IRQF_ONESHOT |
+ IRQF_TRIGGER_FALLING,
+ dev_name(client-dev), gpio);
+
if (status)
goto fail;
--
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
Re: [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver
On Fri 30 August 2013 12:05:11 Archit Taneja wrote: Hi, On Friday 30 August 2013 12:37 PM, Hans Verkuil wrote: On 08/30/2013 08:47 AM, Archit Taneja wrote: On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote: On Thu 29 August 2013 14:32:49 Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. snip +} + +#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1000) Reserve a control range for this driver in include/uapi/linux/v4l2-controls.h. Similar to the ones already defined there. That will ensure that controls for this driver have unique IDs. Thanks, I took this from the mem2mem-testdev driver, a test driver doesn't need to worry about this I suppose. I had a query regarding this. I am planning to add a capture driver in the future for a similar IP which can share some of the control IDs with VPE. Is it possible for 2 different drivers to share the IDs? Certainly. There are three levels of controls: 1) Standard controls: can be used by any driver and are documented in the spec. 2) IP-specific controls: controls specific for a commonly used IP. These can be used by any driver containing that IP and are documented as well in the spec. Good examples are the MFC and CX2341x MPEG controls. 3) Driver-specific controls: these are specific to a driver and do not have to be documented in the spec, only in the header/source specifying them. A range of controls needs to be assigned to such a driver in v4l2-dv-controls.h. In your case it looks like the controls would fall into category 2. For 2), by commonly used IP, do you mean a commonly used class of IPs like MPEG decoder, FM and camera? Or do you mean a specific vendor IP like say a camera subsystem found on different SoCs. I mean a specific vendor IP found on different SoCs. So different drivers would have to support the same IP. I think the controls in my case are very specific to the VPE and VIP IPs. These 2 IPs have some components like scaler, color space converter, chrominance up/downsampler in common. The controls will be specific to how these components behave. For example, a control can tell what value of frequency of Luminance peaking the scaler needs to perform. I don't think all scalers would provide Luma peaking. This holds for other controls too. So if I understood your explanation correctly, I think 3) might make more sense. That might be a good starting point. It is not uncommon that controls migrate from being custom controls to more standardized controls when other devices appear using the same IP. Or sometimes what seemed like a HW specific feature turns out to be available on other hardware from other vendors as well. Also, I noticed in the header that most drivers reserve space for 16 IDs. The current driver just has one, but there will be more custom ones in the future. Is it fine if I reserve 16 for this driver too? Sure, that's no problem. Make sure you reserve enough space for future expansion, i.e. IDs are cheap, so no need to be conservative when defining the range. Thanks for the clarification. Archit Regards, Hans -- 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 02/10] cpufreq: OMAP: Add SMP support for OMAP4+
From: Viresh Kumar viresh.ku...@linaro.org mailto:viresh.ku...@linaro.org Date: Wed, 21 Aug 2013 19:05:05 +0530 Subject: [PATCH] cpufreq: omap: use cpufreq_generic_init() routine Use generic cpufreq_generic_init() routine instead of replicating the same code here. This also rearranges the code a bit to make it more sensible. Also removes some unnecessary checks. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org mailto:viresh.ku...@linaro.org --- drivers/cpufreq/omap-cpufreq.c | 41 +++-- 1 file changed, 11 insertions(+), 30 deletions(-) I haven't tested it but looks straightforward so.. Acked-by: Santosh Shilimkar santosh.shilim...@ti.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 3/3] ARM: OMAP4+: Remove static iotable mappings for SRAM
Rajendra Nayak rna...@ti.com writes:
On Thursday 29 August 2013 10:50 PM, Kevin Hilman wrote:
Rajendra Nayak rna...@ti.com writes:
In order to handle errata I688, a page of sram was reserved by doing a
static iotable map. Now that we use gen_pool to manage sram, we can
completely remove all of these static mappings and use gen_pool_alloc()
to get the one page of sram space needed to implement errata I688.
Suggested-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
[...]
@@ -71,6 +72,21 @@ void omap_bus_sync(void)
}
EXPORT_SYMBOL(omap_bus_sync);
+static int __init omap4_sram_init(void)
+{
+ struct device_node *np;
+ struct gen_pool *sram_pool;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-mpu);
+ if (!np)
+ pr_warn(%s:Unable to allocate sram needed to handle errata
I688\n,
+__func__);
+ sram_pool = of_get_named_gen_pool(np, sram, 0);
I haven't actually tested this, but if there is no 'sram' property defined...
+ sram_sync = (void *)gen_pool_alloc(sram_pool, PAGE_SIZE);
... does this still behave properly?
I guess not :(
of_get_named_gen_pool() ends up returning NULL, but passing NULL to
gen_pool_alloc()
crashes. Will fix with the additional check for non-NULL sram_pool, thanks.
OK, that's what I suspected. Thanks for checking/testing.
Kevin
--
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 3/3] ARM: OMAP4+: Remove static iotable mappings for SRAM
On Friday 30 August 2013 10:39 AM, Kevin Hilman wrote:
Rajendra Nayak rna...@ti.com writes:
On Thursday 29 August 2013 10:50 PM, Kevin Hilman wrote:
Rajendra Nayak rna...@ti.com writes:
In order to handle errata I688, a page of sram was reserved by doing a
static iotable map. Now that we use gen_pool to manage sram, we can
completely remove all of these static mappings and use gen_pool_alloc()
to get the one page of sram space needed to implement errata I688.
Suggested-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
[...]
@@ -71,6 +72,21 @@ void omap_bus_sync(void)
}
EXPORT_SYMBOL(omap_bus_sync);
+static int __init omap4_sram_init(void)
+{
+ struct device_node *np;
+ struct gen_pool *sram_pool;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-mpu);
+ if (!np)
+ pr_warn(%s:Unable to allocate sram needed to handle errata
I688\n,
+ __func__);
+ sram_pool = of_get_named_gen_pool(np, sram, 0);
I haven't actually tested this, but if there is no 'sram' property
defined...
+ sram_sync = (void *)gen_pool_alloc(sram_pool, PAGE_SIZE);
... does this still behave properly?
I guess not :(
of_get_named_gen_pool() ends up returning NULL, but passing NULL to
gen_pool_alloc()
crashes. Will fix with the additional check for non-NULL sram_pool, thanks.
OK, that's what I suspected. Thanks for checking/testing.
I miss-understood your comment initially. Now re-reading it, its clear now.
Regards,
Santosh
--
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 v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
Russ Dill russ.d...@ti.com writes:
On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman khil...@linaro.org wrote:
Vaibhav Bedia vaibhav.be...@gmail.com writes:
[snip]
Morevoer, all the suggestions on how to keep the code in Linux working
around the complications due to the main memory not being accessible
will need to be replicated on the non-Linux s/w stacks and that's just
make it more difficult for them.
The linux code has to be very self-contained (in assembler or C), so I'm
not sure how it's difficult to replicated in any other OS (or non-OS.)
Let me pull on this thread a little bit. Would this involve defining a
bunch of different sections for each arch so that I could do:
void __sram_am33xx am33xx_some_pm_function(args)
{
}
static struct am33xx_foo_dyn *blargity __sramdata_am33xx = { ...};
static const struct am33xx_foo_const *blarg __sramconst_am33xx = { ... };
The sram push code could then push these sections into sram. There
would then be a set of inlines or macros for converting addresses
within these sections to SRAM addresses, maybe also inlines or macros
for calling code that has been pushed into sram by wrapping the
original function pointer. The macros or inlines that call SRAM code
could perform the trampoline as well.
Well, I was thinking of something much dumber.
I was thinking about just _carefully_ writing a single, self-contained C
function, with all of its data on the stack (and consts as #defines).
Think of it is a step up in readability from straight assembly (which
was the stated reason for moving the code to the M3 in the first place.)
Kevin
--
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 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
(picking up an old thread, again) On Thu, Aug 8, 2013 at 7:04 PM, Kevin Hilman khil...@linaro.org wrote: I disagree here. I'm a firmware minimalist, and hiding bugs like this in the firmware is wrong when Linux is otherwise managing these devices. It also imposes criteria on the firmware of future SoCs that doesn't belong there either. IMO, the only stuff the firmware should do is what Linux *cannot* do. Remember, this only needs to happen when there isn't a driver for these devices. Should we communicate to the firmware that the OS has no driver, so please enable the hack? I think not. Agreed on not hiding the bugs in the firmware. Moreover, M3 can't access the IPs in PER domain which is where the bad modules are, so the h/w doesn't support such hackery (+1 for the h/w after all the -1's that it gets ;) [...] That being said, IMO, the kernel (specifically omap_device) should handle this, and it should be rather easy to do in the omap_device layer and keep the SoC suspend/resume core code simple and ignorant of these quirks. AFAICT, there's no reason these quirks need to be dealt with immediatly on suspend. A slight delay should be fine, as long as it's before the next suspend/idle attempt, right? Given that, what we need to do (and by we, I mean you) is to flag all broken IP blocks, and let omap_device handle them in a suspend/resume notifier (c.f. register_pm_notifier() and PM_POST_SUSPEND.) yes - that is the alternate that comes to mind. In the earlier reviews of this series (many months ago now), I complained about the presence of this device specific handling in the core MPU PM code. I'm somewhat troubled by the fact that nobody explored alternatives that so easily come to mind. My bad. I was thinking along those lines [1] but after the suggestion on using the driver bound status i just went with that suggestion in the dumbest possible manner. Regards, Vaibhav [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129676.html -- 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 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Tue, Aug 27, 2013 at 5:45 PM, Kevin Hilman khil...@linaro.org wrote: [...] Looking closer at this code as I'm trying to fully get my head around all the IPC, I have some more comments. I think the split between pm33xx.c and the M3 driver is still confusing here. For example, am33xx_ping_wkup_m3(), am33xx_m3_state_machine_reset() and the guts of am33xx_pm_begin() all belong inside the M3 driver, along with all the wakeup_src stuff, which is info coming from the M3. IOW, the communication with M3 should be abstracted from pm33xx by the M3 driver (or possibly an eventual remoteproc/rpmsg implementation) with a well defined API. In this implementation, the interface is pretty fuzzy and mixed between pm33xx.c and wkup_m3.c. The reason for the current split was to have the M3 driver just do the minimal that's needed to talk to get M3 and MPU talking. What made me do it this way was to attempt to address a previous comment on keeping options open for folks to use M3 for things other than PM stuff. The IPC stuff is how implementors of the firmware (anything other than the PM one that TI provides) want it to be. The top level idea was to have the users of the firmware (PM in this case) decide what functionality they want when talking to M3. They are also free to decide the register bitfield layout and other IPC details. This was also a feeble attempt to keep things extensible for AM437x where in addition to the broken mailbox usage there's now a control module bit to trigger the interrupt to M3 (what's worse? pick one that you hate more ;) The AM437x PM routines could then just register different callbacks that are triggered when the M3 interrupts the MPU. Hope this clears up some of the confusion. Regards, Vaibhav -- 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: omap4 ehci sporadic resume issue
Hi Roger On Thu, Jul 4, 2013 at 10:53 AM, Michael Trimarchi mich...@amarulasolutions.com wrote: Hi On 07/02/2013 05:03 PM, Roger Quadros wrote: On 07/02/2013 05:49 PM, Michael Trimarchi wrote: Hi Roger On 07/02/2013 04:42 PM, Roger Quadros wrote: On 06/28/2013 07:47 PM, Michael Trimarchi wrote: Hi I'm working on PM consumption of other subsystem because it's a very complex device. Right now the pm consumption is sleep mode is 6mA just for (off mode disabled) omap4 + LPDDR2 and TWL6032 I don't exactly know if they have updated the last bootloader but I think so. I have tried to work on STP signal and re-enable it just before resume but nothing change Anyway my idea is the problem is releated on 18clk counter and an invalid state of the hw. I will try to implement save restore register by hand instead using the sar. Michael When you said earlier that the problem doesn't happen when one of the ULPIs is used did you try both of them individually. e.g. case 1: port 1 only enabled, case 2: port 2 only enabled. Did it work in both the cases? Yes, so I don't think could be a problem of ulpi pins and why this happen on both at the same time? Seems more connected to somenthing else. Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously. I'm not sure how to go about fixing this. How important is OFF Mode for your application. Can you keep it always disabled? Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline. Yes, our aim is to get it working with mainline as well. Last question: If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode? SAR restore will only happen when the Device enters OFF mode. Device OFF mode can only be reached when all voltage domains are switched OFF and that would depend if all power domains entered OFF or not. Just a simplistic explanation. You can refer to chapter 3.9.3 Device OFF State Management in the TRM. What happen if we ask to go in off mode for all domains but one doesn't go in off mode so the device will not go in off mode and the sar will not be used? How can work the restore? I have added a check of CM_RESTORE_ST. This register need to be clear before going in OFF mode and then show if the status of phase1 2a and 2b is completed. So before proceed with system resume and after resetting OFF_MODE bit I have tried to wait on this register, but without success. Michael 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 01/13] ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4
On Wed, Aug 21, 2013 at 3:13 AM, Rajendra Nayak rna...@ti.com wrote:
[...]
+/**
+ * omap4_cminst_clkdm_force_sleep - try to put a clockdomain to idle
+ * @part: PRCM partition ID that the clockdomain registers exist in
+ * @inst: CM instance register offset (*_INST macro)
+ * @cdoffs: Clockdomain register offset (*_CDOFFS macro)
+ *
+ * Put a clockdomain referred to by (@part, @inst, @cdoffs) to idle,
+ * forcing it to sleep. No return value.
+ */
+void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs)
+{
+ _clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, part, inst, cdoffs);
I guess this won't work on omap4/5 where some clockdomains do not support
SW_SLEEP and only support HW_AUTO. We might need to have different clkdm
operations for the different omap4 variants.
I am probably missing something here but doesn't omap4_clkdm_clk_disable() from
where this gets invoked have the appropriate flags in place already?
--
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] arm: dts: am33xx: correcting dt node unit address for usb
DT node's unit address should be its own register offset address to make it a
unique across the system. This patch corrects the incorrect USB entries with
correct register offset for unit address.
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..e9b6775 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -346,7 +346,7 @@
ti,hwmods = usb_otg_hs;
status = disabled;
- ctrl_mod: control@44e1 {
+ ctrl_mod: control@44e10620 {
compatible = ti,am335x-usb-ctrl-module;
reg = 0x44e10620 0x10
0x44e10648 0x4;
@@ -449,7 +449,7 @@
tx14, tx15;
};
- cppi41dma: dma-controller@07402000 {
+ cppi41dma: dma-controller@47402000 {
compatible = ti,am3359-cppi41;
reg = 0x4740 0x1000
0x47402000 0x1000
--
1.8.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
Re: [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
On Thu, Aug 29, 2013 at 5:33 PM, Kevin Hilman khil...@linaro.org wrote: [...] Maybe I'm getting confused, but the more you talk about the linux and the firmware doing the same code, the more I think the firmware is (trying) to do too much. If this is going to be understandable (and maintainable), there needs to be a clean split of roles between the MPU and the M3. In the past i tried to keep the firmware as minimal as possible and pushed back all efforts to push unnecessary stuff in there. Like Kevin, i too was of the opinion that we need to do whatever's possible in the kernel. Sadly, things just got a point where it made much more sense (technically as well as non-technically) to just put the low level stuff in the M3. 1. In addition to the Linux support, we have non-OS based code for AM335x (and AM437x) which in the past just had to duplicate whatever was done in the Linux. Being a different codebase the non-OS guys have their own set of challenges and we had to at times sit through and debug issues in one codebase while the other was working fine. Ideally these things should never come up but sadly they do and we need to solve them. We also have people trying to implement this thing on different sort of OS environments and they also end up debugging the same set of issues. With only a handful of folks able to spend time debugging issues 'do everything in Linux and expect others to copy it' model doesn't scale up. Keeping things in the firmware with the code available online helps do away with the 'developer scalability' problem and if one looks at things differently enables code-reuse at the same time. Yes, yes, this is the classic argument for a HAL, and making that case has always gone over well in the kernel. ;) If the carefully crafted C code with a bit of linker magic thrown in works, that's great but for anyone without the generic Linux code in general and the Linux community to go to with queries will have a tough time getting it done. TI non-OS code has been implemented from scratch and one of the purposes is to keep things as simple as possible for folks. I know it's all non-technical stuff and most likely i am a bit biased but just a different POV from someone who spent hours debugging 'this works and that doesn't' kind of issues. Trying to wrap your head around random s/w stacks and figuring out what needs to be changed is not pretty IMHO :\ Moreover, when the code was finally moved to M3, AFAICT we had validated all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT control) that TI hardware guys could throw at us.Yes there could be stupid bugs lurking in the code since it wasn't reviewed as much as i would have liked but we have something which proves the functionality to be used as the base. I don't follow the argument here. You mean it was validated *before* moving it to the M3, or after? Either way, I'm how that makes a case for moving it to the M3. Surely if it was on the MPU, it would also have been validated, no? At least i did all the validation without the VDD_CORE changes. The point i was trying to make is that we are not trying to hide bugs in there, if that's one of the concerns. Just trying to make it simple (subjective, i know) for others to use. 2. As has been already been pointed out by Russ, on AM335x this step needs to be done very late in the suspend process (the last stage actually). late, yes. But *technically*, it can still be done from the MPU. On the next SoC there are other complications related to security which enforce this step must be done from the M3. Aha! So far, the first technical reason I've seen. Can you elaborate? Exactly which step has to be done from the M3, and why can't the MPU do it? And could it be done more simply by putting *only* the parts needed on the M3 and not letting it snowball into a pile of stuff? Sent out another mail for this. Regards, Vaibhav -- 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] arm: dts: am33xx: correcting dt node unit address for usb
On Aug 30, 2013, at 12:52 PM, Mugunthan V N wrote:
DT node's unit address should be its own register offset address to make it a
unique across the system. This patch corrects the incorrect USB entries with
correct register offset for unit address.
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..e9b6775 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -346,7 +346,7 @@
ti,hwmods = usb_otg_hs;
status = disabled;
- ctrl_mod: control@44e1 {
+ ctrl_mod: control@44e10620 {
compatible = ti,am335x-usb-ctrl-module;
reg = 0x44e10620 0x10
0x44e10648 0x4;
@@ -449,7 +449,7 @@
tx14, tx15;
};
- cppi41dma: dma-controller@07402000 {
+ cppi41dma: dma-controller@47402000 {
Why isn't the unit address 4740 ?
compatible = ti,am3359-cppi41;
reg = 0x4740 0x1000
0x47402000 0x1000
--
1.8.4
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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
[GIT PULL] ARM: OMAP: Device Tree for 3.12 take #2
Hi Kevin Olof, Here is the updated version without the conflicting patch (ARM: dts: AM33XX: don't redefine OCP bus and device nodes) and with the signed tag. There is still a small conflict with usb-next, but it is easily fixable, and already fixed by Stephen. Thanks, Benoit The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb: Linux 3.11-rc6 (2013-08-18 14:36:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git tags/for_3.12/dts_signed for you to fetch changes up to 4843be165c10f9886c87eeb20acf19a3ddec6653: ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies (2013-08-30 21:33:13 +0200) Add the minimal DTS support for DRA7xx based SoC core. Add the initial support for N900 and gta04 phones. Enable USB3 on OMAP5 evm board. Do a lot of various cleanups. Afzal Mohammed (2): ARM: dts: AM4372: cpu(s) node per latest binding ARM: dts: AM4372: add few nodes Alexandre Belloni (1): ARM: dts: AM33XX: Add PMU support Benoit Cousson (1): ARM: OMAP5: hwmod: add missing ocp2scp hwmod data Felipe Balbi (4): ARM: OMAP5: dts: fix reg property size ARM: OMAP5: dts: fix ocp2scp DTS data ARM: OMAP5: dts: add palmas-usb node ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies Javier Martinez Canillas (4): ARM: dts: omap3-igep: add pinmux node for GPIO LED configuration ARM: dts: omap3-igep0020: add mux conf for GPIO LEDs ARM: dts: omap3-igep0030: add mux conf for GPIO LED ARM: dts: AM33XX: use pinmux node defined in included file Kishon Vijay Abraham I (1): ARM: dts: omap5-uevm: Split SMPS10 in two nodes Lars Poeschel (1): ARM: dts: AM33xx: Correct gpio #interrupt-cells property Lee Jones (7): ARM: dts: Remove '0x's from OMAP2420 H4 DTS file ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file ARM: dts: Remove '0x's from OMAP3 DTS file ARM: dts: Remove '0x's from OMAP3430 SDP DTS file ARM: dts: Remove '0x's from OMAP4 DTS file ARM: dts: Remove '0x's from OMAP5 DTS file Marek Belisko (1): ARM: dts: Add devicetree for gta04 board. Pavel Machek (1): ARM: dts: N900: Add device tree R Sricharan (1): ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board Robert Nelson (1): ARM: dts: omap3-beagle-xm: fix string error in compatible property Roger Quadros (1): ARM: dts: omap3-beagle: Make USB host pin naming consistent Ruslan Bilovol (1): ARM: dts: twl6030: Move common configuration for OMAP4 boards in a separate dtsi file arch/arm/boot/dts/Makefile | 5 +- arch/arm/boot/dts/am335x-bone.dts | 176 - arch/arm/boot/dts/am335x-evm.dts | 254 ++--- arch/arm/boot/dts/am335x-evmsk.dts | 258 ++--- arch/arm/boot/dts/am33xx.dtsi | 13 +- arch/arm/boot/dts/am4372.dtsi | 347 + arch/arm/boot/dts/dra7-evm.dts | 140 +++ arch/arm/boot/dts/dra7.dtsi| 575 + arch/arm/boot/dts/omap2420-h4.dts | 6 +- arch/arm/boot/dts/omap3-beagle-xm.dts | 2 +- arch/arm/boot/dts/omap3-beagle.dts | 24 +- arch/arm/boot/dts/omap3-gta04.dts | 168 + arch/arm/boot/dts/omap3-igep.dtsi | 2 + arch/arm/boot/dts/omap3-igep0020.dts | 19 +- arch/arm/boot/dts/omap3-igep0030.dts | 17 +- arch/arm/boot/dts/omap3-n900.dts | 92 + arch/arm/boot/dts/omap3.dtsi | 2 +- arch/arm/boot/dts/omap3430-sdp.dts | 22 +- arch/arm/boot/dts/omap4-panda-common.dtsi | 21 +- arch/arm/boot/dts/omap4-sdp.dts| 21 +- arch/arm/boot/dts/omap4.dtsi | 2 +- arch/arm/boot/dts/omap5-uevm.dts | 25 +- arch/arm/boot/dts/omap5.dtsi | 13 +- arch/arm/boot/dts/twl6030_omap4.dtsi | 38 ++ arch/arm/configs/omap2plus_defconfig | 9 + arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 +++ include/dt-bindings/pinctrl/dra.h | 50 +++ 27 files changed, 1912 insertions(+), 434 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/boot/dts/omap3-gta04.dts create mode 100644 arch/arm/boot/dts/omap3-n900.dts create mode 100644 arch/arm/boot/dts/twl6030_omap4.dtsi create mode 100644 include/dt-bindings/pinctrl/dra.h -- 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 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
Vaibhav Bedia vaibhav.be...@gmail.com writes: On Tue, Aug 27, 2013 at 5:45 PM, Kevin Hilman khil...@linaro.org wrote: [...] Looking closer at this code as I'm trying to fully get my head around all the IPC, I have some more comments. I think the split between pm33xx.c and the M3 driver is still confusing here. For example, am33xx_ping_wkup_m3(), am33xx_m3_state_machine_reset() and the guts of am33xx_pm_begin() all belong inside the M3 driver, along with all the wakeup_src stuff, which is info coming from the M3. IOW, the communication with M3 should be abstracted from pm33xx by the M3 driver (or possibly an eventual remoteproc/rpmsg implementation) with a well defined API. In this implementation, the interface is pretty fuzzy and mixed between pm33xx.c and wkup_m3.c. The reason for the current split was to have the M3 driver just do the minimal that's needed to talk to get M3 and MPU talking. What made me do it this way was to attempt to address a previous comment on keeping options open for folks to use M3 for things other than PM stuff. The IPC stuff is how implementors of the firmware (anything other than the PM one that TI provides) want it to be. IMO, there should actually be 3 levels. the SoC PM implementation (pm33xx.c), the M3 driver where the protocol, state-machine, etc. are handled, and the messaging layer. In the current proposal, the last 2 are combined, but I'd really like to see a generalized messaging layer that everyone else using an M3 coprocessor might use as well. As mentioned already, I think that should be rpmsg, but that still needs some exploration. The top level idea was to have the users of the firmware (PM in this case) decide what functionality they want when talking to M3. They are also free to decide the register bitfield layout and other IPC details. This was also a feeble attempt to keep things extensible for AM437x where in addition to the broken mailbox usage there's now a control module bit to trigger the interrupt to M3 (what's worse? pick one that you hate more ;) Sounds like AM43xx is better. If you have a control module bit to trigger an interrupt, why do you need the mailbox at all? The AM437x PM routines could then just register different callbacks that are triggered when the M3 interrupts the MPU. Hope this clears up some of the confusion. Thanks, Kevin -- 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: add AM33XX EDMA support
Hi Benoit,
On 08/26/2013 03:36 AM, Benoit Cousson wrote:
- minus all the TI emails which are not working anymore :-(
I've just sent my previous email too soon...
Now the patch is different :-) I'll take that one.
Unfortunately this patch is still missing from your latest pull request:
Subject [GIT PULL] ARM: OMAP: Device Tree for 3.12 take #2
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
tags/for_3.12/dts_signed (commit 4843be165c10f9886c87eeb20acf19a3ddec6653)
Below is a scissor patch that cleanly applies on above branch.
Thanks,
-Joel
---8
From: Matt Porter mpor...@ti.com
Subject: [PATCH] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
v2 changes:
Drop DT entries that are non-hardware-description Joel Fernandes jo...@ti.com
Discussion in [1].
v3 changes: Changed node name from edma: edma@ to edma: dma-controller@
by Sebastian Andrzej Siewior bige...@linutronix.de
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5996d63..f5869ed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -101,6 +101,18 @@
reg = 0x4820 0x1000;
};
+ edma: dma-controller@4900 {
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ reg = 0x4900 0x1,
+ 0x44e10f90 0x10;
+ interrupts = 12 13 14;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ };
+
gpio0: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
--
1.8.1.2
--
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
