Re: [PATCH v2 8/8] p54: convert to sysdata API
On Wed, Aug 10, 2016 at 09:04:38PM +0200, Arend Van Spriel wrote: > So why would drivers want the devm solution anyway. Once firmware is > loaded in the device it can be freed or do you expect device drivers to > keep the firmware/sysdata for suspend/resume scenario as some do because > of firmware cache behaviour. Does the "rootfs ready" event cover > suspend/resume? There are classes of devices that spend a large proportion of their time powered off and are only powered up and have firmware loaded when they are actively in use. DSPs used in audio systems are one example of this, I'd not be surprised to learn that similar things are done with video. It's too expensive to keep the device powered up and you may be swapping between firmwares depending on use case anyway for a lot of these devices. signature.asc Description: PGP signature
Re: [PATCHv2] wlcore: spi: add wl18xx support
On Thu, Apr 21, 2016 at 11:07:37AM +, Reizer, Eyal wrote: > * (i) If the transfer isn't the last one in the message, this flag is > * used to make the chipselect briefly go inactive in the middle of the > * message. Toggling chipselect in this way may be needed to terminate > * a chip command, letting a single spi_message perform all of group of > * chip transactions together. > Now, in my case I need the CS pin to go inactive and stay inactive during the > transfer > of the next byte for completing the SPI init correctly (sending the extra > clock cycles while CS is inactive) > If I read the above correctly, CS will only briefly go inactive but will when > the next byte > is sent it will be active again. > What am I missing? No, it changes the state. The main use case is a brief bounce but you can use it for other things. signature.asc Description: PGP signature
Re: [PATCHv2] wlcore: spi: add wl18xx support
On Tue, Apr 19, 2016 at 06:04:49PM +, Reizer, Eyal wrote: > Thanks! Glad the illustration helped. > I will try it out again as if i recall cotrectly, i did try that l, and it > didnt produce the correct waveform, but perhaps i didnt understand the usage > of .cs_change correctly. > Will double check anyway. It could also be a bug in your controller driver, it's common for them to not handle cs_change correctly (at least those that open code the message loop, obviously modern ones just factor this out into the core). signature.asc Description: PGP signature
Re: [PATCHv2] wlcore: spi: add wl18xx support
On Tue, Apr 19, 2016 at 05:38:02PM +, Reizer, Eyal wrote: > Hi Mark, > > Hope you can see the attached picture that illustrates what need to sent for > sucesfull SPI init. I think what the picture shows is that you just need to send at least one byte at the end of the transfer *after* deasserting /CS which is totally not what I'd have understood from any of the previous discussion. That is already supported, just send an extra byte using .cs_change to do what is says. signature.asc Description: PGP signature
Re: [PATCHv2] wlcore: spi: add wl18xx support
On Tue, Apr 19, 2016 at 05:21:01PM +, Reizer, Eyal wrote: > The main quirk here is that i need to send extra clocks after the spi init > command while the CS pin is "high" in order to put the wilink chip into SPI > mode. > So just sending an empty transfer wouldnt do the trick here. A single byte transfer would result in extra clocks being sent so there must be more to it than that... > Do you have a recomendation on how to do it without changing the core logic. > If it is possible it would be really great. Please be explicit about what you're trying to do here. I imagine you may need to change the core logic but we need to know what it is that the device needs. signature.asc Description: PGP signature
Re: [PATCHv2] wlcore: spi: add wl18xx support
On Tue, Apr 19, 2016 at 09:05:45AM +, Reizer, Eyal wrote: > Understood. As this special CS manipulation is unique to wspi (wilink spi) I > think the > best option is to move this gpio allocation into wlcore_spi as a new device > tree entry > used only by this driver. That sounds like it is going to break normal chip select operation which doesn't seem like a good idea either. What exactly are you trying to do here? If you need to send some extra bytes at the end of a transfer why not just do that, or add an empty transfer with a delay. It's hard to see what more you could do with only control of the chip select... signature.asc Description: PGP signature
Re: [PATCHv2] wlcore: spi: add wl18xx support
On Mon, Apr 18, 2016 at 05:55:51AM +, Reizer, Eyal wrote: > > I would suggest fixing this using a new API function from the SPI core, if > > we > > don't already have a generic way to do it. > Originally this is what I have done until I was pointed to the generic > cs-gpio mechanism > in the SPI core. > It is a generic mechanism already in the SPI core driver. > See: Documentation/devicetree/bindings/spi/spi-bus.txt > It is also part of the generic spi.h (include/Linux/spi/spi.h), already part > of > " struct spi_device" So it seemed redundant adding another mechanism for > implementing the same. No! This is a *terrible* and broken idea. Client drivers should *not* be peering inside controller implementations like this, and they should especially not be trying to change the chip select without the core knowing about it. This is at best going to be fragile, at worst it will actively break some systems. Whatever you are trying to do needs to go through the SPI core with some degree of abstraction, the core needs to know what's going on and the driver needs to support systems that don't or can't mux the chip select out as a GPIO. signature.asc Description: PGP signature
Re: next-20151126 build: 3 failures 15 warnings (next-20151126)
On Thu, Nov 26, 2015 at 08:34:20PM +0200, Kalle Valo wrote: > Mark Brown <broo...@kernel.org> writes: > > It still ought to be fixed regardless of why it showed up - the > > intention of the code is that we build the real thermal code regardless > > of if that's modular or not but that's not what the code actually does. > Like I said above Michal will apply a fix to his tree. Read the full > discussion from patchwork: > https://patchwork.kernel.org/patch/7707801/ Oh, right - a fix for this specific issue rather than a fix for whatever change he made. signature.asc Description: PGP signature
[PATCH] ath10k: Fix check for !THERMAL case
When defining stubs for !THERMAL cases we currently check if CONFIG_THERMAL
is defined but this fails when the thermal code is built as a module in
which case CONFIG_THERMAL_MODULE is defined instead causing us to define
the stubs as well as building the actual ath10k thermal code which in turn
causes the build to fail on arm64 allmodconfig. Fix this by changing the
check in the header to use IS_ENABLED().
Signed-off-by: Mark Brown <broo...@kernel.org>
---
drivers/net/wireless/ath/ath10k/thermal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/thermal.h
b/drivers/net/wireless/ath/ath10k/thermal.h
index b610ea5caae8..793eec160e65 100644
--- a/drivers/net/wireless/ath/ath10k/thermal.h
+++ b/drivers/net/wireless/ath/ath10k/thermal.h
@@ -36,7 +36,7 @@ struct ath10k_thermal {
int temperature;
};
-#ifdef CONFIG_THERMAL
+#if IS_ENABLED(CONFIG_THERMAL)
int ath10k_thermal_register(struct ath10k *ar);
void ath10k_thermal_unregister(struct ath10k *ar);
void ath10k_thermal_event_temperature(struct ath10k *ar, int temperature);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: next-20151126 build: 3 failures 15 warnings (next-20151126)
On Thu, Nov 26, 2015 at 09:06:25AM +, Build bot for Mark Brown wrote: Today's -next fails to build an arm64 allmodconfig due to: > arm64-allmodconfig > ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of > 'ath10k_thermal_event_temperature' > ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of > 'ath10k_thermal_set_throttling' > ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of > 'ath10k_thermal_register' > ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of > 'ath10k_thermal_unregister' This is happening because there are stub functions provided in the driver's thermal.h for !THERMAL cases but these are guarded by an #ifdef not an #if and so fails to do the right thing if the thermal code is built as a module. It looks like this was somehow triggered as part of the reorganisation of the WiFi directory structure. signature.asc Description: PGP signature
Re: next-20151126 build: 3 failures 15 warnings (next-20151126)
On Thu, Nov 26, 2015 at 02:39:40PM +0200, Kalle Valo wrote: > Mark Brown <broo...@kernel.org> writes: > > It looks like this was somehow triggered as part of the reorganisation > > of the WiFi directory structure. > This is surprising and also worrying, any ideas why? It would be good to > understand the root cause in case there's a bug in wireless drivers > directory reorganisation. No, I didn't make much effort to check though since the use of ifdef was clearly a bug waiting to happen anyway, I was more surprised it worked at all than anything. signature.asc Description: PGP signature
Re: next-20151126 build: 3 failures 15 warnings (next-20151126)
On Thu, Nov 26, 2015 at 06:58:32PM +0200, Kalle Valo wrote:
> Mark Brown <broo...@kernel.org> writes:
> > No, I didn't make much effort to check though since the use of ifdef was
> > clearly a bug waiting to happen anyway, I was more surprised it worked
> > at all than anything.
> Michal Marek explains[1] that this is due to commit cf4f21938e13
> ("kbuild: Allow to specify composite modules with modname-m") and has
> nothing to do with the wireless drivers reorganisation. I'll drop this
> patch as Michal will apply his fix to the kbuild tree.
It still ought to be fixed regardless of why it showed up - the
intention of the code is that we build the real thermal code regardless
of if that's modular or not but that's not what the code actually does.
signature.asc
Description: PGP signature
