Re: [U-Boot] [PATCH v6 07/17] dm: Add README for driver model

2014-02-16 Thread Simon Glass
Hi Gerhard,

On 10 November 2013 11:17, Gerhard Sittig  wrote:
> On Thu, Nov 07, 2013 at 09:32 -0700, Simon Glass wrote:
>>
>> +Declaring Drivers
>> +-
>> +
>> +A driver declaration looks something like this (see
>> +drivers/demo/demo-shape.c):
>> +
>> +static const struct demo_ops simple_ops = {
>> + .hello = shape_hello,
>> + .status = shape_status,
>> +};
>> +
>> +U_BOOT_DRIVER(demo_shape_drv) = {
>> + .name   = "demo_shape_drv",
>> + .id = UCLASS_DEMO,
>> + .ops= &simple_ops,
>> + .priv_data_size = sizeof(struct shape_data),
>> +};
>
> Should the variable 'simple_ops' be named 'shape_ops' or
> 'demo_shape_ops', to better reflect that it's the list of
> operations for the 'shape' driver which implements the 'demo'
> class API?  Because 'simple' is found nowhere else in this
> example.

Yes, will fix, thanks.

>
>
>> +Things to punt for later
>> +
>> +
>> [ ... ]
>> +
>> +For pre-relocation we can simply call the driver model init function. Then
>> +post relocation we throw that away and re-init driver model again. For 
>> drivers
>> +which require some sort of continuity between pre- and post-relocation
>> +devices, we can provide access to the pre-relocatoin device pointers.
>
> s/relocatoin/relocation/

Will fix.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v6 07/17] dm: Add README for driver model

2013-11-10 Thread Gerhard Sittig
On Thu, Nov 07, 2013 at 09:32 -0700, Simon Glass wrote:
> 
> +Terminology
> +---
> +
> +Uclass - a group of device which operate in the same way. A uclass provides

s/device/devices/?

> +What is going on?
> +-
> +
> +Let's start at the top. The demo command is in common/cmd_demo.c. It does
> +the usual command procesing and then:
> +
> + struct device *demo_dev;
> +
> + ret = uclass_get_device(UCLASS_DEMO, devnum, &demo_dev);

Ah, your adding 'devnum' to the routine's signature resolved a
lot of the confusion I had after looking at the previous version
of the document. :)  Sorry for not sending my feedback in time.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v6 07/17] dm: Add README for driver model

2013-11-10 Thread Gerhard Sittig
On Thu, Nov 07, 2013 at 09:32 -0700, Simon Glass wrote:
> 
> +Declaring Drivers
> +-
> +
> +A driver declaration looks something like this (see
> +drivers/demo/demo-shape.c):
> +
> +static const struct demo_ops simple_ops = {
> + .hello = shape_hello,
> + .status = shape_status,
> +};
> +
> +U_BOOT_DRIVER(demo_shape_drv) = {
> + .name   = "demo_shape_drv",
> + .id = UCLASS_DEMO,
> + .ops= &simple_ops,
> + .priv_data_size = sizeof(struct shape_data),
> +};

Should the variable 'simple_ops' be named 'shape_ops' or
'demo_shape_ops', to better reflect that it's the list of
operations for the 'shape' driver which implements the 'demo'
class API?  Because 'simple' is found nowhere else in this
example.


> +Things to punt for later
> +
> +
> [ ... ]
> +
> +For pre-relocation we can simply call the driver model init function. Then
> +post relocation we throw that away and re-init driver model again. For 
> drivers
> +which require some sort of continuity between pre- and post-relocation
> +devices, we can provide access to the pre-relocatoin device pointers.

s/relocatoin/relocation/


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v6 07/17] dm: Add README for driver model

2013-11-07 Thread Simon Glass
This adds a README to help with understanding of this series.

Signed-off-by: Simon Glass 
---
Changes in v6:
- Rename platform_data to platdata
- Revise and update README

Changes in v5: None
Changes in v4: None
Changes in v3:
- Updated README.txt to cover changes since version 2

