Hi,
On Fri, Jun 07, 2013 at 02:49:50PM -0700, Tony Lindgren wrote:
> We want to get rid of the omap specific platform init code
> callbacks as they don't play nice with device tree.
right, any plans to have similar functionality generically ? Maybe
something like:
probe()
{
...
Am Samstag, 8. Juni 2013, 01:13:48 schrieb Heiko Stübner:
> Am Freitag, 7. Juni 2013, 14:53:51 schrieb Linus Walleij:
> > On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner wrote:
> > > + for (i = 0, j = 0; i < size; i += 4, j++) {
> > > + unsigned long pinconf;
> > > +
> > > +
Am Freitag, 7. Juni 2013, 14:53:51 schrieb Linus Walleij:
> On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner wrote:
> > + for (i = 0, j = 0; i < size; i += 4, j++) {
> > + unsigned long pinconf;
> > +
> > + num = be32_to_cpu(*list++);
> > + bank = bank_
Hi all,
Here are the update SDIO remuxing patches that are based on Andreas'
earlier patches. The remuxing part is still in discussion, but that
can be merged later in case there's some way to do it automatically
at the drivers/base/pinctrl.c level.
I've used these patches successfully with wl12x
We want to get rid of the omap specific platform init code
callbacks as they don't play nice with device tree.
Let's convert the context loss check to be based on a
register state detection instead.
Cc: Andreas Fenkart
Cc: Balaji T K
Signed-off-by: Tony Lindgren
---
drivers/mmc/host/omap_hsmm
On some omaps we need to remux MMC pins for PM, and for some omaps
we need to remux the SDIO IRQ pin.
Based on an earlier patch by Andreas Fenkart .
Cc: Andreas Fenkart
Cc: Balaji T K
Cc: Linus Walleij
Signed-off-by: Tony Lindgren
---
drivers/mmc/host/omap_hsmmc.c | 93
From: Andreas Fenkart
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_
From: Andreas Fenkart
Update the debugfs related code for the SDIO support.
Note that PSTATE shows current state of data lines.
Cc: Andreas Fenkart
Cc: Balaji T K
Signed-off-by: Andreas Fenkart
[t...@atomide.com: combined both sysfs patches into one]
---
drivers/mmc/host/omap_hsmmc.c | 26
* Balaji T K [130607 06:42]:
> On Tuesday 04 June 2013 08:16 PM, Tony Lindgren wrote:
> >* Hebbar Gururaja [130531 03:19]:
> >>Amend the hsmmc controller to optionally take a pin control handle and
> >>set the state of the pins to:
> >>
> >>- "default" on boot, resume and before performing a mmc
On 07/06/2013 12:14, Gregory CLEMENT wrote:
On 06/07/2013 11:32 AM, boris brezillon wrote:
On 07/06/2013 11:22, Nicolas Ferre wrote:
On 07/06/2013 10:34, Boris BREZILLON :
Hello,
This patch series is a proposal to move at91 clock implementation
to common clk framework.
Before discussion begi
On 07/06/2013 11:22, Nicolas Ferre wrote:
On 07/06/2013 10:34, Boris BREZILLON :
Hello,
This patch series is a proposal to move at91 clock implementation
to common clk framework.
Before discussion begins I would like to give my kudos to you Boris!
This is huge work and I thank you for it: It
Tomasz,
On Fri, Jun 7, 2013 at 10:42 AM, Tomasz Figa wrote:
> A question just out of curiousity: Is it really correct to have one vmmc
> regulator for the whole device, instead of one regulator per slot?
>
> This might be something obvious, but I don't know any details about
> dw_mmc, so sorry if
On Friday 07 of June 2013 10:28:29 Doug Anderson wrote:
> It is possible to specify a regulator that should be turned on when
> dw_mmc is probed. At the moment dw_mmc will fail to use the regulator
> properly if the regulator probes after dw_mmc. Fix this problem by
> honoring EPROBE_DEFER.
>
>
As of now we rely on code outside of the driver to set the ciu clock
frequency. There's no reason to do that. Add support for setting up
the clock in the driver during probe.
Signed-off-by: Doug Anderson
Acked-by: Jaehoon Chung
---
Changes in v2:
- Added example as per Jaehoon.
.../devicetre
It is possible to specify a regulator that should be turned on when
dw_mmc is probed. At the moment dw_mmc will fail to use the regulator
properly if the regulator probes after dw_mmc. Fix this problem by
honoring EPROBE_DEFER.
At the same time move the regulator code out of the slot init code.
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON
---
drivers/mmc/host/atmel-mci.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/atmel-mci.c b/driv
On 7 June 2013 20:27, Heiko Stübner wrote:
> Am Freitag, 7. Juni 2013, 13:46:32 schrieb Linus Walleij:
>> On Thu, Jun 6, 2013 at 9:08 PM, Heiko Stübner wrote:
>> > There exist platforms, namely at least all Rockchip Cortex-A9 based ones,
>> > that don't use the paradigm of reading-changing-writin
Tomasz / Mark,
On Fri, Jun 7, 2013 at 3:30 AM, Tomasz Figa wrote:
> On Friday 07 of June 2013 11:24:04 Mark Brown wrote:
>> On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote:
>> > This interesting case makes me think that regulator core should
>> > differentiate between regulator lookup
Hello,
Sorry for the noise, the first submission has been filtered.
This patch series is a proposal to move at91 clock implementation
to common clk framework.
Most of the clock provided by the PMC (Power Management Controller) are
implemented :
- main clock (main oscillator)
- pll clocks
- maste
On Tuesday 04 June 2013 08:16 PM, Tony Lindgren wrote:
* Hebbar Gururaja [130531 03:19]:
Amend the hsmmc controller to optionally take a pin control handle and
set the state of the pins to:
- "default" on boot, resume and before performing a mmc transfer
- "idle" after initial default, after r
On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner wrote:
> This driver adds support the Cortex-A9 based SoCs from Rockchip,
> so at least the RK2928, RK3066 (a and b) and RK3188.
> Earlier Rockchip SoCs seem to use similar mechanics for gpio
> handling so should be supportable with relative small cha
Am Freitag, 7. Juni 2013, 13:46:32 schrieb Linus Walleij:
> On Thu, Jun 6, 2013 at 9:08 PM, Heiko Stübner wrote:
> > There exist platforms, namely at least all Rockchip Cortex-A9 based ones,
> > that don't use the paradigm of reading-changing-writing the register
> > contents, but instead only wri
Hello,
This patch series is a proposal to move at91 clock implementation
to common clk framework.
Most of the clock provided by the PMC (Power Management Controller) are
implemented :
- main clock (main oscillator)
- pll clocks
- master clock
- programmable clocks
- utmi clock
- peripheral clocks
On Thu, Jun 6, 2013 at 9:08 PM, Heiko Stübner wrote:
> There exist platforms, namely at least all Rockchip Cortex-A9 based ones,
> that don't use the paradigm of reading-changing-writing the register contents,
> but instead only write the changes to the register with a mask that indicates
> the c
Dear Chris,
If you didn't have any comment, Could you merge this patch, plz?
Best Regards,
Jaehoon Chung
On 05/27/2013 01:10 PM, Jaehoon Chung wrote:
> When use the QUIRK_NONSTANDARD_CLOCK, then never set to 0 at clock control
> register.
> This patch is fixed this problem.
>
> Signed-off-by:
Hi,
On Fri, Jun 07 2013, Sekhar Nori wrote:
> + Chris since the patch has some davinci_mmc.c changes.
>
> Chris, Mark,
>
> On 3/6/2013 9:45 PM, Matt Porter wrote:
>> Move mach-davinci/dma.c to common/edma.c so it can be used
>> by OMAP (specifically AM33xx) as well.
>>
>> Signed-off-by: Matt Port
On Friday 07 of June 2013 11:24:04 Mark Brown wrote:
> On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote:
> > On Thursday 06 of June 2013 21:46:45 Doug Anderson wrote:
> > > dw_mmc is probed. This regulator is optional, though a warning will
> > > be printed if it's missing. The fact th
On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote:
> On Thursday 06 of June 2013 21:46:45 Doug Anderson wrote:
> > dw_mmc is probed. This regulator is optional, though a warning will
> > be printed if it's missing. The fact that the regulator is optional
> > means that (at the moment)
Hi Doug,
On Thursday 06 of June 2013 21:46:45 Doug Anderson wrote:
> It is possible to specify a regulator that should be turned on when
> dw_mmc is probed. This regulator is optional, though a warning will
> be printed if it's missing. The fact that the regulator is optional
> means that (at th
On 06/07/2013 11:32 AM, boris brezillon wrote:
> On 07/06/2013 11:22, Nicolas Ferre wrote:
>> On 07/06/2013 10:34, Boris BREZILLON :
>>> Hello,
>>>
>>> This patch series is a proposal to move at91 clock implementation
>>> to common clk framework.
>>
>> Before discussion begins I would like to give
On 07/06/2013 10:34, Boris BREZILLON :
Hello,
This patch series is a proposal to move at91 clock implementation
to common clk framework.
Before discussion begins I would like to give my kudos to you Boris!
This is huge work and I thank you for it: It is so great!
I am sure that Jean-Christo
31 matches
Mail list logo