headers
Dan Williams | 3 Feb 2009 16:47
Picon
Favicon

Re: [PATCH] libertas: add abilty to set DMA buffers alignmnet for SPI interface in compile time

On Tue, 2009-02-03 at 09:04 +0200, Mike Rapoport wrote:
> Different SPI controllers pose different alignment requirements on DMAable
> buffers. It's possible to alter the SPI controller driver to use it's own
> properly aligned buffers for DMA and copy the data it gets from the client
> into these buffers. However, this approach also impacts overall performance.
> Adding ability to set DMA buffers alignment for SPI interface in compile
> time prevents unnecessary memcpy calls.

I'd still rather that alignment constraints were handled in the
*controller* code, where the constraint actually is.  If this path is
followed, then every SPI-connected device for a platform would have to
have specific hacks for every platform, which is quite unmaintainable.
Is there a good way to fit the alignment constraints into the SPI
controller code?

Dan

> Signed-off-by: Mike Rapoport <mike@...>
> ---
>  drivers/net/wireless/Kconfig           |   10 ++++++++++
>  drivers/net/wireless/libertas/if_spi.c |   27 ++++++++++++++++-----------
>  2 files changed, 26 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
> index fe819a7..3bbb7b2 100644
> --- a/drivers/net/wireless/Kconfig
> +++ b/drivers/net/wireless/Kconfig
>  <at>  <at>  -157,6 +157,16  <at>  <at>  config LIBERTAS_SPI
>  	---help---
>  	  A driver for Marvell Libertas 8686 SPI devices.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dan Williams | 3 Feb 2009 16:51
Picon
Favicon

Re: [PATCH] libertas: if_spi: add ability to call board specific setup/teardown methods

On Tue, 2009-02-03 at 09:04 +0200, Mike Rapoport wrote:
> In certain cases it is required to perform board specific actions
> before activating libertas G-SPI interface. These actions may include
> power up of the chip, GPIOs setup, proper pin-strapping and SPI
> controller config.
> This patch adds ability to call board specific setup/teardown methods
> 
> 
> Signed-off-by: Mike Rapoport <mike@...>

Andrey, does this look OK to you?  Seems fine to me, though what's the
lifetime of the platform data 'pdata' in the probe function?  Is that
guaranteed to be valid for the entire lifetime of the libertas SPI
device?

Dan