Changes in v2:
- Add GPIO uclass and tests
- Add U_BOOT_DEVICE to declare platform_data
- Add a single include/dm.h to bring in driver model code
- Add auto-probing feature for platform_data to avoid driver_bind() calls
- Add automatic allocation of device-specific priv data for uclasses
- Add automatic allocation of platform_data for FDT
- Add automatic allocation of priv data for devices
- Add device tree support in driver model
- Add dm_warn() to warn about impending doom
- Add integration tests for driver model
- Add new header file for lists
- Add new util file to hold utility functions
- Add sandbox GPIO driver
- Add script to run tests
- Add simple unit test functions
- Add test infrastructure for driver model
- Add tests for core code
- Allow a driver to bind to only one uclass
- Allow driver_bind() to support a NULL parent
- Put platform_data definitions in their own header file
- Remove relocation functions
- Remove unneeded arguments to uclass_bind(), uclass_unbind()
- Removed pointer return values in favour of integer
- Rename data structures to hopefully be clearer
- Rename struct device's 'bus' to 'parent'
- Standardise variable names (e.g. uclass instead of class)
- Update gpio command to use driver model
- Use driver_bind() in dm_init() instead of writing new code

 doc/driver-model/README.txt | 368 
 1 file changed, 368 insertions(+)
 create mode 100644 doc/driver-model/README.txt

diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
new file mode 100644
index 000..22c1481
--- /dev/null
+++ b/doc/driver-model/README.txt
@@ -0,0 +1,368 @@
+Driver Model
+
+
+This README contains high-level information about driver model, a unified
+way of declaring and accessing drivers in U-Boot. The original work was done
+by:
+
+   Marek Vasut 
+   Pavel Herrmann 
+   Viktor Křivák 
+   Tomas Hlavacek 
+
+This has been both simplified and extended into the current implementation
+by:
+
+   Simon Glass 
+
+
+Terminology
+---
+
+Uclass - a group of device which operate in the same way. A uclass provides
+   a way of accessing invidual devices within the group, but always
+   using the same interface. For example a GPIO uclass provides
+   operations for get/set value. An I2C uclass may have 10 I2C ports,
+   4 with one driver, and 6 with another.
+
+Driver - some code which talks to a peripheral and presents a higher-level
+   interface to it.
+
+Device - an instance of a driver, tied to a particular port or peripheral.
+
+
+How to try it
+-
+
+Build U-Boot sandbox and run it:
+
+   make sandbox_config
+   make
+   ./u-boot
+
+   (type 'reset' to exit U-Boot)
+
+
+There is a uclass called 'demo'. This uclass handles
+saying hello, and reporting its status. There are two drivers in this
+uclass:
+
+   - simple: Just prints a message for hello, doesn't implement status
+   - shape: Prints shapes and reports number of characters printed as status
+
+The demo class is pretty simple, but not trivial. The intention is that it
+can be used for testing, so it will implement all driver model features and
+provide good code coverage of them. It does have multiple drivers, it
+handles parameter data and platdata (data which tells the driver how
+to operate on a particular platform) and it uses private driver data.
+
+To try it, see the example session below:
+
+=>demo hello 1
+Hello '@' from 07981110: red 4
+=>demo status 2
+Status: 0
+=>demo hello 2
+g
+r@
+e@@
+e@@@
+n
+g@
+=>demo status 2
+Status: 21
+=>demo hello 4 ^
+  y^^^
+ e^
+l^^^
+l^^^
+ o^
+  w^^^
+=>demo status 4
+Status: 36
+=>
+
+
+Running the tests
+-
+
+The intent with driver model is that the core portion has 100% test coverage
+in sandbox, and every uclass has its own test. As a move towards this, tests
+are provided in test/dm. To run them, try:
+
+   ./test/dm/test-dm.sh
+
+You should see something like this:
+
+<...U-Boot banner...>
+Running 12 driver model tests
+Test: dm_test_autobind
+Test: dm_test_autoprobe
+Test: dm_test_children
+Test: dm_test_fdt
+Test: dm_test_gpio
+sandbox_gpio: sb_gpio_get_value: error: offset 4 not reserved
+Test: dm_test_leak
+Warning: Please add '#define DEBUG' to the top of common/dlmalloc.c
+Warning: Please add '#define DEBUG' to the top of common/dlmalloc.c
+Test: dm_test_lifecycle
+Test: dm_test_operations
+Test: dm_test_ordering
+Test: dm_test_platdata
+Test: dm_test_remove
+Test: dm_test_uclass
+Failures: 0
+
+(You can add '#define DEBUG' as suggested to check for memory leaks)
+
+
+What is going on?
+---