u-boot.git/include/dm, branch v2016.07-rc2 Unnamed repository; edit this file 'description' to name the repository. Add a reset driver framework/uclass 2016-06-19T23:05:55+00:00 Stephen Warren swarren@nvidia.com 2016-06-17T15:43:58+00:00 89c1e2da78f82a09685006291ce8bb44f635fa25 A reset controller is a hardware module that controls reset signals that affect other hardware modules or chips. This patch defines a standard API that connects reset clients (i.e. the drivers for devices affected by reset signals) to drivers for reset controllers/providers. Initially, DT is the only supported method for connecting the two. The DT binding specification (reset.txt) was taken from Linux kernel v4.5's Documentation/devicetree/bindings/reset/reset.txt. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> 
A reset controller is a hardware module that controls reset signals that
affect other hardware modules or chips.

This patch defines a standard API that connects reset clients (i.e. the
drivers for devices affected by reset signals) to drivers for reset
controllers/providers. Initially, DT is the only supported method for
connecting the two.

The DT binding specification (reset.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/reset/reset.txt.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Add a mailbox driver framework/uclass 2016-05-27T02:48:31+00:00 Stephen Warren swarren@nvidia.com 2016-05-13T21:50:29+00:00 6238935d018042d332aa7e90eae3addfeb11abdc A mailbox is a hardware mechanism for transferring small message and/or notifications between the CPU on which U-Boot runs and some other device such as an auxilliary CPU running firmware or a hardware module. This patch defines a standard API that connects mailbox clients to mailbox providers (drivers). Initially, DT is the only supported method for connecting the two. The DT binding specification (mailbox.txt) was taken from Linux kernel v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> 
A mailbox is a hardware mechanism for transferring small message and/or
notifications between the CPU on which U-Boot runs and some other device
such as an auxilliary CPU running firmware or a hardware module.

This patch defines a standard API that connects mailbox clients to mailbox
providers (drivers). Initially, DT is the only supported method for
connecting the two.

The DT binding specification (mailbox.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Rename reset to sysreset 2016-05-27T02:48:31+00:00 Stephen Warren swarren@nvidia.com 2016-05-12T18:03:35+00:00 11636258981a083957c19f3979796fde5e7e8080 The current reset API implements a method to reset the entire system. In the near future, I'd like to introduce code that implements the device tree reset bindings; i.e. the equivalent of the Linux kernel's reset API. This controls resets to individual HW blocks or external chips with reset signals. It doesn't make sense to merge the two APIs into one since they have different semantic purposes. Resolve the naming conflict by renaming the existing reset API to sysreset instead, so the new reset API can be called just reset. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> 
The current reset API implements a method to reset the entire system.
In the near future, I'd like to introduce code that implements the device
tree reset bindings; i.e. the equivalent of the Linux kernel's reset API.
This controls resets to individual HW blocks or external chips with reset
signals. It doesn't make sense to merge the two APIs into one since they
have different semantic purposes. Resolve the naming conflict by renaming
the existing reset API to sysreset instead, so the new reset API can be
called just reset.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
dm: allow setting driver_data before/during bind 2016-05-27T02:48:31+00:00 Stephen Warren swarren@nvidia.com 2016-05-11T21:26:24+00:00 daac3bfee57247013cb8373683e9babb191abd75 This will allow a driver's bind function to use the driver data. One example is the Tegra186 GPIO driver, which instantiates child devices for each of its GPIO ports, yet supports two different HW instances each with a different set of ports, and identified by the udevice_id .data field. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> 
This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
drivers: core: device: add support to check dt compatible for a device/machine 2016-05-24T16:42:02+00:00 Mugunthan V N mugunthanvnm@ti.com 2016-04-28T10:06:02+00:00 73443b9e4c451b17d1e08164ea933ee6a849b2b3 Provide an api to check whether the given device or machine is compatible with the given compat string which helps in making decisions in drivers based on device or machine compatible. Idea taken from Linux. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> 
Provide an api to check whether the given device or machine is
compatible with the given compat string which helps in making
decisions in drivers based on device or machine compatible.

Idea taken from Linux.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
dm: core: Allow device names to be freed automatically 2016-05-17T15:54:43+00:00 Simon Glass sjg@chromium.org 2016-05-01T19:52:23+00:00 a2040facd23b88082b9b40f0aa9bcfd495eab88e Some devices have a name that is stored in allocated memory. At present there is no mechanism to free this memory when the device is unbound. Add a device flag to track whether a name is allocated and a function to add the flag. Free the memory when the device is unbound. Signed-off-by: Simon Glass <sjg@chromium.org> 
Some devices have a name that is stored in allocated memory. At present
there is no mechanism to free this memory when the device is unbound.

Add a device flag to track whether a name is allocated and a function to
add the flag. Free the memory when the device is unbound.

Signed-off-by: Simon Glass <sjg@chromium.org>
dm: Rename disk uclass to ahci 2016-05-17T15:54:43+00:00 Simon Glass sjg@chromium.org 2016-05-01T17:35:52+00:00 a219639d4216e59a0c55f0b7d2c8a21f9cb0bb06 This started as 'ahci' and was renamed to 'disk' during code review. But it seems that this is too generic. Now that we have a 'blk' uclass, we can use that as the generic piece, and revert to ahci for this. Signed-off-by: Simon Glass <sjg@chromium.org> 
This started as 'ahci' and was renamed to 'disk' during code review. But it
seems that this is too generic. Now that we have a 'blk' uclass, we can use
that as the generic piece, and revert to ahci for this.

Signed-off-by: Simon Glass <sjg@chromium.org>
m68k: add DM model serial driver 2016-05-17T15:54:43+00:00 angelo@sysam.it angelo@sysam.it 2016-04-27T19:51:13+00:00 e27802af54c2ff2d4d58e4bc217644b75c04ac4c Boards can now use DM serial driver, or still legacy mcf uart driver version. Signed-off-by: Angelo Dureghello <angelo@sysam.it> Acked-by: Simon Glass <sjg@chromium.org> 
Boards can now use DM serial driver, or still legacy mcf uart
driver version.

Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Acked-by: Simon Glass <sjg@chromium.org>
dm: core: Add dev_get_addr_ptr() to return a pointer to the reg address 2016-04-25T05:30:16+00:00 Stefan Roese sr@denx.de 2016-04-21T05:11:34+00:00 28027521be95d27fcb83669e09ce3563bb4dd977 On some platforms (e.g. x86), the return value of dev_get_addr() can't be assigned to a pointer type variable directly. As there might be a difference between the size of fdt_addr_t and the pointer type. On x86 for example, "fdt_addr_t" is 64bit but "void *" only 32bit. So assigning the register base directly in dev_get_addr() results in this compilation warning: warning: cast to pointer from integer of different size This patch introduces the new function dev_get_addr_ptr() that returns a pointer to the 'reg' address that can be used by drivers in this case. Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
On some platforms (e.g. x86), the return value of dev_get_addr() can't
be assigned to a pointer type variable directly. As there might be a
difference between the size of fdt_addr_t and the pointer type. On
x86 for example, "fdt_addr_t" is 64bit but "void *" only 32bit. So
assigning the register base directly in dev_get_addr() results in this
compilation warning:
  warning: cast to pointer from integer of different size

This patch introduces the new function dev_get_addr_ptr() that
returns a pointer to the 'reg' address that can be used by drivers
in this case.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
fdt: implement dev_get_addr_name() 2016-04-15T14:14:37+00:00 Stephen Warren swarren@nvidia.com 2016-04-06T18:49:19+00:00 43c4d44e3330fd21679c0790fa2176075d0e69bf This function parses the reg property based on an index found in the reg-names property. This is required for bindings that are written using reg-names rather than hard-coding indices in reg. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> 
This function parses the reg property based on an index found in the
reg-names property. This is required for bindings that are written
using reg-names rather than hard-coding indices in reg.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>