All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
@ 2011-04-27 15:40 ` Rafał Miłecki
  0 siblings, 0 replies; 9+ messages in thread
From: Rafał Miłecki @ 2011-04-27 15:40 UTC (permalink / raw)
  To: linux-wireless, John W. Linville, Michael Büsch
  Cc: b43-dev, Rafał Miłecki

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
 drivers/ssb/driver_chipcommon.c |   60 ++++++++++++++++++++++++++++-----------
 1 files changed, 43 insertions(+), 17 deletions(-)

diff --git a/drivers/ssb/driver_chipcommon.c b/drivers/ssb/driver_chipcommon.c
index b4b3733..06d15b6 100644
--- a/drivers/ssb/driver_chipcommon.c
+++ b/drivers/ssb/driver_chipcommon.c
@@ -46,40 +46,66 @@ void ssb_chipco_set_clockmode(struct ssb_chipcommon *cc,
 	if (!ccdev)
 		return;
 	bus = ccdev->bus;
+
+	/* We support SLOW only on 6..9 */
+	if (ccdev->id.revision >= 10 && mode == SSB_CLKMODE_SLOW)
+		mode = SSB_CLKMODE_DYNAMIC;
+
+	if (cc->capabilities & SSB_CHIPCO_CAP_PMU)
+		return; /* PMU controls clockmode, separated function needed */
+	SSB_WARN_ON(ccdev->id.revision >= 20);
+
 	/* chipcommon cores prior to rev6 don't support dynamic clock control */
 	if (ccdev->id.revision < 6)
 		return;
-	/* chipcommon cores rev10 are a whole new ball game */
+
+	/* ChipCommon cores rev10+ need testing */
 	if (ccdev->id.revision >= 10)
 		return;
+
 	if (!(cc->capabilities & SSB_CHIPCO_CAP_PCTL))
 		return;
 
 	switch (mode) {
-	case SSB_CLKMODE_SLOW:
+	case SSB_CLKMODE_SLOW: /* For revs 6..9 only */
 		tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
 		tmp |= SSB_CHIPCO_SLOWCLKCTL_FSLOW;
 		chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
 		break;
 	case SSB_CLKMODE_FAST:
-		ssb_pci_xtal(bus, SSB_GPIO_XTAL, 1); /* Force crystal on */
-		tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
-		tmp &= ~SSB_CHIPCO_SLOWCLKCTL_FSLOW;
-		tmp |= SSB_CHIPCO_SLOWCLKCTL_IPLL;
-		chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
+		if (ccdev->id.revision < 10) {
+			ssb_pci_xtal(bus, SSB_GPIO_XTAL, 1); /* Force crystal on */
+			tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
+			tmp &= ~SSB_CHIPCO_SLOWCLKCTL_FSLOW;
+			tmp |= SSB_CHIPCO_SLOWCLKCTL_IPLL;
+			chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
+		} else {
+			chipco_write32(cc, SSB_CHIPCO_SYSCLKCTL,
+				(chipco_read32(cc, SSB_CHIPCO_SYSCLKCTL) |
+				 SSB_CHIPCO_SYSCLKCTL_FORCEHT));
+			/* udelay(150); TODO: not available in early init */
+		}
 		break;
 	case SSB_CLKMODE_DYNAMIC:
-		tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
-		tmp &= ~SSB_CHIPCO_SLOWCLKCTL_FSLOW;
-		tmp &= ~SSB_CHIPCO_SLOWCLKCTL_IPLL;
-		tmp &= ~SSB_CHIPCO_SLOWCLKCTL_ENXTAL;
-		if ((tmp & SSB_CHIPCO_SLOWCLKCTL_SRC) != SSB_CHIPCO_SLOWCLKCTL_SRC_XTAL)
-			tmp |= SSB_CHIPCO_SLOWCLKCTL_ENXTAL;
-		chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
-
-		/* for dynamic control, we have to release our xtal_pu "force on" */
-		if (tmp & SSB_CHIPCO_SLOWCLKCTL_ENXTAL)
-			ssb_pci_xtal(bus, SSB_GPIO_XTAL, 0);
+		if (ccdev->id.revision < 10) {
+			tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
+			tmp &= ~SSB_CHIPCO_SLOWCLKCTL_FSLOW;
+			tmp &= ~SSB_CHIPCO_SLOWCLKCTL_IPLL;
+			tmp &= ~SSB_CHIPCO_SLOWCLKCTL_ENXTAL;
+			if ((tmp & SSB_CHIPCO_SLOWCLKCTL_SRC) !=
+			    SSB_CHIPCO_SLOWCLKCTL_SRC_XTAL)
+				tmp |= SSB_CHIPCO_SLOWCLKCTL_ENXTAL;
+			chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
+
+			/* For dynamic control, we have to release our xtal_pu
+			 * "force on" */
+			if (tmp & SSB_CHIPCO_SLOWCLKCTL_ENXTAL)
+				ssb_pci_xtal(bus, SSB_GPIO_XTAL, 0);
+		} else {
+			chipco_write32(cc, SSB_CHIPCO_SYSCLKCTL,
+				(chipco_read32(cc, SSB_CHIPCO_SYSCLKCTL) &
+				 ~SSB_CHIPCO_SYSCLKCTL_FORCEHT));
+		}
 		break;
 	default:
 		SSB_WARN_ON(1);
-- 
1.7.3.4


^ permalink raw reply related	[flat|nested] 9+ messages in thread
* [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
@ 2011-04-27 15:40 ` Rafał Miłecki
  0 siblings, 0 replies; 9+ messages in thread
