Hi Tony,
* Rajendra Nayak [120730 06:17]:
regulators do not have a 'reg' property, hence the regulator@0,
regulator@1 do not make sense. get rid of it.
Looks like this needs to be refreshed to apply. Care to
refresh against current devel-dt branch in case other
places need the same change?
On 8/25/2012 1:44 AM, Tony Lindgren wrote:
> * AnilKumar Ch [120816 05:20]:
>> Add D_CAN1 pinctrl node to am3358_pinmux master node to export
>> D_CAN functionality on AM335x EVM according to pinctrl-single
>> driver.
>>
>> Signed-off-by: AnilKumar Ch
>> ---
>> Changes from v2:
>> - Incorp
Hi Koen,
On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote:
>
> Op 24 aug. 2012, om 09:56 heeft Koen Kooi het
> volgende geschreven:
>
> >
> > Op 24 aug. 2012, om 09:26 heeft "AnilKumar, Chimata" het
> > volgende geschreven:
> >
> >> Hi Koen,
> >>
> >> On Fri, Aug 24, 2012 at 11:58:34, Ko
On Mon, Aug 27, 2012 at 4:26 PM, Aaro Koskinen wrote:
> On Mon, Aug 27, 2012 at 03:12:07PM -0700, Shilimkar, Santosh wrote:
>> On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen wrote:
>> > Hi,
>> >
>> > On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
>> >> > - pr_err("%s se
This series converts the OMAP hardware random number generator driver
to use runtime PM. Hardware integration data is added for OMAP2xxx
systems. I'm pretty sure this device is available on other OMAP chips
too, but may require some experimentation with the integration details.
There are still a
Convert the OMAP onboard hardware RNG driver to use runtime PM.
This allows us to remove some OMAP-specific cpu_is_omap*() calls from
the RNG driver.
Signed-off-by: Paul Walmsley
Cc: Matt Mackall
Cc: Herbert Xu
---
drivers/char/hw_random/omap-rng.c | 35 +--
Move the OMAP1-specific RNG device creation off to mach-omap1/devices.c,
and create a omap_device-backed registration function for OMAP2+ devices
in mach-omap2/devices.c.
As a nice side-benefit, we can also get rid of
arch/arm/plat-omap/devices.c, thanks to some of the recent changes
from Tony.
O
Remove the SoC restriction code from the OMAP RNG driver. The
integration code in arch/arm/*omap* should handle this. The device
shouldn't be created if it doesn't exist on the currently-booted SoC.
This allows us to remove some OMAP-specific cpu_is_omap*() calls from
the driver. Also, if other
Encapsulate all of the RNG per-device state into a single per-device
structure record, as opposed to a set of per-driver file variables.
Signed-off-by: Paul Walmsley
Cc: Matt Mackall
Cc: Herbert Xu
---
drivers/char/hw_random/omap-rng.c | 115 +
1 file chang
Add integration data for the hardware random number generator IP block
on some OMAP SoCs. This appears to be present on OMAP2xxx and OMAP3xxx
SoCs, although it is not so easy to tell. It may also be present on
other OMAP2+ SoCs.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_2
On Mon, Aug 27, 2012 at 03:12:07PM -0700, Shilimkar, Santosh wrote:
> On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen wrote:
> > Hi,
> >
> > On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
> >> > - pr_err("%s seen by %s %s at address %x\n",
> >> > + pr_err_ratelimite
Hi,
On Tue, Aug 21 2012, Felipe Balbi wrote:
> On Sat, Aug 18, 2012 at 12:22:20AM +0530, Venkatraman S wrote:
>> Essentially, a lot of cleanups leading up to adding a new
>> feature for OMAP HSMMC. The idea is to convert to the use
>> of software timer instead of IP timer for timekeeping, due
>> t
On Mon, Aug 27, 2012 at 3:26 PM, Igor Grinberg wrote:
> Currently, omap2_sync32k_clocksource_init() function initializes the 32K
> timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER
> setting.
> Fix this by providing a default implementation for
> !CONFIG_OMAP_32K_TIMER case.
Hi,
On Fri, Aug 24 2012, Paul Walmsley wrote:
> After commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 ("mmc:
> omap_hsmmc: remove private DMA API implementation"), the Nokia N800
> here stopped booting:
>
> [2.086181] Waiting for root device /dev/mmcblk0p1...
> [2.324066] Unhandled fault:
Currently, omap2_sync32k_clocksource_init() function initializes the 32K
timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER
setting.
Fix this by providing a default implementation for
!CONFIG_OMAP_32K_TIMER case.
Signed-off-by: Igor Grinberg
Reviewed-by: Paul Walmsley
---
On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
>> > - pr_err("%s seen by %s %s at address %x\n",
>> > + pr_err_ratelimited("%s seen by %s %s at address %x\n",
>> > omap3_l3_code
Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core:
Ensure drvdata = NULL when no driver is bound', the Amstrad Delta sound
card no longer initializes correctly due to drvdata reset to NULL by an
upper layer before the codec device, required for successful card setup,
is registered
Hi,
On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
> > - pr_err("%s seen by %s %s at address %x\n",
> > + pr_err_ratelimited("%s seen by %s %s at address %x\n",
> > omap3_l3_code_string(code),
> > omap3_l3_initiator_s
On Mon, Aug 27, 2012 at 11:28:30PM +0200, Janusz Krzysztofik wrote:
> - platform_set_drvdata(ams_delta_audio_platform_device,
> - &ams_delta_audio_card);
> -
> - ret = platform_device_add(ams_delta_audio_platform_device);
> - if (ret)
> - goto er
On Mon, Aug 27, 2012 at 2:03 PM, Aaro Koskinen wrote:
>
> When booting kernel on RM-680/N950, the console is flooded with:
>
> [6.894348] In-band Error seen by MPU at address 0
> [6.894348] [ cut here ]
> [6.894378] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c
When booting kernel on RM-680/N950, the console is flooded with:
[6.894348] In-band Error seen by MPU at address 0
[6.894348] [ cut here ]
[6.894378] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162
omap3_l3_app_irq+0xd4/0x12c()
[6.894378] Modules linked
Hi Afzal,
On 08/27/2012 05:37 AM, Mohammed, Afzal wrote:
> On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:
[snip]
>> I understand that this is based upon how timings for onenand and tusb
>> are being calculated today, but I am not sure that this is the way to go
>> for all devices. Personal
On Fri, Aug 24, 2012 at 12:40:37PM +0530, Arun Raghavan wrote:
> It's been in shambles for an absurdly long time. Would be good to
> actually try to tackle it again at Plumbers or sth.
I think all this really needs is someone with the time to do the work -
it's more a coding problem with unifying
On Tue, Aug 28, 2012 at 00:06:45, Paul Walmsley wrote:
> On Mon, 27 Aug 2012, Hiremath, Vaibhav wrote:
>
> > On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote:
> >
> > > Is the dcan driver present in v3.6-rc kernels?
> >
> > Multiple versions have been submitted already, I have validated us
On Mon, 27 Aug 2012, Hiremath, Vaibhav wrote:
> On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote:
>
> > Is the dcan driver present in v3.6-rc kernels?
>
> Multiple versions have been submitted already, I have validated using them.
> Irrespective of this, it is independent change and requir
On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote:
> Hi
>
> On Mon, 27 Aug 2012, Vaibhav Hiremath wrote:
>
> > Currently, the device names for the dcan module follows the
> > format "dcan.X", where 'X' is the dcan instance number.
> > On other side, driver may request for clock with/without c
Hi
On Mon, 27 Aug 2012, Vaibhav Hiremath wrote:
> Currently, the device names for the dcan module follows the
> format "dcan.X", where 'X' is the dcan instance number.
> On other side, driver may request for clock with/without con_id
> and dev_id, and it is expected that platform should respect t
On Mon, 16 Jul 2012, Vaibhav Hiremath wrote:
> With commit ae6df418a21f3a361c5f9b878e32a8aba4e17692
> Sub: ARM: OMAP2+: dmtimer: cleanup fclk usage)
> The Timer functional clock naming convention has changed from
> gptX_fck => timerXfck, and so as the timer init function
> in mach-omap2/timer.c.
>
On Fri, Aug 24, 2012 at 01:16:34PM -0700, Tony Lindgren wrote:
> * Mark Brown [120821 11:09]:
> > The board shouldn't have to define the regulators, the regulator driver
> > really ought to be able to figure out that they're there by itself if
> > there's no configuration based purely on knowing
Hi Daniel,
On Mon, Aug 27, 2012 at 19:00:32, Daniel Mack wrote:
> So the GPMC driver is the one that is matched from DT, and the NAND
> driver will the be instanciated from the (generic) GPMC driver?
I think you were referring to nand device being instantiated from
gpmc driver?, hence resulting
On 27.08.2012 14:38, Mohammed, Afzal wrote:
> On Mon, Aug 27, 2012 at 17:46:17, Daniel Mack wrote:
>
>>> Such a generic routine would help create a driver out of gpmc platform
>>> code, which would be peripheral agnostic and thus lead to DT finally.
>>> Input to generic timing calculation routine
Hi Daniel,
On Mon, Aug 27, 2012 at 17:46:17, Daniel Mack wrote:
> > Such a generic routine would help create a driver out of gpmc platform
> > code, which would be peripheral agnostic and thus lead to DT finally.
> > Input to generic timing calculation routine would be gpmc peripheral
> > timings
The device/node resources (like, IORESOURCE_MEM and IORESOURCE_IRQ)
are overwritten by hwmod resources, due to all known reasons but
that should not be the reason for not providing all the information
in the DTS blob. Ideally we should use DTS resource and use HWMOD
framework wherever required and
To make it consistent, convert all hex number presentation
to lower-case from all am33xx specific nodes.
Signed-off-by: Vaibhav Hiremath
Cc: Tony Lindgren
---
arch/arm/boot/dts/am335x-bone.dts |2 +-
arch/arm/boot/dts/am335x-evm.dts |2 +-
arch/arm/boot/dts/am33xx.dtsi | 20 +
This series is trivial patch-series and should be considered as
preparation for the future where we supposed to get rid of
hwmod dependency.
1/2: Converts all hex numbers to lowercase, fixing inconsistency
2/2: Add reg and interrupt property to all device/module nodes inside
DTS files.
Alt
Hi Afzal,
On 21.08.2012 12:41, Afzal Mohammed wrote:
> This series provides a generic gpmc timing calculation routine. There
> were three peripherals (OneNAND, tusb6010, smc91x) using custom timing
> calculations, they are migrated to use the generic timing calculation.
>
> Such a generic routine
Hi Tony,
On Sat, Aug 25, 2012 at 01:24:47, Tony Lindgren wrote:
> Yes agreed. Also as some values make sense only in cycles, converting them
> back and forth to time is wrong. So at least some values should have an
> option to specify them in cycles directly, and then ignore any time based
> valu
On 08/27/12 12:25, Jean Pihet wrote:
> Hi Timo,
>
> On Fri, Aug 24, 2012 at 10:39 PM, Tony Lindgren wrote:
>> * Timo Kokkonen [120824 08:11]:
>>> Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat
>>> API to the new PM QoS API. This allows the callback to be removed from
>>> the
On Tue, Aug 21, 2012 at 9:08 PM, Shubhrajyoti Datta
wrote:
> Hi Venkat,
> Some doubts below.
>
> On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S wrote:
>> SYSCONFIG register of HSMMC IP is managed by the omap hwmod
>> abstraction layer.
>
> At init only right?
Yes.
>
>
>> Resetting the IP and con
On Tue, Aug 21, 2012 at 8:51 PM, T Krishnamoorthy, Balaji
wrote:
> On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S wrote:
>> Flushing spurious IRQs from HSMMC IP is done twice in
>> omap_hsmmc_irq and omap_hsmmc_do_irq.
>
> spurious IRQ is flushed in start of omap_hsmmc_do_irq
> and irq acked at
Hi Jon,
On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:
> On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
> > +/* can the cycles be avoided ? */
>
> What is the above comment referring too?
This was added in the initial stages and refers to the usage of
cycles in struct gpmc_device_timings.
Currently, the device names for the dcan module follows the
format "dcan.X", where 'X' is the dcan instance number.
On other side, driver may request for clock with/without con_id
and dev_id, and it is expected that platform should respect this
request and return the requested clock handle.
Now, w
On Mon, 2012-08-27 at 14:23 +0530, Chandrabhanu Mahapatra wrote:
> The DISPC_IRQ bit definitions pertaining to channel LCD3 as DISPC_IRQ_VSYNC3,
> DISPC_IRQ_SYNC_LOST3, DISPC_IRQ_ACBIAS_COUNT_STAT3 AND DISPC_IRQ_FRAMEDONE3
> which were incorrectly set in previous LCD3 patches have been corrected he
Hi Timo,
On Fri, Aug 24, 2012 at 10:39 PM, Tony Lindgren wrote:
> * Timo Kokkonen [120824 08:11]:
>> Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat
>> API to the new PM QoS API. This allows the callback to be removed from
>> the platform data structure.
>>
>> The latency req
The DISPC_IRQ bit definitions pertaining to channel LCD3 as DISPC_IRQ_VSYNC3,
DISPC_IRQ_SYNC_LOST3, DISPC_IRQ_ACBIAS_COUNT_STAT3 AND DISPC_IRQ_FRAMEDONE3
which were incorrectly set in previous LCD3 patches have been corrected here.
Reported-by: Mark Tyler
Signed-off-by: Chandrabhanu Mahapatra
--
Hi Tony,
On Sat, Aug 25, 2012 at 01:16:30, Tony Lindgren wrote:
> This hangs n800 during the boot.
Shall I read the above as n800 boot without patch 10/10,
but with the other patches in this series ?
As per the board file, n800 has tusb6010 as well as
OneNAND in sync read & async write mode, wa
46 matches
Mail list logo
