Header claims GPL v2, so make the MODULE_LICENSE reflect that properly.
Signed-off-by: Mike Looijmans
---
drivers/gpu/drm/i2c/adv7511.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index 2aaa3c8..73a4ee6 100644
Header claims GPL v2, so make the MODULE_LICENSE reflect that properly.
Signed-off-by: Mike Looijmans
---
drivers/media/i2c/adv7511.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 95bcd40..497ee00 100644
--- a
MTU=15000, PC-to-gadget: 239 Mbps, Gadget-to-PC: 361 Mbps
On boards with slower CPUs the performance improvement will be
relatively much larger, e.g. an OMAP-L138 increased from 40 to
220 Mbps using a similar patch on an 2.6.37 kernel.
Signed-off-by: Mike Looijmans
---
drivers/usb/gadget
On 27-07-15 12:28, Kalle Valo wrote:
Mike Looijmans writes:
Fixes commit eae79b4f3e82ca63a53478a161b190a0d38fe526 ("rsi: fix memory leak
in rsi_load_ta_instructions()") which stopped the driver from functioning.
You can abbreviate the commit id:
Fixes commit eae79b4f3e82 ("
fails.
Tested on a Topic Miami-Florida board which contains the rsi SDIO chip.
Also added the same kfree() call to the USB glue driver. This was not
tested on actual hardware though, as I only have the SDIO version.
Fixes: eae79b4f3e82 ("rsi: fix memory leak in rsi_load_ta_instructions()")
ted on a Topic Miami-Florida board which contains the rsi SDIO chip.
Also added the same kfree() call to the USB glue driver. This was not
tested on actual hardware though, as I only have the SDIO version.
Signed-off-by: Mike Looijmans
Cc: sta...@vger.kernel.org
---
drivers/net/wireless/rsi/rs
combination with additional devices on other controllers.
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
On 02-07-15 11:39, David Laight wrote:
From: Peter Chen
Sent: 30 June 2015 03:06
On Fri, Jun 26, 2015 at 03:47:03PM +0200, Mike Looijmans wrote:
The datasheet for the 334x PHY mentions that a reset can be performed:
"... by bringing the pin low for a minimum of 1 microsecond and
then hig
ested on mainline.
Signed-off-by: Mike Looijmans
---
drivers/power/ltc2941-battery-gauge.c | 54 ++-
1 file changed, 8 insertions(+), 46 deletions(-)
diff --git a/drivers/power/ltc2941-battery-gauge.c
b/drivers/power/ltc2941-battery-gauge.c
index daeb086..4a
er(driver/mtd/spi-nor)
> are not the same mtd layer,I found that it's hard to do.
> But for new structure spi controller(such as
> driver/mtd/spi-nor/fsl-quadspi.c) is very reasonable.and
> it can be easy to set spi controller and spi nor into quad mode at the same
> time
On 30-06-15 17:42, Graham Moore wrote:
On 06/30/2015 06:17 AM, Mike Looijmans wrote:
Micron QUAD mode expects command, address and data on 4 lanes instead of just
one for command (extended SPI mode). This requires the controller to be in a
special mode, so check first if the controller could
ommit sets QUAD mode for most Micron chips without asking the controller
whether it's possible to do so, and without telling the controller that a
different mode is required, so it couldn't work.
Signed-off-by: Mike Looijmans
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 in
ated while already
being supplied from the host PC.
Signed-off-by: Mike Looijmans
---
drivers/usb/chipidea/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index c865abe..4c6cf48 100644
--- a/drivers/usb/chipidea/core.c
+++ b/d
t the
chip will assert the DIR output. 1ms seems like a safe time to wait
for that to happen, so no change there.
Signed-off-by: Mike Looijmans
---
drivers/usb/chipidea/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/co
Ping!
Just curious, any further feedback or comment after Arnd Bergmann's ack?
It fixes a bug that took quite some time to discover and analyze, we should
save other people going through that same trouble.
On 07-05-15 14:54, Mike Looijmans wrote:
When dma-coherent transfers are en
Y3 derive from PLL1
Y4 and Y5 derive from PLL2
Given a target output frequency, the driver will set the PLL and
divider to best approximate the desired output.
Signed-off-by: Mike Looijmans
---
v2: Coding style check
Add devicetree binding documentation
v3: Remove clk-private.h and processed
On 02-06-15 09:50, Paul Bolle wrote:
On Mon, 2015-06-01 at 12:13 +0200, Mike Looijmans wrote:
--- /dev/null
+++ b/drivers/clk/clk-cdce925.c
+static int cdce925_regmap_i2c_write(
+ void *context, const void *data, size_t count)
+ dev_dbg(&i2c->dev, "%s(%u) %#x %#x\
On 02-06-15 09:50, Paul Bolle wrote:
On Mon, 2015-06-01 at 12:13 +0200, Mike Looijmans wrote:
--- /dev/null
+++ b/drivers/clk/clk-cdce925.c
+static int cdce925_regmap_i2c_write(
+ void *context, const void *data, size_t count)
+ dev_dbg(&i2c->dev, "%s(%u) %#x %#x\
Y3 derive from PLL1
Y4 and Y5 derive from PLL2
Given a target output frequency, the driver will set the PLL and
divider to best approximate the desired output.
Signed-off-by: Mike Looijmans
---
v2: Coding style check
Add devicetree binding documentation
v3: Remove clk-private.h and processed
On 28-05-15 23:48, Michael Turquette wrote:
Hi Mike,
Quoting Mike Looijmans (2014-12-03 23:26:15)
This driver supports the TI CDCE925 programmable clock synthesizer.
The chip contains two PLLs with spread-spectrum clocking support and
five output dividers. The driver only supports the
Hello,
I was wondering what happened to this patch? Should I resubmit?
Mike.
On 04-12-14 08:26, Mike Looijmans wrote:
This driver supports the TI CDCE925 programmable clock synthesizer.
The chip contains two PLLs with spread-spectrum clocking support and
five output dividers. The driver only
is just confusing. Replace the word "consistent" in the
descriptions into "coherent" to be clear about this. Most hardware
will offer "coherent" memory, so the logical choice here is to adapt
the description to match reality.
Signed-off-by: Mike Looijmans
---
Docume
patch, the mapped memory is cacheable and the
transfer speed is again 600MB/s (limited by the FPGA) when
the data is in the L2 cache, while data integrity is being
maintained.
The patch has no effect on non-coherent DMA.
Signed-off-by: Mike Looijmans
---
v2: Mistakenly sent the wrong patch which
Oops, "arch/arm/boot/dts/topic-dyplo.dtsi" should not have been in there. Will
send a v2 patch to correct that.
On 07-05-15 14:00, Mike Looijmans wrote:
When dma-coherent transfers are enabled, the mmap call must
not change the pg_prot flags in the vma struct.
Split the arm_dma_m
patch, the mapped memory is cacheable and the
transfer speed is again 600MB/s (limited by the FPGA) when
the data is in the L2 cache, while data integrity is being
maintained.
The patch has no effect on non-coherent DMA.
Signed-off-by: Mike Looijmans
---
arch/arm/boot/dts/topic-dyplo.dtsi | 1 +
a
patch, the mapped memory is cacheable and the
transfer speed is again 600MB/s (limited by the FPGA) when
the data is in the L2 cache, while data integrity is being
maintained.
The patch has no effect on non-coherent DMA.
Signed-off-by: Mike Looijmans
---
v2: Mistakenly sent the wrong patch which
On 12-01-15 04:04, Mike Turquette wrote:
On Thu, Jan 8, 2015 at 11:01 PM, Mike Looijmans wrote:
Just a ping to inform if you've had had time to look at this?
Its in the queue for review this week. A lot to catch up on after the
holidays. Thanks for the ping.
Just another ping, you ha
e spi_nor_ids, so
replace them with the correct names for these chips.
This repairs the disappearance of NOR flash on the Miami boards since 3.18.
Signed-off-by: Mike Looijmans
---
drivers/mtd/devices/m25p80.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/
The driver reported 30% less than actually measured. This turned out to
be caused by a simple typo in the formula to calculate the LSB quantity.
Signed-off-by: Mike Looijmans
---
drivers/power/ltc2941-battery-gauge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
On 22-01-15 03:24, Sebastian Reichel wrote:
Hi,
On Tue, Oct 28, 2014 at 08:05:12AM +0100, Mike Looijmans wrote:
Both the LTC2941 and LTC2943 measure battery capacity.
The LTC2943 is compatible with the LTC2941, it adds voltage and
temperature monitoring, and uses a slightly different
ether a timeout must also cause a reset.
Signed-off-by: Mike Looijmans
---
v4: Fix 'return' with a value, in function returning void
.../devicetree/bindings/watchdog/gpio-wdt.txt |5 +++
drivers/watchdog/gpio_wdt.c| 37 +++-
2 file
Just a ping to inform if you've had had time to look at this?
Mike.
On 12/04/2014 08:26 AM, Mike Looijmans wrote:
This driver supports the TI CDCE925 programmable clock synthesizer.
The chip contains two PLLs with spread-spectrum clocking support and
five output dividers. The driver
On 12/09/2014 07:48 PM, Mark Brown wrote:
On Tue, Dec 09, 2014 at 07:12:30PM +0100, Mike Looijmans wrote:
On 12/09/2014 05:14 PM, Mark Brown wrote:
If a regulator depends on another regulator that happens to be called
later, the kernel always prints a message like this:
reg-fixed-voltage
ed, the driver calls clk_round_rate
for two frequencies. If the results are equal, or if the call returns
an error, the driver assumes the clock is fixed.
Signed-off-by: Mike Looijmans
---
v3: Only enable clock once in hw_params which may be called multiple times.
sound/soc/ad
Is this v3 patch okay or are you waiting for additional changes?
Kind regards,
Mike.
On 11/21/2014 10:40 AM, Mike Looijmans wrote:
On some chips, like the TPS386000, the trigger cannot be disabled
and the CPU must keep toggling the line at all times. Add a switch
"always_running&quo
On 12/10/2014 10:34 AM, Lars-Peter Clausen wrote:
On 12/05/2014 01:37 PM, Mike Looijmans wrote:
If the master clock supports programmable rates, program it to generate
the desired frequency. Only apply constraints when the clock is fixed.
This allows proper clock generation for both 44100 and
eally are errors.
--
Mike Looijmans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
message to debug level.
This fixes a storm of error messages at boot when a board has a power
regulator on an I2C bus which powers GPIO controlled regulators for
example.
Signed-off-by: Mike Looijmans
---
drivers/regulator/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
If the regulator cannot be registered because its supplier is not
available yet, don't write an error. There is no need to alert the
user of probe deferrals.
This fixes a storm of error messages at boot when a GPIO controlled
regulator is supplied by an I2C controlled supply.
Signed-off-by:
Just a ping to ask for attention. Anyone care to review, comment or otherwise
provide some feedback?
On 12/04/2014 08:26 AM, Mike Looijmans wrote:
This driver supports the TI CDCE925 programmable clock synthesizer.
The chip contains two PLLs with spread-spectrum clocking support and
five
. If the results are equal, or if the call returns
an error, the driver assumes the clock is fixed.
Signed-off-by: Mike Looijmans
---
v2: Fix fixed clock detection as discussed.
sound/soc/adi/axi-spdif.c | 60 -
1 file changed, 38 insertions(+), 2
On 12/04/2014 01:45 PM, Lars-Peter Clausen wrote:
On 12/04/2014 07:52 AM, Mike Looijmans wrote:
If the master clock supports programmable rates, program it to generate
the desired frequency. Only apply constraints when the clock is fixed.
This allows proper clock generation for both 44100 and
Y3 derive from PLL1
Y4 and Y5 derive from PLL2
Given a target output frequency, the driver will set the PLL and
divider to best approximate the desired output.
Signed-off-by: Mike Looijmans
---
v2: Coding style check
Add devicetree binding documentation
.../devicetree/bindings/clock
first.
Starting the clock and enabling the SPDIF output AFTER programming the
dividers is a more logical order anyway.
Signed-off-by: Mike Looijmans
---
sound/soc/adi/axi-spdif.c | 56 -
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git
On 24-11-2014 14:15, Grygorii Strashko wrote:
Hi Uwe,
On 11/23/2014 07:04 PM, Uwe Kleine-König wrote:
On Thu, Nov 20, 2014 at 12:03:08PM +0200, Grygorii Strashko wrote:
@@ -664,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
if (!of_property_read_u32(pdev-
one other module uses it (xylon_connector.c).
Signed-off-by: Mike Looijmans
---
drivers/gpu/drm/drm_sysfs.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ab1a5f6..d0296cc 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drive
ether a timeout must also cause a reset.
Signed-off-by: Mike Looijmans
---
v3: Indentation adjusted to match
Fix error path in probe when notification registration fails
Prevent double assignment of "armed" variable
.../devicetree/bindings/watchdog/gpio-wdt.txt |5 ++
On 11/21/2014 08:28 AM, Guenter Roeck wrote:
On 11/20/2014 10:53 PM, Mike Looijmans wrote:
On some chips, like the TPS386000, the trigger cannot be disabled
and the CPU must keep toggling the line at all times. Add a switch
"always_running" to keep toggling the GPIO line regardl
ether a timeout must also cause a reset.
Signed-off-by: Mike Looijmans
---
v2: Rename property "always_running" to "always-running" and add devicetree
documentation
.../devicetree/bindings/watchdog/gpio-wdt.txt |5 +
drivers/watchdog/gpio_wdt.c
ether a timeout must also cause a reset.
Signed-off-by: Mike Looijmans
---
drivers/watchdog/gpio_wdt.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index 220a9e0..921ee67 100644
--- a/drivers
to test (you'd have to
trigger an I2C error at exactly the moment that a clock frequency change is
about to occur...).
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+
On 11/04/2014 08:47 PM, Mark Brown wrote:
On Tue, Nov 04, 2014 at 02:35:50PM +0100, Mike Looijmans wrote:
I still need help with one thing that isn't clear to me though. The DT is
parsed when calling regulator_register. But then how do I fetch my "private"
settings in t
On 11/04/2014 09:26 PM, Mark Brown wrote:
On Tue, Nov 04, 2014 at 07:50:45AM +0100, Mike Looijmans wrote:
v3: Add .of_match_table and prefix lltc
Clarify why regmap cannot be used
Add lltc,operating-mode (0..3) DT property
regulator child nodes are optional
Leave out the mode
On 11/04/2014 12:34 PM, Mark Brown wrote:
On Tue, Nov 04, 2014 at 09:55:14AM +0100, Mike Looijmans wrote:
On 11/03/2014 06:38 PM, Mike Looijmans wrote:
You need to develop against current versions of the kernel, this is
something that was merged into Linus' tree during the merge w
On 11/04/2014 12:34 PM, Mark Brown wrote:
On Tue, Nov 04, 2014 at 09:55:14AM +0100, Mike Looijmans wrote:
On 11/03/2014 06:38 PM, Mike Looijmans wrote:
You need to develop against current versions of the kernel, this is
something that was merged into Linus' tree during the merge w
On 11/03/2014 06:38 PM, Mike Looijmans wrote:
On 3-11-2014 16:10, Mark Brown wrote:
On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote:
On 11/03/2014 01:09 PM, Mark Brown wrote:
No function calls, just use regulators_node. What is unclear about the
functionality?
I don
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
Signed-off-by: Mike Looijmans
---
v3: Add .of_match_table and prefix lltc
Clarify why regmap cannot be used
Add lltc,operating-mode (0..3) DT property
regulator child nodes are optional
.../devicetree
On 3-11-2014 16:10, Mark Brown wrote:
On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote:
On 11/03/2014 01:09 PM, Mark Brown wrote:
No function calls, just use regulators_node. What is unclear about the
functionality?
I don't understand what you mean by "regul
On 11/03/2014 01:09 PM, Mark Brown wrote:
On Mon, Nov 03, 2014 at 09:10:08AM +0100, Mike Looijmans wrote:
On 10/30/2014 05:51 PM, Mark Brown wrote:
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if
On 10/30/2014 05:51 PM, Mark Brown wrote:
On Thu, Oct 30, 2014 at 12:26:55PM +0100, Mike Looijmans wrote:
+ np = of_node_get(i2c->dev.of_node);
+ np_regulators = of_get_child_by_name(np, "regulators");
+ np_child = of_get_child_by_name(
On 30-10-2014 17:51, Mark Brown wrote:
On Thu, Oct 30, 2014 at 12:26:55PM +0100, Mike Looijmans wrote:
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
v2: Prefix "lltc" to devicetree properties. Use the same property names
as the ltc3589 driver. Remo
On 10/30/2014 11:58 AM, Mark Brown wrote:
On Thu, Oct 30, 2014 at 11:53:37AM +0100, Mike Looijmans wrote:
On 10/30/2014 11:29 AM, Mike Looijmans wrote:
So I should add "regulator-default-voltage" to the generic code? That would
indeed be better than trying to do it into this driv
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
v2: Prefix "lltc" to devicetree properties. Use the same property names
as the ltc3589 driver. Remove default-voltage property. Use
devm_register_regulator.
Signed-off-by: Mike Looijmans
---
.../
On 10/30/2014 11:29 AM, Mike Looijmans wrote:
On 10/30/2014 11:15 AM, Mark Brown wrote:
On Thu, Oct 30, 2014 at 07:47:44AM +0100, Mike Looijmans wrote:
On 10/29/2014 01:30 PM, Mark Brown wrote:
A couple of problems here:
- This contains DT code but no DT bindings documentation; the
On 10/30/2014 11:15 AM, Mark Brown wrote:
On Thu, Oct 30, 2014 at 07:47:44AM +0100, Mike Looijmans wrote:
On 10/29/2014 01:30 PM, Mark Brown wrote:
A couple of problems here:
- This contains DT code but no DT bindings documentation; the binding
documentation is mandatory for any
On 10/29/2014 01:30 PM, Mark Brown wrote:
On Wed, Oct 29, 2014 at 09:16:00AM +0100, Mike Looijmans wrote:
+ if (!status->voltage_set) {
+ if (of_property_read_u32(dev->dev.of_node,
+ "ltc3562-default-voltage", &v_default) =
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
Signed-off-by: Mike Looijmans
---
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/ltc3562.c | 387 +++
3 files changed, 395
This patch adds the LTC3562 I2C controlled voltage regulator to
the kernel. The driver was tested and developed on a Topic Miami
board where this chip supplies the IO voltages for the FPGA pins.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
As discussed here, I'll post a new patch which simply removes the error
messages.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
sdhci_add_host and sdhci_platfm_init already report failure,
so don't emit error messages when a failure occurs. This prevents
occurences of "deferred" messages when required power supplies
are not ready for operation yet.
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/sd
On 10/27/2014 05:38 PM, Sebastian Reichel wrote:
Hi,
On Thu, Oct 23, 2014 at 02:38:38PM +0200, Mike Looijmans wrote:
Both the LTC2941 and LTC2943 measure battery capacity.
The LTC2943 is compatible with the LTC2941, it adds voltage and
temperature monitoring, and uses a slightly different
This adds the devicetree binding documentation for the LTC2941 and LTC2943
driver. These are I2C connected battery gas gauge ICs.
Signed-off-by: Mike Looijmans
---
.../devicetree/bindings/power/ltc2941.txt | 27
1 file changed, 27 insertions(+)
create mode
LTC294X.
v2: Fix units of measurement: uV, uA and centidegrees.
v3: Correctly set configuration register. Allow negative values
for the sense resistor.
v4: Run checkpatch.pl and fix all errors and warnings.
v5: Prefix "lltc," to devicetree properties.
Signed-off-by: Mike
Y3 derive from PLL1
Y4 and Y5 derive from PLL2
Given a target output frequency, the driver will set the PLL and
divider to best approximate the desired output.
Signed-off-by: Mike Looijmans
---
drivers/clk/Kconfig | 17 +
drivers/clk/Makefile |1 +
drivers/clk/clk-cdce925.c
This patch contains a driver for an I2C controlled clock synthesizer.
We've been using this driver for a while for creating clock signals
for HDMI and audio.
The only thing missing in this patch is the devicetree binding
information, I intend to add that in a later patch.
Please provid
LTC294X.
v2: Fix units of measurement: uV, uA and centidegrees.
v3: Correctly set configuration register. Allow negative values
for the sense resistor.
v4: Run checkpatch.pl and fix all errors and warnings.
Signed-off-by: Mike Looijmans
---
drivers/power/Kconfig |8
When the error code is -EPROBE_DEFER, this will already be reported
so don't emit an error message in that case.
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/sdhci-of-arasan.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-ara
"ret" is a signed int, so use "%d" in format strings instead of "%u".
This prevents cryptic codes in error messages like this:
sdhci-arasan e0101000.sdhci: platform register failed (4294966779)
Signed-off-by: Mike Looijmans
Reviewed-by: Michal Simek
---
driv
LTC294X.
v2: Fix units of measurement: uV, uA and centidegrees.
v3: Correctly set configuration register. Allow negative values
for the sense resistor.
Signed-off-by: Mike Looijmans
---
drivers/power/Kconfig |7 +
drivers/power/Makefile|1 +
drivers
LTC294X.
v2: Fix units of measurement: uV, uA and centidegrees.
Signed-off-by: Mike Looijmans
---
drivers/power/Kconfig |7 +
drivers/power/Makefile|1 +
drivers/power/ltc2941-battery-gauge.c | 497 +
3 files changed, 505
client/driver for the Linear Technology LTC2941 and LTC2943
+ * Battery Gas Gauge IC
+ *
+ * Copyright (C) 2014 Topic Embedded Systems
+ *
+ * Author: Auryn Verwegen
+ * Author: Mike Looijmans
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#i
I based this patch on the 3.17rc5 state. Hope this applies cleanly now?
On 09/15/2014 12:06 PM, Mike Looijmans wrote:
The KSZ9031 appears to suffer from the same hardware bug as described
for the KSZ9021 in commit 32fcafbcd1c9f6c7013016a22a5369b4acb93577
("net/phy: micrel: Disable asymm
Pause flag for the KSZ9031 to fix this.
Signed-off-by: Mike Looijmans
---
drivers/net/phy/micrel.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index fd0ea7c..011dbda 100644
--- a/drivers/net/phy/micrel.c
+++ b/drive
On 09/13/2014 12:18 AM, David Miller wrote:
From: Mike Looijmans
Date: Fri, 12 Sep 2014 14:40:37 +0200
The KSZ9031 appears to suffer from the same hardware bug as described
for the KSZ9021 in commit 32fcafbcd1c9f6c7013016a22a5369b4acb93577
("net/phy: micrel: Disable asymmetric paus
Pause flag for the KSZ9031 to fix this.
Signed-off-by: Mike Looijmans
---
drivers/net/phy/micrel.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 5a8993b..a932a35 100644
--- a/drivers/net/phy/micrel.c
+++ b/drive
On 09/11/2014 08:41 PM, Florian Fainelli wrote:
On 09/11/2014 06:45 AM, Mike Looijmans wrote:
Our KSZ9031 appears to suffer from the same hardware bug as described
for the KSZ9021 in commit 32fcafbcd1c9f6c7013016a22a5369b4acb93577,
you have to unplug the cable and plug it back to get it to work
Our KSZ9031 appears to suffer from the same hardware bug as described
for the KSZ9021 in commit 32fcafbcd1c9f6c7013016a22a5369b4acb93577,
you have to unplug the cable and plug it back to get it to work.
Remove the SUPPORTED_Asym_Pause flag for the KSZ9031 to fix this.
Signed-off-by: Mike
ce or reliability.
Tested on a custom board with an OMAP-L138 CPU. Patch originally applied
to a 2.6.37 kernel and ported to 3.14.
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/davinci_mmc.c | 52 +---
1 file changed, 33 insertions(+), 19 deletions(-)
Note: I have not been able to test or even compile this on recent
kernels. Can somebody verify that this does not kill the SD driver?
Mike.
On 08/29/2014 08:41 AM, Mike Looijmans wrote:
The davinci-mmc driver uses a busy wait loop to wait for the card to
become ready (BUSY signal). The MMC
s correct. All your remarks were. Problem currently is
that I'm not assigned to a project related to the davinci so I cannot
spend time to fix and port it (the actual platform still runs 2.6.37).
Feel free to adap my patch or comments and commit. Or wait a few weeks
for when I have a sp
On 04/07/2014 02:51 PM, Arnd Bergmann wrote:
On Monday 07 April 2014 14:32:20 Mike Looijmans wrote:
On 04/07/2014 02:25 PM, Arnd Bergmann wrote:
Judging from the kernel output, regulator_get_optional returns -ENODEV if the
supply wasn't found.
Maybe the API is confusing (or wrong?) here
On 04/07/2014 02:25 PM, Arnd Bergmann wrote:
On Monday 07 April 2014 13:18:54 Ben Dooks wrote:
On 07/04/14 13:16, Ben Dooks wrote:
On 07/04/14 13:09, Mike Looijmans wrote:
On 04/07/2014 10:11 AM, Arnd Bergmann wrote:
On Monday 07 April 2014 08:38:28 Mike Looijmans wrote:
index 34aef81
and which is not our case - at least
for majority of our customers.
I write them by hand. Is there any other way?
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
On 04/07/2014 10:11 AM, Arnd Bergmann wrote:
On Monday 07 April 2014 08:38:28 Mike Looijmans wrote:
index 34aef81..43b90c1 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2972,6 +2972,8 @@ int sdhci_add_host(struct sdhci_host *host)
host->vq
that has an I2C regulator for one of the sdhcis
and no regulators at all for the other. This patch enables such a system
to work correctly.
v2: Do not change logging output
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/sdhci.c |4
1 file changed, 4 insertions(+)
diff --git a
that has an I2C regulator for one of the sdhcis
and no regulators at all for the other. This patch enables such a system
to work correctly.
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/sdhci.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never wanted to use a regulator anyway and continues without ever
enabling or configuring the re
On 26-3-2014 16:09, Georgi Djakov wrote:
On 03/07/2014 04:18 PM, Mike Looijmans wrote:
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never
pin 0 for a status LED.
# devmem 0XF8000830
0x002E
Register 0XF8000830 is SD0_WP_CD_SEL, and 0x002E sets CD to pin 46 and
WP to pin "0", not to EMIO as I specified in the design.
"
Eli: Maybe you have the same issue as Mike. Can you please check it?
Met vriendelijke g
dling from that
driver as well.
Cool, thanks!
Are you going to update the davinci patch as well?
An amended patch is on its way now. I forgot to set the subject to "PATCHv2"
though.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovensewe
201 - 300 of 317 matches
Mail list logo