Hi Jean-Philippe,
I finally create my patch against f5cef8f45739db4c0c1c346296922cac274c87eb
in attachment, but the problem is that isif_set_hw_if_params is not called
by gstreamer.
If I set in drivers/media/video/davinci/isif.c (and not in
drivers/media/video/davinci/dm365_ccdc.c as I don't
I suppose it does not work, because isif_set_hw_if params is only called
if the user applications is doing a VIDIOC_S_INPUT.
based on your log, it seems gstreamer does not do that.
I don't know if the driver or the application should be corrected.
May be there is a command switch to gstreamer
Hello everybody.
If I'm not wrong it doesn't yet exist the voice codec for dm365.
Is there any roadmap to support this peripheral?
Thank in advance.
2010/4/1 Raffaele Recalcati lamiapost...@gmail.com
It seems that in git kernel this peripheral is not yet supported.
I search everywere:
Mike -
I do plan on resubmitting the driver as a replacement driver (remove the old
and add the updated version) as suggested by TI. I am just trying to get some
other work finished up first. If you want to try the version I submitted, the
patch was actually against the arago kernel. You
Hi Kevin,
Both the existing functions and the new functions all do basically the same
thing:
- read base + offset
- set/clear bit(s) based on GPIO#
- write base + offset
Davinci doesn't really do a read-modify-write. Instead, it sets bits
into set_data/clr_data registers to indirectly
This patch series contains a bundle of common code changes that are needed as
a precursor to adding tnetv107x soc support.
Some of these patches were sent out separately earlier, but have also been
included here.
This patch series has been boot-up tested on dm365, thanks to Sandeep.
Cyril
This patch allows socs to override the divider ratio mask by setting an
optional field (div_ratio_mask) in the pll_data structure.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Tested-by: Sandeep Paulraj s-paul...@ti.com
---
arch/arm/mach-davinci/clock.c |9 ++---
This patch allows for gpio controllers that deviate from those found on
traditional davinci socs. davinci_soc_info has an added field to indicate the
soc-specific gpio controller type. The gpio initialization code then bails
out of necessary.
More elements (tnetv107x) to be added later into
This patch adopts a debug uart selection similar to the OMAP model. During
the boot process, the uncompress code determines the physical and virtual base
addresses of the board-specific debug uart. These addresses are then passed
on to the in-kernel debug macros through a small chunk of memory
macroized repeated container_of()s to improve readability.
unified direction in/out functions.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Tested-by: Sandeep Paulraj s-paul...@ti.com
---
arch/arm/mach-davinci/gpio.c | 47 +
1 files changed, 24
This patch allows for a more flexible ioremap() interception. The mechanism
works by translating physical addresses based on soc-specific iotable
contents (davinci_soc_info.io_desc), once davinci_soc_info is populated by
davinci_common_init().
Signed-off-by: Cyril Chemparathy cy...@ti.com
Renamed gpio structures to something more sensible:
struct gpio_controller -- struct davinci_gpio_regs
struct davinci_gpio -- struct davinci_gpio_controller
This change also moves davinci_gpio_controller definition to gpio.h.
Eventually, the gpio registers structure will be
This patch eliminates the global gpio_lock, and implements a per-controller
lock instead. This also switches to irqsave/irqrestore locks in case gpios
are manipulated in isr.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Tested-by: Sandeep Paulraj s-paul...@ti.com
---
This patch renders the inlined gpio accessors in gpio.h independent of the
underlying controller's register layout. This is done by including three new
fields in davinci_gpio_controller to hold the addresses of the set, clear, and
in data registers.
Other changes:
1. davinci_gpio_regs structure
Howdy,
I don't know if this is the proper place for this, so please direct me
elsewhere if it is not.
I get a LOT of NAND bad eraseblocks when booting my dm6467t DVEVM. I've
never dealt with NAND ROM before so I was surprised by how many bad
eraseblocks are generated. I've seen elsewhere
15 matches
Mail list logo