From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sat, 12 Dec 2020 08:39:58 -0700 Subject: [PATCH v2 00/26] dm: Change the way sequence numbers are implemented In-Reply-To: References: <20201211013151.1927814-1-sjg@chromium.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Michael, On Fri, 11 Dec 2020 at 01:55, Michael Walle wrote: > > Hi Simon, > > Am 2020-12-11 02:31, schrieb Simon Glass: > > At present each device has two sequence numbers, with 'req_seq' being > > set up at bind time and 'seq' at probe time. The idea is that devices > > can 'request' a sequence number and then the conflicts are resolved > > when > > the device is probed. > > > > This makes things complicated in a few cases, since we don't really > > know > > (at bind time) what the sequence number will end up being. We want to > > honour the bind-time requests if at all possible, but in fact the only > > source of these at present is the devicetree aliases. > > > > Apart from the obvious need for sequence numbers to supports U-Boot's > > numbering on devices on the command line, the current scheme was > > designed to: > > > > - avoid calculating the sequence number until it is needed, to save > > execution time > > - allow multiple devices to obtain a particular sequence number as they > > are probed and removed > > - retain a record of the 'requested' sequence number even if it turns > > out > > that a device could not get it (to allow debugging and retrying) > > > > After some years using the current scheme it seems on balance that > > these > > goals don't have as much merit as first thought. The first point would > > be persuasive except that we end up reading the devicetree aliases at > > bind-time anyway. So the work of resolving the sequence numbers during > > probing is not that great. The second point hasn't really been an > > issue, > > as there is typically no contention for sequence numbers (boards tend > > to > > allocate them statically in the devicetree). Re the third point, we can > > often figure out what was requested by looking at aliases, and in the > > cases where we can't, it doesn't seem to matter much. > > > > Since we have the devicetree available at bind time, we may as well > > just > > use it, in the hope that the required processing will turn out to be > > useful later (i.e. the device actually gets used). In addition, it is > > simpler to use a single sequence number, since it avoids confusion and > > some extra code. > > > > This series moves U-Boot to use a single, bind-time sequence number. > > All > > uclasses assign sequence numbers to their devices, so that as soon as a > > device is bound, it has a sequence number. If the uclass flag > > DM_UC_FLAG_SEQ_ALIAS is enabled (as well as the CONFIG option), a > > devicetree alias provides the number. Otherwise, the next available > > number > > (after the last alias and avoiding existing devices) is used. > > > > Apart from the simplicity gains, overall these changes seem to reduce > > the > > number of tweaks and workarounds needed to get the desired behaviour. > > > > However there will certainly be some problems created, so board > > maintainers should test this out. > > > > This series is available at u-boot-dm/seq-working > > > > Changes in v2: > > - Give all devices a sequence number > > - Drop uclass_alloc_all_seqs() and GD_FLG_DM_NO_SEQ flag > > - Drop the GD_FLG_DM_NO_SEQ flag > > - Use the sequence number directly instead of max bus > > - Adjust the tests to handle the new allocation scheme > > - Drop the networking changes which are no-longer needed > > - Update for new logic > > - Adjust commit message > > - Drop pointless check for max == -1 > > - Adjust the tests to handle the new allocation scheme > > - Simplify the logic so auto_seq is positive > > - Update the docs to indicate all devices get a sequence number > > - Update the docs to explain how aliases reserve sequence numbers > > - Drop commit changing efi_uc_destroy() > > Sequence numbers looks good, but PCI still doesnt work on my board. Thanks for trying this out. I suppose you have a different problem from what I found in v1. Can you please send the output of these things before and after the change? dm tree dm uc pci pci 1 (e.g. for other buses) pci 0 long Which board is it? I suppose there is a chance I have one. Thanks, Simon