From: Rafał Miłecki @ 2011-04-27 15:40 UTC (permalink / raw)
  To: linux-wireless, John W. Linville, Michael Büsch
  Cc: b43-dev, Rafał Miłecki

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 drivers/ssb/driver_chipcommon.c |   60 ++++++++++++++++++++++++++++-----------
 1 files changed, 43 insertions(+), 17 deletions(-)

diff --git a/drivers/ssb/driver_chipcommon.c b/drivers/ssb/driver_chipcommon.c
index b4b3733..06d15b6 100644
--- a/drivers/ssb/driver_chipcommon.c
+++ b/drivers/ssb/driver_chipcommon.c
@@ -46,40 +46,66 @@ void ssb_chipco_set_clockmode(struct ssb_chipcommon *cc,
 	if (!ccdev)
 		return;
 	bus = ccdev->bus;
+
+	/* We support SLOW only on 6..9 */
+	if (ccdev->id.revision >= 10 && mode == SSB_CLKMODE_SLOW)
+		mode = SSB_CLKMODE_DYNAMIC;
+
+	if (cc->capabilities & SSB_CHIPCO_CAP_PMU)
+		return; /* PMU controls clockmode, separated function needed */
+	SSB_WARN_ON(ccdev->id.revision >= 20);
+
 	/* chipcommon cores prior to rev6 don't support dynamic clock control */
 	if (ccdev->id.revision < 6)
 		return;
-	/* chipcommon cores rev10 are a whole new ball game */
+
+	/* ChipCommon cores rev10+ need testing */
 	if (ccdev->id.revision >= 10)
 		return;
+
 	if (!(cc->capabilities & SSB_CHIPCO_CAP_PCTL))
 		return;
 
 	switch (mode) {
-	case SSB_CLKMODE_SLOW:
+	case SSB_CLKMODE_SLOW: /* For revs 6..9 only */
 		tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
 		tmp |= SSB_CHIPCO_SLOWCLKCTL_FSLOW;
 		chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
 		break;
 	case SSB_CLKMODE_FAST:
-		ssb_pci_xtal(bus, SSB_GPIO_XTAL, 1); /* Force crystal on */
-		tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
-		tmp &= ~SSB_CHIPCO_SLOWCLKCTL_FSLOW;
-		tmp |= SSB_CHIPCO_SLOWCLKCTL_IPLL;
-		chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
+		if (ccdev->id.revision < 10) {
+			ssb_pci_xtal(bus, SSB_GPIO_XTAL, 1); /* Force crystal on */
+			tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
+			tmp &= ~SSB_CHIPCO_SLOWCLKCTL_FSLOW;
+			tmp |= SSB_CHIPCO_SLOWCLKCTL_IPLL;
+			chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
+		} else {
+			chipco_write32(cc, SSB_CHIPCO_SYSCLKCTL,
+				(chipco_read32(cc, SSB_CHIPCO_SYSCLKCTL) |
+				 SSB_CHIPCO_SYSCLKCTL_FORCEHT));
+			/* udelay(150); TODO: not available in early init */
+		}
 		break;
 	case SSB_CLKMODE_DYNAMIC:
-		tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
-		tmp &= ~SSB_CHIPCO_SLOWCLKCTL_FSLOW;
-		tmp &= ~SSB_CHIPCO_SLOWCLKCTL_IPLL;
-		tmp &= ~SSB_CHIPCO_SLOWCLKCTL_ENXTAL;
-		if ((tmp & SSB_CHIPCO_SLOWCLKCTL_SRC) != SSB_CHIPCO_SLOWCLKCTL_SRC_XTAL)
-			tmp |= SSB_CHIPCO_SLOWCLKCTL_ENXTAL;
-		chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
-
-		/* for dynamic control, we have to release our xtal_pu "force on" */
-		if (tmp & SSB_CHIPCO_SLOWCLKCTL_ENXTAL)
-			ssb_pci_xtal(bus, SSB_GPIO_XTAL, 0);
+		if (ccdev->id.revision < 10) {
+			tmp = chipco_read32(cc, SSB_CHIPCO_SLOWCLKCTL);
+			tmp &= ~SSB_CHIPCO_SLOWCLKCTL_FSLOW;
+			tmp &= ~SSB_CHIPCO_SLOWCLKCTL_IPLL;
+			tmp &= ~SSB_CHIPCO_SLOWCLKCTL_ENXTAL;
+			if ((tmp & SSB_CHIPCO_SLOWCLKCTL_SRC) !=
+			    SSB_CHIPCO_SLOWCLKCTL_SRC_XTAL)
+				tmp |= SSB_CHIPCO_SLOWCLKCTL_ENXTAL;
+			chipco_write32(cc, SSB_CHIPCO_SLOWCLKCTL, tmp);
+
+			/* For dynamic control, we have to release our xtal_pu
+			 * "force on" */
+			if (tmp & SSB_CHIPCO_SLOWCLKCTL_ENXTAL)
+				ssb_pci_xtal(bus, SSB_GPIO_XTAL, 0);
+		} else {
+			chipco_write32(cc, SSB_CHIPCO_SYSCLKCTL,
+				(chipco_read32(cc, SSB_CHIPCO_SYSCLKCTL) &
+				 ~SSB_CHIPCO_SYSCLKCTL_FORCEHT));
+		}
 		break;
 	default:
 		SSB_WARN_ON(1);
-- 
1.7.3.4

^ permalink raw reply related	[flat|nested] 9+ messages in thread
* Re: [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
  2011-04-27 15:40 ` Rafał Miłecki
@ 2011-04-27 17:58   ` Larry Finger
  -1 siblings, 0 replies; 9+ messages in thread
From: Larry Finger @ 2011-04-27 17:58 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: linux-wireless, John W. Linville, Michael Büsch, b43-dev

On 04/27/2011 10:40 AM, Rafał Miłecki wrote:
> Signed-off-by: Rafał Miłecki<zajec5@gmail.com>
> ---
>   drivers/ssb/driver_chipcommon.c |   60 ++++++++++++++++++++++++++++-----------
>   1 files changed, 43 insertions(+), 17 deletions(-)
>

ACK.

Larry


^ permalink raw reply	[flat|nested] 9+ messages in thread
* [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
@ 2011-04-27 17:58   ` Larry Finger
  0 siblings, 0 replies; 9+ messages in thread
From: Larry Finger @ 2011-04-27 17:58 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: linux-wireless, John W. Linville, Michael Büsch, b43-dev

On 04/27/2011 10:40 AM, Rafa? Mi?ecki wrote:
> Signed-off-by: Rafa? Mi?ecki<zajec5@gmail.com>
> ---
>   drivers/ssb/driver_chipcommon.c |   60 ++++++++++++++++++++++++++++-----------
>   1 files changed, 43 insertions(+), 17 deletions(-)
>

ACK.

Larry

^ permalink raw reply	[flat|nested] 9+ messages in thread
* [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
  2011-04-27 15:40 ` Rafał Miłecki
  (?)
  (?)
@ 2011-04-27 20:41 ` Michael Büsch
  2011-04-27 20:52     ` Rafał Miłecki
  -1 siblings, 1 reply; 9+ messages in thread
From: Michael Büsch @ 2011-04-27 20:41 UTC (permalink / raw)
  To: b43-dev

> +??? ??? ??? /* udelay(150); TODO: not available in early init */

udelay() should be available at this point. Are you confusing it with msleep(), which is not available that early?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110427/e0e1d2fa/attachment.html>

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
  2011-04-27 20:41 ` Michael Büsch
@ 2011-04-27 20:52     ` Rafał Miłecki
  0 siblings, 0 replies; 9+ messages in thread
From: Rafał Miłecki @ 2011-04-27 20:52 UTC (permalink / raw)
  To: Michael Büsch
  Cc: linux-wireless, John W. Linville, Michael Büsch, b43-dev

2011/4/27 Michael Büsch <m@bues.ch>:
>> +            /* udelay(150); TODO: not available in early init */
>
> udelay() should be available at this point. Are you confusing it with
> msleep(), which is not available that early?

I had no idea about this difference, thanks.

However I still think about initializing ChipCommon later, to let it
*sleep* and no to delay boot process. Should this be fine? Or are
there some important reasons to init ChipCommon early?

-- 
Rafał

^ permalink raw reply	[flat|nested] 9+ messages in thread
* [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
@ 2011-04-27 20:52     ` Rafał Miłecki
  0 siblings, 0 replies; 9+ messages in thread
From: Rafał Miłecki @ 2011-04-27 20:52 UTC (permalink / raw)
  To: Michael Büsch
  Cc: linux-wireless, John W. Linville, Michael Büsch, b43-dev

2011/4/27 Michael B?sch <m@bues.ch>:
>> +??? ??? ??? /* udelay(150); TODO: not available in early init */
>
> udelay() should be available at this point. Are you confusing it with
> msleep(), which is not available that early?

I had no idea about this difference, thanks.

However I still think about initializing ChipCommon later, to let it
*sleep* and no to delay boot process. Should this be fine? Or are
there some important reasons to init ChipCommon early?

-- 
Rafa?

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
  2011-04-27 20:52     ` Rafał Miłecki
@ 2011-04-27 21:37       ` Michael Büsch
  -1 siblings, 0 replies; 9+ messages in thread
From: Michael Büsch @ 2011-04-27 21:37 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: linux-wireless, John W. Linville, Michael Büsch, b43-dev

On Wed, 2011-04-27 at 22:52 +0200, Rafał Miłecki wrote: 
> 2011/4/27 Michael Büsch <m@bues.ch>:
> >> +            /* udelay(150); TODO: not available in early init */
> >
> > udelay() should be available at this point. Are you confusing it with
> > msleep(), which is not available that early?
> 
> I had no idea about this difference, thanks.
> 
> However I still think about initializing ChipCommon later, to let it
> *sleep* and no to delay boot process. Should this be fine? Or are
> there some important reasons to init ChipCommon early?

I don't think it matters it all, if the boot process takes
150 microseconds longer or not. So I'd rather not change it for
no good reason.
This new 0.00015 seconds (150 us) delay in chipcommon seems perfectly
fine.

Even a few MMIO bus accesses will take longer than this tiny delay.
And there are thousands of MMIO accesses on bootup.
So it will hardly be measureable.

-- 
Greetings Michael.


^ permalink raw reply	[flat|nested] 9+ messages in thread
* [PATCH] ssb: cc: prepare clockmode support for cores rev 10+
@ 2011-04-27 21:37       ` Michael Büsch
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Büsch @ 2011-04-27 21:37 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: linux-wireless, John W. Linville, Michael Büsch, b43-dev

On Wed, 2011-04-27 at 22:52 +0200, Rafa? Mi?ecki wrote: 
> 2011/4/27 Michael B?sch <m@bues.ch>:
> >> +            /* udelay(150); TODO: not available in early init */
> >
> > udelay() should be available at this point. Are you confusing it with
> > msleep(), which is not available that early?
> 
> I had no idea about this difference, thanks.
> 
> However I still think about initializing ChipCommon later, to let it
> *sleep* and no to delay boot process. Should this be fine? Or are
> there some important reasons to init ChipCommon early?

I don't think it matters it all, if the boot process takes
150 microseconds longer or not. So I'd rather not change it for
no good reason.
This new 0.00015 seconds (150 us) delay in chipcommon seems perfectly
fine.

Even a few MMIO bus accesses will take longer than this tiny delay.
And there are thousands of MMIO accesses on bootup.
So it will hardly be measureable.

-- 
Greetings Michael.

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-04-27 21:37 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-27 15:40 [PATCH] ssb: cc: prepare clockmode support for cores rev 10+ Rafał Miłecki
2011-04-27 15:40 ` Rafał Miłecki
2011-04-27 17:58 ` Larry Finger
2011-04-27 17:58   ` Larry Finger
2011-04-27 20:41 ` Michael Büsch
2011-04-27 20:52   ` Rafał Miłecki
2011-04-27 20:52     ` Rafał Miłecki
2011-04-27 21:37     ` Michael Büsch
2011-04-27 21:37       ` Michael Büsch

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.