inear.com/docs/26553
LTC2633: http://www.linear.com/docs/39529
LTC2635: http://www.linear.com/docs/28754
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Add separate definitions for 8, 10 and 12-bit versions
drivers/iio/dac/Kconfig | 3 +-
dri
inear.com/docs/26553
LTC2633: http://www.linear.com/docs/39529
LTC2635: http://www.linear.com/docs/28754
Signed-off-by: Mike Looijmans
---
v2: Add separate definitions for 8, 10 and 12-bit versions
drivers/iio/dac/Kconfig | 3 +-
drivers/iio/dac/ad5064.c | 71 +++
The LTC3651 reports its status via GPIO lines. This driver translates
the GPIO levels to battery charger status information via sysfs.
It relies on devicetree to supply the IO configuration.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Remove unused include
Remove las
The LTC3651 reports its status via GPIO lines. This driver translates
the GPIO levels to battery charger status information via sysfs.
It relies on devicetree to supply the IO configuration.
Signed-off-by: Mike Looijmans
---
v2: Remove unused include
Remove last part of license text
Use
This adds the devicetree bindings documentation for the LTC3651 battery charger.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
.../bindings/power/supply/ltc3651-charger.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644
Documen
This adds the devicetree bindings documentation for the LTC3651 battery charger.
Signed-off-by: Mike Looijmans
---
.../bindings/power/supply/ltc3651-charger.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/supply
On 04-05-17 17:36, Sebastian Reichel wrote:
Hi,
On Tue, May 02, 2017 at 03:48:33PM +0200, Mike Looijmans wrote:
The LTC3651 reports its status via GPIO lines. This driver translates
the GPIO levels to battery charger status information via sysfs.
It relies on devicetree to supply the IO
On 04-05-17 17:36, Sebastian Reichel wrote:
Hi,
On Tue, May 02, 2017 at 03:48:33PM +0200, Mike Looijmans wrote:
The LTC3651 reports its status via GPIO lines. This driver translates
the GPIO levels to battery charger status information via sysfs.
It relies on devicetree to supply the IO
The LTC3651 reports its status via GPIO lines. This driver translates
the GPIO levels to battery charger status information via sysfs.
It relies on devicetree to supply the IO configuration.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
I'll send the devicetree binding documen
The LTC3651 reports its status via GPIO lines. This driver translates
the GPIO levels to battery charger status information via sysfs.
It relies on devicetree to supply the IO configuration.
Signed-off-by: Mike Looijmans
---
I'll send the devicetree binding documentation in a separate patch
On 27-04-17 11:16, Lars-Peter Clausen wrote:
On 04/27/2017 07:52 AM, Jonathan Cameron wrote:
On 26/04/17 10:44, Mike Looijmans wrote:
The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar
to the AD5064 device, in particular the LTC2627.
This patch adds support for those devices
On 27-04-17 11:16, Lars-Peter Clausen wrote:
On 04/27/2017 07:52 AM, Jonathan Cameron wrote:
On 26/04/17 10:44, Mike Looijmans wrote:
The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar
to the AD5064 device, in particular the LTC2627.
This patch adds support for those devices
inear.com/docs/26553
LTC2633: http://www.linear.com/docs/39529
LTC2635: http://www.linear.com/docs/28754
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/iio/dac/Kconfig | 3 ++-
drivers/iio/dac/ad5064.c | 58 ++--
2 fi
inear.com/docs/26553
LTC2633: http://www.linear.com/docs/39529
LTC2635: http://www.linear.com/docs/28754
Signed-off-by: Mike Looijmans
---
drivers/iio/dac/Kconfig | 3 ++-
drivers/iio/dac/ad5064.c | 58 ++--
2 files changed, 58 insertions(+),
The spec for the pca9546 was missing. This chip is the same as the pca9545
except that it lacks interrupt lines. While the i2c_device_id table mapped
the pca9546 to the pca9545 definition the compatible table did not.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/i2c
The spec for the pca9546 was missing. This chip is the same as the pca9545
except that it lacks interrupt lines. While the i2c_device_id table mapped
the pca9546 to the pca9545 definition the compatible table did not.
Signed-off-by: Mike Looijmans
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 6
d be done with it, instead
of adding platforms one by one?
select DMA_ENGINE
help
Enable support for Xilinx AXI VDMA Soft IP.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +
of adding platforms one by one?
select DMA_ENGINE
help
Enable support for Xilinx AXI VDMA Soft IP.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
x_dma_chan_probe(struct xilinx_dma_device
*xdev,
has_dre = of_property_read_bool(node, "xlnx,include-dre");
chan->genlock = of_property_read_bool(node, "xlnx,genlock-mode");
+ chan->has_fstoreen = of_property_read_bool(node, "xlnx,fstore-enable");
_bool(node, "xlnx,include-dre");
chan->genlock = of_property_read_bool(node, "xlnx,genlock-mode");
+ chan->has_fstoreen = of_property_read_bool(node, "xlnx,fstore-enable");
err = of_property_read_u32(node, "xlnx,datawidth", );
if (err) {
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
The cadence I2C driver calls cdns_i2c_writereg(..) to setup a workaround
in the controller, but did so after calling i2c_add_adapter() which starts
probing devices on the bus. Change the order so that the configuration is
completely finished before using the adapter.
Signed-off-by: Mike Looijmans
The cadence I2C driver calls cdns_i2c_writereg(..) to setup a workaround
in the controller, but did so after calling i2c_add_adapter() which starts
probing devices on the bus. Change the order so that the configuration is
completely finished before using the adapter.
Signed-off-by: Mike Looijmans
should be consistent with the other driver, I'd say.
Makes sense.
I'll create a v2 patch to just move the i2c_add_adapter to after writing the
configuration registers, and leave the dmesg output as is.
Thanks for reviewing,
Mike.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalwe
should be consistent with the other driver, I'd say.
Makes sense.
I'll create a v2 patch to just move the i2c_add_adapter to after writing the
configuration registers, and leave the dmesg output as is.
Thanks for reviewing,
Mike.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalwe
On 06-01-17 22:34, Vladimir Zapolskiy wrote:
Hello Mike,
On 01/05/2017 12:47 PM, Mike Looijmans wrote:
The driver calls i2c_add_adapter before writing to config registers,
resulting in dmesg output like this, where devices fail to initialize:
cdns-i2c ff03.i2c: timeout waiting
On 06-01-17 22:34, Vladimir Zapolskiy wrote:
Hello Mike,
On 01/05/2017 12:47 PM, Mike Looijmans wrote:
The driver calls i2c_add_adapter before writing to config registers,
resulting in dmesg output like this, where devices fail to initialize:
cdns-i2c ff03.i2c: timeout waiting
n before
the devices on the bus.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/i2c/busses/i2c-cadence.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 6869712..7793bb
n before
the devices on the bus.
Signed-off-by: Mike Looijmans
---
drivers/i2c/busses/i2c-cadence.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 6869712..7793bb8 100644
--- a/drivers/i2c/
On 17-11-2016 19:56, Guenter Roeck wrote:
On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
On 17-11-16 17:56, Guenter Roeck wrote:
On 11/17/2016 04:10 AM, Tom Levens wrote:
Updated version of the ltc2990 driver which supports all measurement
modes available in the chip
On 17-11-2016 19:56, Guenter Roeck wrote:
On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
On 17-11-16 17:56, Guenter Roeck wrote:
On 11/17/2016 04:10 AM, Tom Levens wrote:
Updated version of the ltc2990 driver which supports all measurement
modes available in the chip
/product/ltc2990
Author: Mike Looijmans <mike.looijm...@topic.nl>
+Tom Levens <tom.lev...@cern.ch>
Description
@@ -16,10 +17,8 @@ Description
LTC2990 is a Quad I2C Voltage, Current and Temperature Monitor.
The chip's inputs can measure 4 voltages, or two inputs together (1
quot;Error: Failed to set control mode.\n");
return ret;
@@ -127,7 +244,7 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
hwmon_dev = devm_hwmon_device_register_with_groups(>dev,
i2c->name,
- i2c,
+
devicetree binding documentation and list
the settings that the chip considers neutral.
Changing the implementation to accept negative values would have been
a better solution, but would break existing configurations.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Document
devicetree binding documentation and list
the settings that the chip considers neutral.
Changing the implementation to accept negative values would have been
a better solution, but would break existing configurations.
Signed-off-by: Mike Looijmans
---
Documentation/devicetree/bindings/net/micrel-k
Set bit 0 in register 1C.23 to enable the EDPD feature of the
KSZ9031 PHY. This reduces power consumption when the link is
down.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Unconditionally enable EDPD mode
drivers/net/phy/micrel.c | 21 +
1 file c
Set bit 0 in register 1C.23 to enable the EDPD feature of the
KSZ9031 PHY. This reduces power consumption when the link is
down.
Signed-off-by: Mike Looijmans
---
v2: Unconditionally enable EDPD mode
drivers/net/phy/micrel.c | 21 +
1 file changed, 21 insertions(+)
diff
think. It's a feature found on many PHYs, apparently
without any ill effects, so just enabling unconditionally simplifies
things. And it's good for the environment...
I'll post a v2 patch (which won't need devicetree changes then).
--
Mike Looijmans
think. It's a feature found on many PHYs, apparently
without any ill effects, so just enabling unconditionally simplifies
things. And it's good for the environment...
I'll post a v2 patch (which won't need devicetree changes then).
--
Mike Looijmans
Set bit 0 in register 1C.23 to enable the EDPD feature of the
KSZ9031 PHY. This reduces power consumption when the link is
down. To use this, set "enable-edpd" in the devicetree.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
.../devicetree/bindings/net/mi
Set bit 0 in register 1C.23 to enable the EDPD feature of the
KSZ9031 PHY. This reduces power consumption when the link is
down. To use this, set "enable-edpd" in the devicetree.
Signed-off-by: Mike Looijmans
---
.../devicetree/bindings/net/micrel-ksz90x1.txt| 6 ++
drive
On 30-08-16 18:38, Rob Herring wrote:
On Wed, Aug 24, 2016 at 10:13:27AM +0200, Mike Looijmans wrote:
Add devicetree property for early initialization of the fan controller
to prevent overheating, for example when resetting the board while the
fan was completely turned off.
Signed-off-by: Mike
On 30-08-16 18:38, Rob Herring wrote:
On Wed, Aug 24, 2016 at 10:13:27AM +0200, Mike Looijmans wrote:
Add devicetree property for early initialization of the fan controller
to prevent overheating, for example when resetting the board while the
fan was completely turned off.
Signed-off-by: Mike
On 26-08-16 01:01, Zach Brown wrote:
The sdhci controller on xilinx zynq devices will not function unless
the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
In cases where it is impossible to provide the CD bit in hardware,
setting the controller to test mode and then
On 26-08-16 01:01, Zach Brown wrote:
The sdhci controller on xilinx zynq devices will not function unless
the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
In cases where it is impossible to provide the CD bit in hardware,
setting the controller to test mode and then
Add devicetree property for early initialization of the fan controller
to prevent overheating, for example when resetting the board while the
fan was completely turned off.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Documentation/devicetree/bindings/hwmon/max6650.t
re ignored while writing
new values.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Documentation/hwmon/max6650 | 1 +
drivers/hwmon/max6650.c | 108 +++-
2 files changed, 68 insertions(+), 41 deletions(-)
diff --git a/Documentation
Add devicetree property for early initialization of the fan controller
to prevent overheating, for example when resetting the board while the
fan was completely turned off.
Signed-off-by: Mike Looijmans
---
Documentation/devicetree/bindings/hwmon/max6650.txt | 5 +
1 file changed, 5
re ignored while writing
new values.
Signed-off-by: Mike Looijmans
---
Documentation/hwmon/max6650 | 1 +
drivers/hwmon/max6650.c | 108 +++-
2 files changed, 68 insertions(+), 41 deletions(-)
diff --git a/Documentation/hwmon/max6650 b/Documentation/hwm
Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v5: Accept on
Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.
Signed-off-by: Mike Looijmans
---
v5: Accept only 12V or 5V supply voltage
v4
This adds the devicetree binding documentation for the max6650 fan
controller.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Allow only 12V or 5V supply voltage
.../devicetree/bindings/hwmon/max6650.txt | 23 ++
1 file changed, 23 inse
This adds the devicetree binding documentation for the max6650 fan
controller.
Signed-off-by: Mike Looijmans
---
v2: Allow only 12V or 5V supply voltage
.../devicetree/bindings/hwmon/max6650.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
(resent through different SMTP server, bounced as spam because of company
server's unwanted modifications, sorry if you received this twice now)
On 19-08-16 04:43, Guenter Roeck wrote:
On 08/16/2016 12:20 AM, Mike Looijmans wrote:
Parse devicetree parameters for voltage and prescaler setting
(resent through different SMTP server, bounced as spam because of company
server's unwanted modifications, sorry if you received this twice now)
On 19-08-16 04:43, Guenter Roeck wrote:
On 08/16/2016 12:20 AM, Mike Looijmans wrote:
Parse devicetree parameters for voltage and prescaler setting
ic details of the controller (like the fact
that fan1_target does not take effect when pwm1_enable is set to
anything but "2"). Early initialization of the fan controller prevents
overheating, for example when resetting the board while the fan was
completely turned off.
Signed-of
ic details of the controller (like the fact
that fan1_target does not take effect when pwm1_enable is set to
anything but "2"). Early initialization of the fan controller prevents
overheating, for example when resetting the board while the fan was
completely turned off.
Signed-of
This adds the devicetree binding documentation for the max6650 fan
controller.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Associated code changes sent as a separate patch as requested.
.../devicetree/bindings/hwmon/max6650.txt | 23 ++
This adds the devicetree binding documentation for the max6650 fan
controller.
Signed-off-by: Mike Looijmans
---
Associated code changes sent as a separate patch as requested.
.../devicetree/bindings/hwmon/max6650.txt | 23 ++
1 file changed, 23 insertions
Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v4: Vendor
Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.
Signed-off-by: Mike Looijmans
---
v4: Vendor prefix "maxim," for
Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v3: Resubmit b
Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.
Signed-off-by: Mike Looijmans
---
v3: Resubmit because mailing lists bounced
to make systems select the ARM global timer
as a last resort instead of a first choice.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/clocksource/arm_global_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/arm_global_time
to make systems select the ARM global timer
as a last resort instead of a first choice.
Signed-off-by: Mike Looijmans
---
drivers/clocksource/arm_global_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/arm_global_timer.c
b/drivers/clocksource
On 17-03-16 18:06, Grygorii Strashko wrote:
Hi Mike,
On 03/17/2016 09:15 AM, Mike Looijmans wrote:
The arm_global_timer clock runs on the CPU clock, and does not correct
for cpufreq scaling. This makes the clock not very suitable as a
clocksource, and basically any clock running
On 17-03-16 18:06, Grygorii Strashko wrote:
Hi Mike,
On 03/17/2016 09:15 AM, Mike Looijmans wrote:
The arm_global_timer clock runs on the CPU clock, and does not correct
for cpufreq scaling. This makes the clock not very suitable as a
clocksource, and basically any clock running
.
This is sufficient to support the Topic Miami SOM which uses this chip
to monitor the currents flowing into the FPGA and the CPU parts.
Signed-off-by: Mike Looijmans
---
drivers/hwmon/Kconfig | 15 +++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/ltc2990.c | 273
.
This is sufficient to support the Topic Miami SOM which uses this chip
to monitor the currents flowing into the FPGA and the CPU parts.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/hwmon/Kconfig | 15 +++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/ltc2990.c
and not confuse people even further. So I'd happily repost that patch.
--
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/
and not confuse people even further. So I'd happily repost that patch.
--
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/
c_coherent(),
but there are also some drivers that use dma_map_single().
If I recall correctly, most MMC controllers have their own
scatter-gather DMA controller and copy data straight to/from userspace
buffers.
--
Mike Looijmans
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
er, this is usually faster than using the streaming API.
--
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/
er, this is usually faster than using the streaming API.
--
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/
any drivers call dma_alloc_coherent(),
but there are also some drivers that use dma_map_single().
If I recall correctly, most MMC controllers have their own
scatter-gather DMA controller and copy data straight to/from userspace
buffers.
--
Mike Looijmans
--
To unsubscribe from this list: send the l
Just a "ping" reminder, I'd like to inquire about the status of this patch...
On 30-11-15 12:18, Mike Looijmans wrote:
The gadget ethernet driver supports changing the MTU, but only allows this
when the USB cable is removed. The comment indicates that this is because
the "
Just a "ping" reminder, I'd like to inquire about the status of this patch...
On 30-11-15 12:18, Mike Looijmans wrote:
The gadget ethernet driver supports changing the MTU, but only allows this
when the USB cable is removed. The comment indicates that this is because
the "
config usb0 mtu 15000") without having to manually pull
the plug or change the driver's default setting.
This is especially important after commit bba787a860fa
("usb: gadget: ether: Allow jumbo frames")
Signed-off-by: Mike Looijmans
---
v2: Fix commit reference (checkpatch) and unus
config usb0 mtu 15000") without having to manually pull
the plug or change the driver's default setting.
This is especially important after commit bba787a860fa:
"usb: gadget: ether: Allow jumbo frames".
Signed-off-by: Mike Looijmans
---
drivers/usb/gadget/function/u_ether.c | 16 -
config usb0 mtu 15000") without having to manually pull
the plug or change the driver's default setting.
This is especially important after commit bba787a860fa:
"usb: gadget: ether: Allow jumbo frames".
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
driver
config usb0 mtu 15000") without having to manually pull
the plug or change the driver's default setting.
This is especially important after commit bba787a860fa
("usb: gadget: ether: Allow jumbo frames")
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Fix comm
On 23-11-15 23:02, Moritz Fischer wrote:
Hi Mike,
thanks for your feedback. I put what I think you suggested inline below.
On Thu, Nov 19, 2015 at 11:25 PM, Mike Looijmans
wrote:
On 19-11-15 23:07, Moritz Fischer wrote:
@@ -457,19 +457,26 @@ static int zynq_fpga_probe(struct
On 23-11-15 23:02, Moritz Fischer wrote:
Hi Mike,
thanks for your feedback. I put what I think you suggested inline below.
On Thu, Nov 19, 2015 at 11:25 PM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:
On 19-11-15 23:07, Moritz Fischer wrote:
@@ -457,19 +457,26 @@ stat
c const struct of_device_id zynq_fpga_of_match[] = {
{ .compatible = "xlnx,zynq-devcfg-1.0", },
@@ -503,6 +544,7 @@ static struct platform_driver zynq_fpga_driver = {
.driver = {
.name = "zynq_fpga_manager",
.of_match_table = of_match_ptr(zy
nq_fpga_runtime_resume, NULL)
+};
+
#ifdef CONFIG_OF
static const struct of_device_id zynq_fpga_of_match[] = {
{ .compatible = "xlnx,zynq-devcfg-1.0", },
@@ -503,6 +544,7 @@ static struct platform_driver zynq_fpga_driver = {
.driver = {
.name = "zynq_fpg
could go one step further and implement a generic
DMA-through-mmap access to QSPI flash.
Mike.
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
could go one step further and implement a generic
DMA-through-mmap access to QSPI flash.
Mike.
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
Here's a series of three patches to fix up the Kconfig file in the
clk directory. No functional change, just cosmetic.
The first patch gets rid of double "help" headers and makes them uniform.
There's a simple typo fix, and moving two related entries together.
Kind regards,
Mike.
--
To
Simple cosmetic fix.
Signed-off-by: Mike Looijmans
---
drivers/clk/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 7205d2b..48ec7d3 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -154,7 +154,7 @@ config
There are two TI CDCE clock chips in this file. Move them close
together so they're easier to find.
No functional change, just cosmetic.
Signed-off-by: Mike Looijmans
---
drivers/clk/Kconfig | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk
duplicates have been spreading.
A quick survey in the kernel using grep revealed that simply "help" is
most commonly used, so convert all entries to only use a single "help"
header line.
Signed-off-by: Mike Looijmans
---
drivers/clk/Kconfig | 33 +++
Here's a series of three patches to fix up the Kconfig file in the
clk directory. No functional change, just cosmetic.
The first patch gets rid of double "help" headers and makes them uniform.
There's a simple typo fix, and moving two related entries together.
Kind regards,
Mike.
--
To
Simple cosmetic fix.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/clk/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 7205d2b..48ec7d3 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/K
There are two TI CDCE clock chips in this file. Move them close
together so they're easier to find.
No functional change, just cosmetic.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/clk/Kconfig | 16
1 file changed, 8 insertions(+), 8 deletions(-)
duplicates have been spreading.
A quick survey in the kernel using grep revealed that simply "help" is
most commonly used, so convert all entries to only use a single "help"
header line.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/clk/Kconfig |
On 23-10-15 07:31, Mike Looijmans wrote:
On 22-10-15 18:07, Sören Brinkmann wrote:
Hi Mike,
On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote:
Supplying pinmux configuration for e.g. gpio pins leads to deferred
probes because the pinctrl device is probed much later than gpio.
Move
On 22-10-15 18:07, Sören Brinkmann wrote:
Hi Mike,
On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote:
Supplying pinmux configuration for e.g. gpio pins leads to deferred
probes because the pinctrl device is probed much later than gpio.
Move the init call to a much earlier stage so
Supplying pinmux configuration for e.g. gpio pins leads to deferred
probes because the pinctrl device is probed much later than gpio.
Move the init call to a much earlier stage so it probes before the
devices that may need it.
Signed-off-by: Mike Looijmans
---
drivers/pinctrl/pinctrl-zynq.c
Supplying pinmux configuration for e.g. gpio pins leads to deferred
probes because the pinctrl device is probed much later than gpio.
Move the init call to a much earlier stage so it probes before the
devices that may need it.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
d
On 22-10-15 18:07, Sören Brinkmann wrote:
Hi Mike,
On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote:
Supplying pinmux configuration for e.g. gpio pins leads to deferred
probes because the pinctrl device is probed much later than gpio.
Move the init call to a much earlier stage so
On 23-10-15 07:31, Mike Looijmans wrote:
On 22-10-15 18:07, Sören Brinkmann wrote:
Hi Mike,
On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote:
Supplying pinmux configuration for e.g. gpio pins leads to deferred
probes because the pinctrl device is probed much later than gpio.
Move
201 - 300 of 552 matches
Mail list logo