> ---
>  drivers/net/wireless/libertas/if_spi.c |   15 +++++++++++++++
>  include/linux/spi/libertas_spi.h       |    7 +++++++
>  2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
> index 7c02ea3..07311e7 100644
> --- a/drivers/net/wireless/libertas/if_spi.c
> +++ b/drivers/net/wireless/libertas/if_spi.c
>  <at>  <at>  -42,6 +42,7  <at>  <at>  struct if_spi_packet {
>  struct if_spi_card {
>  	struct spi_device		*spi;
>  	struct lbs_private		*priv;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roel Kluin | 3 Feb 2009 17:15
Picon
Gravatar

[PATCH] wireless: pos[4] tested twice, 2nd should be pos[5]

Is this what it should be? please review.
----------------->8----------------------8<------------------

pos[4] can't be both 0x43 and 0x04, 2nd should be pos[5]

Signed-off-by: Roel Kluin <roel.kluin@...>
---
diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
index 57f6c12..00a57ed 100644
--- a/drivers/net/wireless/libertas/scan.c
+++ b/drivers/net/wireless/libertas/scan.c
 <at>  <at>  -692,7 +692,7  <at>  <at>  static int lbs_process_bss(struct bss_descriptor *bss,
 					    bss->wpa_ie_len);
 			} else if (pos[1] >= MARVELL_MESH_IE_LENGTH &&
 				   pos[2] == 0x00 && pos[3] == 0x50 &&
-				   pos[4] == 0x43 && pos[4] == 0x04) {
+				   pos[4] == 0x43 && pos[5] == 0x04) {
 				lbs_deb_scan("got mesh IE\n");
 				bss->mesh = 1;
 			} else {
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Nick Kossifidis | 3 Feb 2009 17:17
Picon

Re: [ath5k-devel] [PATCH 1/5] ath5k: PHY code cleanup

2009/2/3 Maxim Levitsky <maximlevitsky@...>:
> I just tried your 5 patches, as they could fix hangs in the device,
> that I experience occasionally, when resuming my aspire one from ram.
>
> I applied the patches, and I got very unstable system, that tended to
> hang even before X.
>
> When it didn't hang, I tried suspend to ram cycle, but it hanged then.
>
>
> Best regards,
>        Maxim Levitsky
>
>

It's related to unhandled BMISS interrupts, Bob is working on it to
see what triggers them. A quick solution is to disable them (as we
don't handle them anyway) but it would be better to know the problem.

--

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 8 comments |
headers
Andrey Yurovsky | 3 Feb 2009 17:17

Re: [PATCH] libertas: add abilty to set DMA buffers alignmnet for SPI interface in compile time

On Tue, Feb 3, 2009 at 7:47 AM, Dan Williams <dcbw@...> wrote:
> On Tue, 2009-02-03 at 09:04 +0200, Mike Rapoport wrote:
>> Different SPI controllers pose different alignment requirements on DMAable
>> buffers. It's possible to alter the SPI controller driver to use it's own
>> properly aligned buffers for DMA and copy the data it gets from the client
>> into these buffers. However, this approach also impacts overall performance.
>> Adding ability to set DMA buffers alignment for SPI interface in compile
>> time prevents unnecessary memcpy calls.
>
> I'd still rather that alignment constraints were handled in the
> *controller* code, where the constraint actually is.  If this path is
> followed, then every SPI-connected device for a platform would have to
> have specific hacks for every platform, which is quite unmaintainable.
> Is there a good way to fit the alignment constraints into the SPI
> controller code?
>
> Dan

"struct spi_device" currently stores things like the IRQ number (ie:
"spi->irq"), how about we add an optional field to struct spi_device,
something like "dma_alignment" that drivers can use as a hint?  On PXA
it would be set to 8, on Blackfin it can be left at 0 or set to 4 or
something.

In our case we have:
- a device that needs ALIGN(4) or a multiple of 4 to work
- a controller that wants ALIGN(8)

So our if_spi_probe would then use the spi->dma_alignment field to
choose a sane value to use with ALIGN.  This would work for run-time
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bob Copeland | 3 Feb 2009 17:24
Favicon

Re: [PATCH 5/5] ath5k: Update reset code

On Sat, 31 Jan 2009 04:31:47 +0200, Nick Kossifidis wrote
>  int ath5k_hw_reset(struct ath5k_hw *ah, enum nl80211_iftype op_mode,
>  	struct ieee80211_channel *channel, bool change_channel)

Here's another thing I just noticed:

>  {
> +	u32 s_seq[10], s_ant, s_led[3], staid1_flags, tsf_up, tsf_lo;

s_seq is now an array (we used to initialize s_seq to 0)

[...]
> +		if (change_channel) {
> +			/*
> +			 * Save frame sequence count
> +			 * For revs. after Oahu, only save
> +			 * seq num for DCU 0 (Global seq num)
> +			 */
> +			if (ah->ah_mac_srev < AR5K_SREV_AR5211) {
> +
> +				for (i = 0; i < 10; i++)
> +					s_seq[i] = ath5k_hw_reg_read(ah,
> +						AR5K_QUEUE_DCU_SEQNUM(i));
> +
> +			} else {
> +				s_seq[0] = ath5k_hw_reg_read(ah,
> +						AR5K_QUEUE_DCU_SEQNUM(0));
> +			}

We only save the DCU sequence values if changing a channel
(Continue reading)

Permalink | Reply | 8 comments |
headers
Nick Kossifidis | 3 Feb 2009 17:24
Picon

Re: [ath5k-devel] [PATCH 1/5] ath5k: PHY code cleanup

2009/2/3 Nick Kossifidis <mickflemm@...>:
> 2009/2/3 Maxim Levitsky <maximlevitsky@...>:
>> I just tried your 5 patches, as they could fix hangs in the device,
>> that I experience occasionally, when resuming my aspire one from ram.
>>
>> I applied the patches, and I got very unstable system, that tended to
>> hang even before X.
>>
>> When it didn't hang, I tried suspend to ram cycle, but it hanged then.
>>
>>
>> Best regards,
>>        Maxim Levitsky
>>
>>
>
> It's related to unhandled BMISS interrupts, Bob is working on it to
> see what triggers them. A quick solution is to disable them (as we
> don't handle them anyway) but it would be better to know the problem.
>

Hmm if i recall correctly you have a AR2425 right ? I tested this code
on AR2425 before i submit the patches and it worked fine, can you give
me some more infos so i can reproduce this ? What's your setup ?

--

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
(Continue reading)

Permalink | Reply | 6 comments |
headers
Nick Kossifidis | 3 Feb 2009 17:28
Picon

Re: [ath5k-devel] [PATCH 5/5] ath5k: Update reset code

2009/2/3 Bob Copeland <me@...>:
> On Sat, 31 Jan 2009 04:31:47 +0200, Nick Kossifidis wrote
>>  int ath5k_hw_reset(struct ath5k_hw *ah, enum nl80211_iftype op_mode,
>>       struct ieee80211_channel *channel, bool change_channel)
>
> Here's another thing I just noticed:
>
>>  {
>> +     u32 s_seq[10], s_ant, s_led[3], staid1_flags, tsf_up, tsf_lo;
>
> s_seq is now an array (we used to initialize s_seq to 0)
>
> [...]
>> +             if (change_channel) {
>> +                     /*
>> +                      * Save frame sequence count
>> +                      * For revs. after Oahu, only save
>> +                      * seq num for DCU 0 (Global seq num)
>> +                      */
>> +                     if (ah->ah_mac_srev < AR5K_SREV_AR5211) {
>> +
>> +                             for (i = 0; i < 10; i++)
>> +                                     s_seq[i] = ath5k_hw_reg_read(ah,
>> +                                             AR5K_QUEUE_DCU_SEQNUM(i));
>> +
>> +                     } else {
>> +                             s_seq[0] = ath5k_hw_reg_read(ah,
>> +                                             AR5K_QUEUE_DCU_SEQNUM(0));
>> +                     }
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Dan Williams | 3 Feb 2009 17:37
Picon
Favicon

Re: [PATCH] libertas: add abilty to set DMA buffers alignmnet for SPI interface in compile time

On Tue, 2009-02-03 at 08:17 -0800, Andrey Yurovsky wrote:
> On Tue, Feb 3, 2009 at 7:47 AM, Dan Williams <dcbw@...> wrote:
> > On Tue, 2009-02-03 at 09:04 +0200, Mike Rapoport wrote:
> >> Different SPI controllers pose different alignment requirements on DMAable
> >> buffers. It's possible to alter the SPI controller driver to use it's own
> >> properly aligned buffers for DMA and copy the data it gets from the client
> >> into these buffers. However, this approach also impacts overall performance.
> >> Adding ability to set DMA buffers alignment for SPI interface in compile
> >> time prevents unnecessary memcpy calls.
> >
> > I'd still rather that alignment constraints were handled in the
> > *controller* code, where the constraint actually is.  If this path is
> > followed, then every SPI-connected device for a platform would have to
> > have specific hacks for every platform, which is quite unmaintainable.
> > Is there a good way to fit the alignment constraints into the SPI
> > controller code?
> >
> > Dan
> 
> "struct spi_device" currently stores things like the IRQ number (ie:
> "spi->irq"), how about we add an optional field to struct spi_device,
> something like "dma_alignment" that drivers can use as a hint?  On PXA
> it would be set to 8, on Blackfin it can be left at 0 or set to 4 or
> something.
> 
> In our case we have:
> - a device that needs ALIGN(4) or a multiple of 4 to work
> - a controller that wants ALIGN(8)
> 
> So our if_spi_probe would then use the spi->dma_alignment field to
(Continue reading)

Permalink | Reply | 1 comment |
headers
P.G. Richardson | 3 Feb 2009 17:39
Picon

Re: rtl8187 wireless issues


> On Mon, Feb 02, 2009 at 11:48:55PM +0000, Hin-Tak Leung wrote:
>
>> About dates in wireless-testing log - I had an impression (I could be
>> wrong) that the dates are sometimes git-format-patch/posting dates and
>> not dates at which John commits to wireless-testing? (i.e. the dates
>> shown could be a lot earlier than time of commit, or time of commit is
>> not shown by the dates associated with a patch - I thought this makes
>> sense since the date of a patch should be the first time it appears in
>> the "system", not the first time it gets in-coporated in a particular
>> tree, and patches can go between trees and should *not* pick up date
>> change on the way).
>
> Patch dates in 'git log' are based on their reported creation time or
> (for patches not from git) their posting time.  That's just the way
> git works (at least by default).
>
> I generally tag wireless-testing updates on the master branch with
> a date-based tag.  You can see them like this:
>
> 	git fetch --tags # just in case...
> 	git tag | grep master
>
> Hth!

Apologies. there might be some confusion. When I mentioned the date of the
30/01/2009, I was referring to the snapshot date of the tarball
downloaded, ie. compat-wireless-$(date -I).tar.bz2.

I haven't used wireless-testing's git repo thus far. If it will help with
(Continue reading)

Permalink | Reply | 2 comments |

Gmane