Hi Tomi,
Thank for the patches.
On Tuesday 16 June 2015 13:16:22 Tomi Valkeinen wrote:
Hi,
I noticed that on some platforms omapdss did not probe successfully. Some
resource was not available yet, but omapdss did not manage to handle
deferred probing. The reason was the use of
Brian,
On 06/15/2015 02:32 PM, Kristo, Tero wrote:
On 06/15/2015 09:36 PM, Brian Hutchinson wrote:
Clocks 4-7 are capable of PWM output on dm816x.
This adds the pwm capability to those timers.
Use checkpatch pls, I see lots of whitespace errors.
Also, I don't think Mike / Stephen care
On Wed, Jun 17, 2015 at 12:04:07AM +0200, Rafael J. Wysocki wrote:
On Tue, Jun 16, 2015 at 11:40 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
by adding the missing MODULE_ALIAS(), cpufreq-dt
can be autoloaded by udev/systemd.
On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
by adding the missing MODULE_ALIAS(), cpufreq-dt
can be autoloaded by udev/systemd.
Signed-off-by: Felipe Balbi ba...@ti.com
looks like this wasn't applied anywhere. Viresh, can you apply this
patch please ?
---
On Tue, Jun 16, 2015 at 11:40 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, May 08, 2015 at 02:57:30PM -0500, Felipe Balbi wrote:
by adding the missing MODULE_ALIAS(), cpufreq-dt
can be autoloaded by udev/systemd.
Signed-off-by: Felipe Balbi ba...@ti.com
looks like this wasn't applied
On Tue, Jun 16, 2015 at 02:17:56PM -0500, Felipe Balbi wrote:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when running @ 400kHz and
duty cycle is lower than 34%.
The idea of
See Documentation/DMA-API.txt - Part Id
Signed-off-by: Fabian Frederick f...@skynet.be
---
This is untested.
drivers/mmc/host/omap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 68dd6c7..70dcf07 100644
---
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages when running @ 400kHz and
duty cycle is lower than 34%.
The idea of
On Tue, Jun 16, 2015 at 02:20:45PM -0500, Felipe Balbi wrote:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is that some devices present an erratic behavior
with certain duty cycles.
One such example is TPS65218 PMIC which fails
to change voltages
Hello,
Mrs. Liliane picked you. For details email her
directly: lilbetencou...@hotmail.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
From: Kishon Vijay Abraham I kis...@ti.com
DTO/DCRC errors were not being informed to the mmc core since
commit ae4bf788ee9b (mmc: omap_hsmmc: consolidate error report handling of
HSMMC IRQ). This commit made sure 'end_trans' is never set on DTO/DCRC
errors. This is because after this commit
On Fri, Jun 12, 2015 at 9:10 AM, Uwe Kleine-König
u.kleine-koe...@pengutronix.de wrote:
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value
Refactor dss probe function by extracting the setup for video plls into
a separate function. The call to this function is also moved to a
slightly earlier phase, so that in error case we can bail out more
easily.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
omapdss kernel module contains drivers for multiple devices, one for
each DSS submodule. The probing we have at the moment is a mess, and
doesn't give us proper deferred probing nor ensure that all the devices
are probed before omapfb/omapdrm start using omapdss.
This patch solves the mess by
Now that we are using components in omapdss, there's no need for
separate handling of dss and dispc driver init. Thus we can move the dss
and dispc init and unit func pointers to the lists we use for the other
dss submodules.
We can now also handle errors returned by the registration functions
The following patches will add component handling to omapdss, improving
the handling of deferred probing. However, at the moment we're using
quite a lot of __inits and __exits in the driver, which prevent normal
dynamic probing and removal.
This patch removes most of the uses of __init and
The return value of dss_init_ports() is not handled at all, causing
crashes later if the call failed.
This patch adds the error handling, and we also move the call to a
slightly earlier place to make bailing out easier.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
We have a list of function pointers to dss submodule uninit functions.
It makes sense to do the uninit in the reverse order to init, but that
is not currently the case.
This patch reorders the uninit calls to be the reverse of init order.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Hi,
I noticed that on some platforms omapdss did not probe successfully. Some
resource was not available yet, but omapdss did not manage to handle deferred
probing. The reason was the use of platform_driver_probe() in combination with
how the omapdss module handles the drivers.
To fix this
We have a flag, 'dss_initialized', which tells omapfb and omapdrm if
omapdss is available. At the moment it can be set even if the dss
submodules are not all ready, in case something gets deferred.
Move the flag to dss_core driver so that it'll signal the availability
of the dss drivers move
Hi,
When using omap_hsmmc driver, if sd-card repeatedly plug unplugged
multiple times quickly, card enumeration stops after few iterations.
This can be easily reproduced on DRA74X EVM which uses omap_hsmmc driver.
This patch series addresses the above problem. The first patch fixes irq
handler
Usually when there is an error in transfer, DTO/CTO or other error
interrupts are raised. But if the card is unplugged in the middle of a
data transfer, it is observed that, neither completion(success) or
timeout(error) interrupts are raised. Hence, the mmc-core is waiting
for-ever for the
Sometimes BADA, DEB or CEB error interrupts occur when sd card is
unplugged during data transfer. These interrupts are currently ignored
by the interrupt handler. But, this results in card not being
recognised on subsequent insertion. This is because mmcqd is waiting
forever for the data
Hi,
Here's a late pull request that would be good to get into v4.2.
This series mostly just drops code that's now unnecessary, and
also fixes potential interrupt re-entrancy issues that the old
handling has.
The series changes omap hsmmc, 8250_omap and omap-serial to use
the Linux generic
25 matches
Mail list logo
