From dfc1e148542f6f4951fd59e32c14a7368356db9d Mon Sep 17 00:00:00 2001 From: Adrian Bunk Date: Thu, 5 May 2005 16:15:51 -0700 Subject: [PATCH] remove BK documentation There's no longer a reason to document the obsolete BK usage. Signed-off-by: Adrian Bunk Cc: Jeff Garzik Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/00-INDEX | 2 - Documentation/BK-usage/00-INDEX | 51 ------ Documentation/BK-usage/bk-kernel-howto.txt | 283 ----------------------------- Documentation/BK-usage/bk-make-sum | 34 ---- Documentation/BK-usage/bksend | 36 ---- Documentation/BK-usage/bz64wrap | 41 ----- Documentation/BK-usage/cpcset | 36 ---- Documentation/BK-usage/cset-to-linus | 49 ----- Documentation/BK-usage/csets-to-patches | 44 ----- Documentation/BK-usage/gcapatch | 8 - Documentation/BK-usage/unbz64wrap | 25 --- 11 files changed, 609 deletions(-) delete mode 100644 Documentation/BK-usage/00-INDEX delete mode 100644 Documentation/BK-usage/bk-kernel-howto.txt delete mode 100755 Documentation/BK-usage/bk-make-sum delete mode 100755 Documentation/BK-usage/bksend delete mode 100755 Documentation/BK-usage/bz64wrap delete mode 100755 Documentation/BK-usage/cpcset delete mode 100755 Documentation/BK-usage/cset-to-linus delete mode 100755 Documentation/BK-usage/csets-to-patches delete mode 100755 Documentation/BK-usage/gcapatch delete mode 100755 Documentation/BK-usage/unbz64wrap (limited to 'Documentation') diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 72dc90f8f4a7..8de8a01a2474 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -12,8 +12,6 @@ Following translations are available on the WWW: 00-INDEX - this file. -BK-usage/ - - directory with info on BitKeeper. BUG-HUNTING - brute force method of doing binary search of patches to find bug. Changes diff --git a/Documentation/BK-usage/00-INDEX b/Documentation/BK-usage/00-INDEX deleted file mode 100644 index 82768784ea52..000000000000 --- a/Documentation/BK-usage/00-INDEX +++ /dev/null @@ -1,51 +0,0 @@ -bk-kernel-howto.txt: Description of kernel workflow under BitKeeper - -bk-make-sum: Create summary of changesets in one repository and not -another, typically in preparation to be sent to an upstream maintainer. -Typical usage: - cd my-updated-repo - bk-make-sum ~/repo/original-repo - mv /tmp/linus.txt ../original-repo.txt - -bksend: Create readable text output containing summary of changes, GNU -patch of the changes, and BK metadata of changes (as needed for proper -importing into BitKeeper by an upstream maintainer). This output is -suitable for emailing BitKeeper changes. The recipient of this output -may pipe it directly to 'bk receive'. - -bz64wrap: helper script. Uncompressed input is piped to this script, -which compresses its input, and then outputs the uu-/base64-encoded -version of the compressed input. - -cpcset: Copy changeset between unrelated repositories. -Attempts to preserve changeset user, user address, description, in -addition to the changeset (the patch) itself. -Typical usage: - cd my-updated-repo - bk changes # looking for a changeset... - cpcset 1.1511 . ../another-repo - -csets-to-patches: Produces a delta of two BK repositories, in the form -of individual files, each containing a single cset as a GNU patch. -Output is several files, each with the filename "/tmp/rev-$REV.patch" -Typical usage: - cd my-updated-repo - bk changes -L ~/repo/original-repo 2>&1 | \ - perl csets-to-patches - -cset-to-linus: Produces a delta of two BK repositories, in the form of -changeset descriptions, with 'diffstat' output created for each -individual changset. -Typical usage: - cd my-updated-repo - bk changes -L ~/repo/original-repo 2>&1 | \ - perl cset-to-linus > summary.txt - -gcapatch: Generates patch containing changes in local repository. -Typical usage: - cd my-updated-repo - gcapatch > foo.patch - -unbz64wrap: Reverse an encoded, compressed data stream created by -bz64wrap into an uncompressed, typically text/plain output. - diff --git a/Documentation/BK-usage/bk-kernel-howto.txt b/Documentation/BK-usage/bk-kernel-howto.txt deleted file mode 100644 index b7b9075d2910..000000000000 --- a/Documentation/BK-usage/bk-kernel-howto.txt +++ /dev/null @@ -1,283 +0,0 @@ - - Doing the BK Thing, Penguin-Style - - - - -This set of notes is intended mainly for kernel developers, occasional -or full-time, but sysadmins and power users may find parts of it useful -as well. It assumes at least a basic familiarity with CVS, both at a -user level (use on the cmd line) and at a higher level (client-server model). -Due to the author's background, an operation may be described in terms -of CVS, or in terms of how that operation differs from CVS. - -This is -not- intended to be BitKeeper documentation. Always run -"bk help " or in X "bk helptool " for reference -documentation. - - -BitKeeper Concepts ------------------- - -In the true nature of the Internet itself, BitKeeper is a distributed -system. When applied to revision control, this means doing away with -client-server, and changing to a parent-child model... essentially -peer-to-peer. On the developer's end, this also represents a -fundamental disruption in the standard workflow of changes, commits, -and merges. You will need to take a few minutes to think about -how to best work under BitKeeper, and re-optimize things a bit. -In some sense it is a bit radical, because it might described as -tossing changes out into a maelstrom and having them magically -land at the right destination... but I'm getting ahead of myself. - -Let's start with this progression: -Each BitKeeper source tree on disk is a repository unto itself. -Each repository has a parent (except the root/original, of course). -Each repository contains a set of a changesets ("csets"). -Each cset is one or more changed files, bundled together. - -Each tree is a repository, so all changes are checked into the local -tree. When a change is checked in, all modified files are grouped -into a logical unit, the changeset. Internally, BK links these -changesets in a tree, representing various converging and diverging -lines of development. These changesets are the bread and butter of -the BK system. - -After the concept of changesets, the next thing you need to get used -to is having multiple copies of source trees lying around. This -really- -takes some getting used to, for some people. Separate source trees -are the means in BitKeeper by which you delineate parallel lines -of development, both minor and major. What would be branches in -CVS become separate source trees, or "clones" in BitKeeper [heh, -or Star Wars] terminology. - -Clones and changesets are the tools from which most of the power of -BitKeeper is derived. As mentioned earlier, each clone has a parent, -the tree used as the source when the new clone was created. In a -CVS-like setup, the parent would be a remote server on the Internet, -and the child is your local clone of that tree. - -Once you have established a common baseline between two source trees -- -a common parent -- then you can merge changesets between those two -trees with ease. Merging changes into a tree is called a "pull", and -is analagous to 'cvs update'. A pull downloads all the changesets in -the remote tree you do not have, and merges them. Sending changes in -one tree to another tree is called a "push". Push sends all changes -in the local tree the remote does not yet have, and merges them. - -From these concepts come some initial command examples: - -1) bk clone -q http://linux.bkbits.net/linux-2.5 linus-2.5 -Download a 2.5 stock kernel tree, naming it "linus-2.5" in the local dir. -The "-q" disables listing every single file as it is downloaded. - -2) bk clone -ql linus-2.5 alpha-2.5 -Create a separate source tree for the Alpha AXP architecture. -The "-l" uses hard links instead of copying data, since both trees are -on the local disk. You can also replace the above with "bk lclone -q ..." - -You only clone a tree -once-. After cloning the tree lives a long time -on disk, being updating by pushes and pulls. - -3) cd alpha-2.5 ; bk pull http://gkernel.bkbits.net/alpha-2.5 -Download changes in "alpha-2.5" repository which are not present -in the local repository, and merge them into the source tree. - -4) bk -r co -q -Because every tree is a repository, files must be checked out before -they will be in their standard places in the source tree. - -5) bk vi fs/inode.c # example change... - bk citool # checkin, using X tool - bk push bk://gkernel@bkbits.net/alpha-2.5 # upload change -Typical example of a BK sequence that would replace the analagous CVS -situation, - vi fs/inode.c - cvs commit - -As this is just supposed to be a quick BK intro, for more in-depth -tutorials, live working demos, and docs, see http://www.bitkeeper.com/ - - - -BK and Kernel Development Workflow ----------------------------------- -Currently the latest 2.5 tree is available via "bk clone $URL" -and "bk pull $URL" at http://linux.bkbits.net/linux-2.5 -This should change in a few weeks to a kernel.org URL. - - -A big part of using BitKeeper is organizing the various trees you have -on your local disk, and organizing the flow of changes among those -trees, and remote trees. If one were to graph the relationships between -a desired BK setup, you are likely to see a few-many-few graph, like -this: - - linux-2.5 - | - merge-to-linus-2.5 - / | | - / | | - vm-hacks bugfixes filesys personal-hacks - \ | | / - \ | | / - \ | | / - testing-and-validation - -Since a "bk push" sends all changes not in the target tree, and -since a "bk pull" receives all changes not in the source tree, you want -to make sure you are only pushing specific changes to the desired tree, -not all changes from "peer parent" trees. For example, pushing a change -from the testing-and-validation tree would probably be a bad idea, -because it will push all changes from vm-hacks, bugfixes, filesys, and -personal-hacks trees into the target tree. - -One would typically work on only one "theme" at a time, either -vm-hacks or bugfixes or filesys, keeping those changes isolated in -their own tree during development, and only merge the isolated with -other changes when going upstream (to Linus or other maintainers) or -downstream (to your "union" trees, like testing-and-validation above). - -It should be noted that some of this separation is not just recommended -practice, it's actually [for now] -enforced- by BitKeeper. BitKeeper -requires that changesets maintain a certain order, which is the reason -that "bk push" sends all local changesets the remote doesn't have. This -separation may look like a lot of wasted disk space at first, but it -helps when two unrelated changes may "pollute" the same area of code, or -don't follow the same pace of development, or any other of the standard -reasons why one creates a development branch. - -Small development branches (clones) will appear and disappear: - - -------- A --------- B --------- C --------- D ------- - \ / - -----short-term devel branch----- - -While long-term branches will parallel a tree (or trees), with period -merge points. In this first example, we pull from a tree (pulls, -"\") periodically, such as what occurs when tracking changes in a -vendor tree, never pushing changes back up the line: - - -------- A --------- B --------- C --------- D ------- - \ \ \ - ----long-term devel branch----------------- - -And then a more common case in Linux kernel development, a long term -branch with periodic merges back into the tree (pushes, "/"): - - -------- A --------- B --------- C --------- D ------- - \ \ / \ - ----long-term devel branch----------------- - - - - - -Submitting Changes to Linus ---------------------------- -There's a bit of an art, or style, of submitting changes to Linus. -Since Linus's tree is now (you might say) fully integrated into the -distributed BitKeeper system, there are several prerequisites to -properly submitting a BitKeeper change. All these prereq's are just -general cleanliness of BK usage, so as people become experts at BK, feel -free to optimize this process further (assuming Linus agrees, of -course). - - - -0) Make sure your tree was originally cloned from the linux-2.5 tree -created by Linus. If your tree does not have this as its ancestor, it -is impossible to reliably exchange changesets. - - - -1) Pay attention to your commit text. The commit message that -accompanies each changeset you submit will live on forever in history, -and is used by Linus to accurately summarize the changes in each -pre-patch. Remember that there is no context, so - "fix for new scheduler changes" -would be too vague, but - "fix mips64 arch for new scheduler switch_to(), TIF_xxx semantics" -would be much better. - -You can and should use the command "bk comment -C" to update the -commit text, and improve it after the fact. This is very useful for -development: poor, quick descriptions during development, which get -cleaned up using "bk comment" before issuing the "bk push" to submit the -changes. - - - -2) Include an Internet-available URL for Linus to pull from, such as - - Pull from: http://gkernel.bkbits.net/net-drivers-2.5 - - - -3) Include a summary and "diffstat -p1" of each changeset that will be -downloaded, when Linus issues a "bk pull". The author auto-generates -these summaries using "bk changes -L ", to obtain a listing -of all the pending-to-send changesets, and their commit messages. - -It is important to show Linus what he will be downloading when he issues -a "bk pull", to reduce the time required to sift the changes once they -are downloaded to Linus's local machine. - -IMPORTANT NOTE: One of the features of BK is that your repository does -not have to be up to date, in order for Linus to receive your changes. -It is considered a courtesy to keep your repository fairly recent, to -lessen any potential merge work Linus may need to do. - - -4) Split up your changes. Each maintainer<->Linus situation is likely -to be slightly different here, so take this just as general advice. The -author splits up changes according to "themes" when merging with Linus. -Simultaneous pushes from local development go to special trees which -exist solely to house changes "queued" for Linus. Example of the trees: - - net-drivers-2.5 -- on-going net driver maintenance - vm-2.5 -- VM-related changes - fs-2.5 -- filesystem-related changes - -Linus then has much more freedom for pulling changes. He could (for -example) issue a "bk pull" on vm-2.5 and fs-2.5 trees, to merge their -changes, but hold off net-drivers-2.5 because of a change that needs -more discussion. - -Other maintainers may find that a single linus-pull-from tree is -adequate for passing BK changesets to him. - - - -Frequently Answered Questions ------------------------------ -1) How do I change the e-mail address shown in the changelog? -A. When you run "bk citool" or "bk commit", set environment - variables BK_USER and BK_HOST to the desired username - and host/domain name. - - -2) How do I use tags / get a diff between two kernel versions? -A. Pass the tags Linus uses to 'bk export'. - -ChangeSets are in a forward-progressing order, so it's pretty easy -to get a snapshot starting and ending at any two points in time. -Linus puts tags on each release and pre-release, so you could use -these two examples: - - bk export -tpatch -hdu -rv2.5.4,v2.5.5 | less - # creates patch-2.5.5 essentially - bk export -tpatch -du -rv2.5.5-pre1,v2.5.5 | less - # changes from pre1 to final - -A tag is just an alias for a specific changeset... and since changesets -are ordered, a tag is thus a marker for a specific point in time (or -specific state of the tree). - - -3) Is there an easy way to generate One Big Patch versus mainline, - for my long-lived kernel branch? -A. Yes. This requires BK 3.x, though. - - bk export -tpatch -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+ - diff --git a/Documentation/BK-usage/bk-make-sum b/Documentation/BK-usage/bk-make-sum deleted file mode 100755 index 58ca46a0fcc6..000000000000 --- a/Documentation/BK-usage/bk-make-sum +++ /dev/null @@ -1,34 +0,0 @@ -#!/bin/sh -e -# DIR=$HOME/BK/axp-2.5 -# cd $DIR - -LINUS_REPO=$1 -DIRBASE=`basename $PWD` - -{ -cat </dev/null - -cat < (:D: :I:)\n$each(:C:){ (:C:)\n}\n}' - - -} > /tmp/linus.txt - -cat < 13/02/2002 -# -# Add diffstat output after Changelog 21/02/2002 - -PROG=bksend - -usage() { - echo "usage: $PROG -r" - echo -e "\twhere is of the form '1.23', '1.23..', '1.23..1.27'," - echo -e "\tor '+' to indicate the most recent revision" - - exit 1 -} - -case $1 in --r) REV=$2; shift ;; --r*) REV=`echo $1 | sed 's/^-r//'` ;; -*) echo "$PROG: no revision given, you probably don't want that";; -esac - -[ -z "$REV" ] && usage - -echo "You can import this changeset into BK by piping this whole message to:" -echo "'| bk receive [path to repository]' or apply the patch as usual." - -SEP="\n===================================================================\n\n" -echo -e $SEP -env PAGER=/bin/cat bk changes -r$REV -echo -bk export -tpatch -du -h -r$REV | diffstat -echo; echo -bk export -tpatch -du -h -r$REV -echo -e $SEP -bk send -wgzip_uu -r$REV - diff --git a/Documentation/BK-usage/bz64wrap b/Documentation/BK-usage/bz64wrap deleted file mode 100755 index be780876849f..000000000000 --- a/Documentation/BK-usage/bz64wrap +++ /dev/null @@ -1,41 +0,0 @@ -#!/bin/sh - -# bz64wrap - the sending side of a bzip2 | base64 stream -# Andreas Dilger Jan 2002 - - -PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin - -# A program to generate base64 encoding on stdout -BASE64_ENCODE="uuencode -m /dev/stdout" -BASE64_BEGIN= -BASE64_END= - -BZIP=NO -BASE64=NO - -# Test if we have the bzip program installed -bzip2 -c /dev/null > /dev/null 2>&1 && BZIP=YES - -# Test if uuencode can handle the -m (MIME) encoding option -$BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES - -if [ $BASE64 = NO ]; then - BASE64_ENCODE=mimencode - BASE64_BEGIN="begin-base64 644 -" - BASE64_END="====" - - $BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES -fi - -if [ $BZIP = NO -o $BASE64 = NO ]; then - echo "$0: can't use bz64 encoding: bzip2=$BZIP, $BASE64_ENCODE=$BASE64" - exit 1 -fi - -# Sadly, mimencode does not appear to have good "begin" and "end" markers -# like uuencode does, and it is picky about getting the right start/end of -# the base64 stream, so we handle this internally. -echo "$BASE64_BEGIN" -bzip2 -9 | $BASE64_ENCODE -echo "$BASE64_END" diff --git a/Documentation/BK-usage/cpcset b/Documentation/BK-usage/cpcset deleted file mode 100755 index b8faca97dab9..000000000000 --- a/Documentation/BK-usage/cpcset +++ /dev/null @@ -1,36 +0,0 @@ -#!/bin/sh -# -# Purpose: Copy changeset patch and description from one -# repository to another, unrelated one. -# -# usage: cpcset [revision] [from-repository] [to-repository] -# - -REV=$1 -FROM=$2 -TO=$3 -TMPF=/tmp/cpcset.$$ - -rm -f $TMPF* - -CWD_SAVE=`pwd` -cd $FROM -bk changes -r$REV | \ - grep -v '^ChangeSet' | \ - sed -e 's/^ //g' > $TMPF.log - -USERHOST=`bk changes -r$REV | grep '^ChangeSet' | awk '{print $4}'` -export BK_USER=`echo $USERHOST | awk '-F@' '{print $1}'` -export BK_HOST=`echo $USERHOST | awk '-F@' '{print $2}'` - -bk export -tpatch -hdu -r$REV > $TMPF.patch && \ -cd $CWD_SAVE && \ -cd $TO && \ -bk import -tpatch -CFR -y"`cat $TMPF.log`" $TMPF.patch . && \ -bk commit -y"`cat $TMPF.log`" - -rm -f $TMPF* - -echo changeset $REV copied. -echo "" - diff --git a/Documentation/BK-usage/cset-to-linus b/Documentation/BK-usage/cset-to-linus deleted file mode 100755 index d28a96f8c618..000000000000 --- a/Documentation/BK-usage/cset-to-linus +++ /dev/null @@ -1,49 +0,0 @@ -#!/usr/bin/perl -w - -use strict; - -my ($lhs, $rev, $tmp, $rhs, $s); -my @cset_text = (); -my @pipe_text = (); -my $have_cset = 0; - -while (<>) { - next if /^---/; - - if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) { - &cset_rev if ($have_cset); - - $rev = $tmp; - $have_cset = 1; - - push(@cset_text, $_); - } - - elsif ($have_cset) { - push(@cset_text, $_); - } -} -&cset_rev if ($have_cset); -exit(0); - - -sub cset_rev { - my $empty_cset = 0; - - open PIPE, "bk export -tpatch -hdu -r $rev | diffstat -p1 2>/dev/null |" or die; - while ($s = ) { - $empty_cset = 1 if ($s =~ /0 files changed/); - push(@pipe_text, $s); - } - close(PIPE); - - if (! $empty_cset) { - print @cset_text; - print @pipe_text; - print "\n\n"; - } - - @pipe_text = (); - @cset_text = (); -} - diff --git a/Documentation/BK-usage/csets-to-patches b/Documentation/BK-usage/csets-to-patches deleted file mode 100755 index e2b81c35883f..000000000000 --- a/Documentation/BK-usage/csets-to-patches +++ /dev/null @@ -1,44 +0,0 @@ -#!/usr/bin/perl -w - -use strict; - -my ($lhs, $rev, $tmp, $rhs, $s); -my @cset_text = (); -my @pipe_text = (); -my $have_cset = 0; - -while (<>) { - next if /^---/; - - if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) { - &cset_rev if ($have_cset); - - $rev = $tmp; - $have_cset = 1; - - push(@cset_text, $_); - } - - elsif ($have_cset) { - push(@cset_text, $_); - } -} -&cset_rev if ($have_cset); -exit(0); - - -sub cset_rev { - my $empty_cset = 0; - - system("bk export -tpatch -du -r $rev > /tmp/rev-$rev.patch"); - - if (! $empty_cset) { - print @cset_text; - print @pipe_text; - print "\n\n"; - } - - @pipe_text = (); - @cset_text = (); -} - diff --git a/Documentation/BK-usage/gcapatch b/Documentation/BK-usage/gcapatch deleted file mode 100755 index aaeb17dc7c7f..000000000000 --- a/Documentation/BK-usage/gcapatch +++ /dev/null @@ -1,8 +0,0 @@ -#!/bin/sh -# -# Purpose: Generate GNU diff of local changes versus canonical top-of-tree -# -# Usage: gcapatch > foo.patch -# - -bk export -tpatch -hdu -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+ diff --git a/Documentation/BK-usage/unbz64wrap b/Documentation/BK-usage/unbz64wrap deleted file mode 100755 index 4fc3e73e9a81..000000000000 --- a/Documentation/BK-usage/unbz64wrap +++ /dev/null @@ -1,25 +0,0 @@ -#!/bin/sh - -# unbz64wrap - the receiving side of a bzip2 | base64 stream -# Andreas Dilger Jan 2002 - -# Sadly, mimencode does not appear to have good "begin" and "end" markers -# like uuencode does, and it is picky about getting the right start/end of -# the base64 stream, so we handle this explicitly here. - -PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin - -if mimencode -u < /dev/null > /dev/null 2>&1 ; then - SHOW= - while read LINE; do - case $LINE in - begin-base64*) SHOW=YES ;; - ====) SHOW= ;; - *) [ "$SHOW" ] && echo "$LINE" ;; - esac - done | mimencode -u | bunzip2 - exit $? -else - cat - | uudecode -o /dev/stdout | bunzip2 - exit $? -fi -- cgit v1.2.1 From ac5f34c028a043405de087e43699195ab3974dbf Mon Sep 17 00:00:00 2001 From: Matt Porter Date: Thu, 5 May 2005 16:15:52 -0700 Subject: [PATCH] Update dontdiff Additions to the dontdiff list. Signed-off-by: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dontdiff | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 7c2496426ab9..9a33bb94f74f 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -27,6 +27,7 @@ *.so *.tex *.ver +*.xml *_MODULES *_vga16.c *cscope* @@ -110,6 +111,7 @@ mkdep mktables modpost modversions.h* +offsets.h oui.c* parse.c* parse.h* @@ -134,4 +136,5 @@ vmlinux-* vmlinux.lds vsyscall.lds wanxlfw.inc +uImage zImage -- cgit v1.2.1 From 02c30a84e6298b6b20a56f0896ac80b47839e134 Mon Sep 17 00:00:00 2001 From: Jesper Juhl Date: Thu, 5 May 2005 16:16:16 -0700 Subject: [PATCH] update Ross Biro bouncing email address Ross moved. Remove the bad email address so people will find the correct one in ./CREDITS. Signed-off-by: Jesper Juhl Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/networking/DLINK.txt | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/DLINK.txt b/Documentation/networking/DLINK.txt index 083d24752b83..55d24433d151 100644 --- a/Documentation/networking/DLINK.txt +++ b/Documentation/networking/DLINK.txt @@ -178,10 +178,9 @@ Released 1994-06-13 7. ACKNOWLEDGMENTS. These drivers wouldn't have been done without the base - (and support) from Ross Biro , - and D-Link Systems Inc. The driver relies upon GPL-ed - source from D-Link Systems Inc. and from Russel Nelson at - Crynwr Software . + (and support) from Ross Biro, and D-Link Systems Inc. + The driver relies upon GPL-ed source from D-Link Systems Inc. + and from Russel Nelson at Crynwr Software . Additional input also from: Donald Becker , Alan Cox -- cgit v1.2.1 From a1446c7fb7610a7b417d8b2fadb6751f86ee833e Mon Sep 17 00:00:00 2001 From: Jody McIntyre Date: Mon, 16 May 2005 21:53:59 -0700 Subject: [PATCH] ieee1394: feature removal notices drivers/ieee1394 feature removal notices: amdtp, cmp, legacy rawiso interface Signed-off-by: Jody McIntyre Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index d3c52dd24a2a..b9eb209318ab 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -63,3 +63,23 @@ Why: Outside of Linux, the only implementations of anything even people, who might be using implementations that I am not aware of, to adjust to this upcoming change. Who: Paul E. McKenney + +--------------------------- + +What: IEEE1394 Audio and Music Data Transmission Protocol driver, + Connection Management Procedures driver +When: November 2005 +Files: drivers/ieee1394/{amdtp,cmp}* +Why: These are incomplete, have never worked, and are better implemented + in userland via raw1394 (see http://freebob.sourceforge.net/ for + example.) +Who: Jody McIntyre + +--------------------------- + +What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN +When: November 2005 +Why: Deprecated in favour of the new ioctl-based rawiso interface, which is + more efficient. You should really be using libraw1394 for raw1394 + access anyway. +Who: Jody McIntyre -- cgit v1.2.1 From 2add87a95068d6457d4e5824d0417d39007665a4 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:10 -0700 Subject: [PATCH] dvb: b2c2/flexcop driver refactoring part 2: add modular Flexcop driver b2c2/flexcop driver refactoring to support PCI and USB based cards part 2: add modular Flexcop driver Signed-off-by: Patrick Boettcher Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/README.flexcop | 279 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 279 insertions(+) create mode 100644 Documentation/dvb/README.flexcop (limited to 'Documentation') diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop new file mode 100644 index 000000000000..9ec735714e43 --- /dev/null +++ b/Documentation/dvb/README.flexcop @@ -0,0 +1,279 @@ +This README escorted the skystar2-driver rewriting procedure. It describes the +state of the new flexcop-driver set and some internals are written down here +too. + +How to do something in here? +============================ + +make -f Makefile.t +make -C ../build-2.6 +./in.sh # load the drivers +./rm.sh # unload the drivers + +Please read this file, if you want to contribute. + +This document hopefully describes things about the flexcop and its +device-offsprings. Goal is to write a easy-to-write and easy-to-read set of +drivers based on the skystar2.c and other information. + +This directory is temporary. It is used for rewriting the skystar2.c and to +create shared code, which then can be used by the usb box as well. + +Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been +touched and rewritten. + +General coding processing +========================= + +We should proceed as follows (as long as no one complains): + +0) Think before start writing code! + +1) rewriting the skystar2.c with the help of the flexcop register descriptions +and splitting up the files to a pci-bus-part and a flexcop-part. +The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the +device-specific part and b2c2-flexcop.ko for the common flexcop-functions. + +2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c +and other pci drivers) + +3) make some beautification (see 'Improvements when rewriting (refactoring) is +done') + +4) Testing the new driver and maybe substitute the skystar2.c with it, to reach +a wider tester audience. + +5) creating an usb-bus-part using the already written flexcop code for the pci +card. + +Idea: create a kernel-object for the flexcop and export all important +functions. This option saves kernel-memory, but maybe a lot of functions have +to be exported to kernel namespace. + + +Current situation +================= + +0) Done :) +1) Done (some minor issues left) +2) Done +3) Not ready yet, more information is necessary +4) next to be done (see the table below) +5) USB driver is working (yes, there are some minor issues) + +What seems to be ready? +----------------------- + +1) Rewriting +1a) i2c is cut off from the flexcop-pci.c and seems to work +1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c +1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c +1e) eeprom (reading MAC address) +1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me)) +1f) misc. register accesses for reading parameters (e.g. resetting, revision) +1g) pid/mac filter (flexcop-hw-filter.c) +1i) dvb-stuff initialization in flexcop.c (done) +1h) dma stuff (now just using the size-irq, instead of all-together, to be done) +1j) remove flexcop initialization from flexcop-pci.c completely (done) +1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO') +1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from +non-static where possible, moved code to proper places) + +2) Search for errors in the leftover of flexcop-pci.c (partially done) +5a) add MAC address reading + +What to do in the near future? +-------------------------------------- +(no special order here) + + +5) USB driver +5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting) +5c) feeding of ISOC data to the software demux (format of the isochronous data +and speed optimization, no real error) + +Testing changes +--------------- + +O = item is working +P = item is partially working +X = item is not working +N = item does not apply here + = item need to be examined + + | PCI | USB +item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312 +-------+-------+---------+---------+-------+-------+---------+---------+------- +1a) | O | | | | N | N | N | N +1b) | O | | | | | | O | +1c) | N | N | | | N | N | O | +1d) | O | O +1e) | O | O +1f) | P +1g) | O +1h) | P | +1i) | O | N +1j) | O | N +1l) | O | N +2) | O | N +5a) | N | O +5b)* | N | +5c)* | N | + +* - not done yet + +Known bugs and problems and TODO +-------------------------------- + +1g/h/l) when pid filtering is enabled on the pci card + +DMA usage currently: + The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first + address and triggers an IRQ when it's full and starts writing to the second + address. When the second address is full, the IRQ is triggered again, and + the flexcop writes to first address again, and so on. + The buffersize of each address is currently 640*188 bytes. + + Problem is, when using hw-pid-filtering and doing some low-bandwidth + operation (like scanning) the buffers won't be filled enough to trigger + the IRQ. That's why: + + When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ + is triggered. Is the current write address of DMA1 different to the one + during the last IRQ, then the data is passed to the demuxer. + + There is an additional DMA-IRQ-method: packet count IRQ. This isn't + implemented correctly yet. + + The solution is to disable HW PID filtering, but I don't know how the DVB + API software demux behaves on slow systems with 45MBit/s TS. + +Solved bugs :) +-------------- +1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't +working) +SOLUTION: also index 0 was affected, because net_translation is done for +these indexes by default + +5b) isochronous transfer does only work in the first attempt (for the Sky2PC USB, +Air2PC is working) +SOLUTION: the flexcop was going asleep and never really woke up again (don't +know if this need fixes, see flexcop-fe-tuner.c:flexcop_sleep) + +Improvements when rewriting (refactoring) is done +================================================= + +- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control + (enable sleeping for other demods than dvb-s) +- add support for CableStar (stv0297 Microtune 203x/ALPS) + +Debugging +--------- +- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it + with this flexcop, this is important, because i2c is now using the + flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for + that, please tell us so). + +Everything which is identical in the following table, can be put into a common +flexcop-module. + + PCI USB +------------------------------------------------------------------------------- +Different: +Register access: accessing IO memory USB control message +I2C bus: I2C bus of the FC USB control message +Data transfer: DMA isochronous transfer +EEPROM transfer: through i2c bus not clear yet + +Identical: +Streaming: accessing registers +PID Filtering: accessing registers +Sram destinations: accessing registers +Tuner/Demod: I2C bus +DVB-stuff: can be written for common use + +Restrictions: +============ + +We need to create a bus-specific-struct and a flexcop-struct. + +bus-specific-struct: + +struct flexcop_pci +... + +struct flexcop_usb +... + + +struct flexcop_device { + void *bus_specific; /* container for bus-specific struct */ +... +} + +PCI i2c can read/write max 4 bytes at a time, USB can more + +Functions +========= + +Syntax +------ + +- Flexcop functions will be called "flexcop(_[a-z0-9]+)+" and exported as such + if needed. +- Flexcop-device functions will be called "flexcop_device(_[a-z0-9]+)+" and + exported as such if needed. +- Both will be compiled to b2c2-flexcop.ko and their source can be found in the + flexcop*.[hc] + +Callbacks and exports +--------------------- + +Bus-specific functions will be given as callbacks (function pointers) to the +flexcop-module. (within the flexcop_device-struct) + +Initialization process +====================== + +b2c2-flexcop.ko is loaded +b2c2-flexcop-.ko is loaded + +suppose a device is found: +malloc flexcop and the bus-specific variables (via flexcop_device_malloc) +fill the bus-specific variable +fill the flexcop variable (especially the bus-specific callbacks) +bus-specific initialization + - ... +do the common initialization (via flexcop_device_initialize) + - reset the card + - determine flexcop type (II, IIB, III) + - hw_filters (bus dependent) + - 0x204 + - set sram size + - create the dvb-stuff + - create i2c stuff + - frontend-initialization +done +bus specific: + - media_destination (this and the following 3 are bus specific) + - cai_dest + - cao_dest + - net_destination + +Bugs fixed while rewriting the driver +===================================== + +- EEPROM access (to read the MAC address) was fixed to death some time last + year. (fixed here and in skystar2.c) (Bjarne, this was the piece of code + (fix-chipaddr) we were wondering about) + + +Acknowledgements (just for the rewriting part) +================ + +Bjarne Steinsbo thought a lot in the first place of the pci part for this code +sharing idea. + +Andreas Oberritter for providing a recent PCI initialization template (pluto2.c). + +comments, critics and ideas to linux-dvb@linuxtv.org or patrick.boettcher@desy.de -- cgit v1.2.1 From 3ed8a31cb387b2ae3e4ca508f973931b61e6f6bd Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:13 -0700 Subject: [PATCH] dvb: flexcop: add acknowledgements add acknowledgements Signed-off-by: Patrick Boettcher Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/README.flexcop | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop index 9ec735714e43..8036faa1ead9 100644 --- a/Documentation/dvb/README.flexcop +++ b/Documentation/dvb/README.flexcop @@ -274,6 +274,11 @@ Acknowledgements (just for the rewriting part) Bjarne Steinsbo thought a lot in the first place of the pci part for this code sharing idea. -Andreas Oberritter for providing a recent PCI initialization template (pluto2.c). +Andreas Oberritter for providing a recent PCI initialization template +(pluto2.c). + +Boleslaw Ciesielski for pointing out a problem with firmware loader. + +Vadim Catana for correcting the USB transfer. comments, critics and ideas to linux-dvb@linuxtv.org or patrick.boettcher@desy.de -- cgit v1.2.1 From c6ee197ccf4af454638c044706f0ba7ef6c1bb76 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:17 -0700 Subject: [PATCH] dvb: flexcop: readme update readme update Signed-off-by: Patrick Boettcher Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/README.flexcop | 121 +++++++-------------------------------- 1 file changed, 21 insertions(+), 100 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop index 8036faa1ead9..a50c70f9ca72 100644 --- a/Documentation/dvb/README.flexcop +++ b/Documentation/dvb/README.flexcop @@ -2,26 +2,20 @@ This README escorted the skystar2-driver rewriting procedure. It describes the state of the new flexcop-driver set and some internals are written down here too. -How to do something in here? -============================ - -make -f Makefile.t -make -C ../build-2.6 -./in.sh # load the drivers -./rm.sh # unload the drivers - -Please read this file, if you want to contribute. - This document hopefully describes things about the flexcop and its -device-offsprings. Goal is to write a easy-to-write and easy-to-read set of +device-offsprings. Goal was to write an easy-to-write and easy-to-read set of drivers based on the skystar2.c and other information. -This directory is temporary. It is used for rewriting the skystar2.c and to -create shared code, which then can be used by the usb box as well. - Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been touched and rewritten. +History & News +============== + 2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana) + + + + General coding processing ========================= @@ -81,16 +75,15 @@ non-static where possible, moved code to proper places) 2) Search for errors in the leftover of flexcop-pci.c (partially done) 5a) add MAC address reading +5c) feeding of ISOC data to the software demux (format of the isochronous data +and speed optimization, no real error) (thanks to Vadim Catana) What to do in the near future? -------------------------------------- (no special order here) - 5) USB driver 5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting) -5c) feeding of ISOC data to the software demux (format of the isochronous data -and speed optimization, no real error) Testing changes --------------- @@ -118,7 +111,7 @@ item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312 2) | O | N 5a) | N | O 5b)* | N | -5c)* | N | +5c) | N | O * - not done yet @@ -155,17 +148,21 @@ working) SOLUTION: also index 0 was affected, because net_translation is done for these indexes by default -5b) isochronous transfer does only work in the first attempt (for the Sky2PC USB, -Air2PC is working) -SOLUTION: the flexcop was going asleep and never really woke up again (don't -know if this need fixes, see flexcop-fe-tuner.c:flexcop_sleep) +5b) isochronous transfer does only work in the first attempt (for the Sky2PC +USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really +woke up again (don't know if this need fixes, see +flexcop-fe-tuner.c:flexcop_sleep) + +NEWS: when the driver is loaded and unloaded and loaded again (w/o doing +anything in the while the driver is loaded the first time), no transfers take +place anymore. Improvements when rewriting (refactoring) is done ================================================= - split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control (enable sleeping for other demods than dvb-s) -- add support for CableStar (stv0297 Microtune 203x/ALPS) +- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA) Debugging --------- @@ -192,82 +189,6 @@ Sram destinations: accessing registers Tuner/Demod: I2C bus DVB-stuff: can be written for common use -Restrictions: -============ - -We need to create a bus-specific-struct and a flexcop-struct. - -bus-specific-struct: - -struct flexcop_pci -... - -struct flexcop_usb -... - - -struct flexcop_device { - void *bus_specific; /* container for bus-specific struct */ -... -} - -PCI i2c can read/write max 4 bytes at a time, USB can more - -Functions -========= - -Syntax ------- - -- Flexcop functions will be called "flexcop(_[a-z0-9]+)+" and exported as such - if needed. -- Flexcop-device functions will be called "flexcop_device(_[a-z0-9]+)+" and - exported as such if needed. -- Both will be compiled to b2c2-flexcop.ko and their source can be found in the - flexcop*.[hc] - -Callbacks and exports ---------------------- - -Bus-specific functions will be given as callbacks (function pointers) to the -flexcop-module. (within the flexcop_device-struct) - -Initialization process -====================== - -b2c2-flexcop.ko is loaded -b2c2-flexcop-.ko is loaded - -suppose a device is found: -malloc flexcop and the bus-specific variables (via flexcop_device_malloc) -fill the bus-specific variable -fill the flexcop variable (especially the bus-specific callbacks) -bus-specific initialization - - ... -do the common initialization (via flexcop_device_initialize) - - reset the card - - determine flexcop type (II, IIB, III) - - hw_filters (bus dependent) - - 0x204 - - set sram size - - create the dvb-stuff - - create i2c stuff - - frontend-initialization -done -bus specific: - - media_destination (this and the following 3 are bus specific) - - cai_dest - - cao_dest - - net_destination - -Bugs fixed while rewriting the driver -===================================== - -- EEPROM access (to read the MAC address) was fixed to death some time last - year. (fixed here and in skystar2.c) (Bjarne, this was the piece of code - (fix-chipaddr) we were wondering about) - - Acknowledgements (just for the rewriting part) ================ @@ -281,4 +202,4 @@ Boleslaw Ciesielski for pointing out a problem with firmware loader. Vadim Catana for correcting the USB transfer. -comments, critics and ideas to linux-dvb@linuxtv.org or patrick.boettcher@desy.de +comments, critics and ideas to linux-dvb@linuxtv.org. -- cgit v1.2.1 From 71e3420111530273f2b26fabfac4d021c2a2b79f Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:36 -0700 Subject: [PATCH] dvb: tda10046: support for different firmware versions added support for different tda10046 firmware versions. tested with v20, v21 and v25. (Andreas Oberritter) Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/get_dvb_firmware | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 3ffdcb394299..a750f0101d9d 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -107,7 +107,7 @@ sub tda10045 { sub tda10046 { my $sourcefile = "tt_budget_217g.zip"; my $url = "http://www.technotrend.de/new/217g/$sourcefile"; - my $hash = "a25b579e37109af60f4a36c37893957c"; + my $hash = "6a7e1e2f2644b162ff0502367553c72d"; my $outfile = "dvb-fe-tda10046.fw"; my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); @@ -115,7 +115,7 @@ sub tda10046 { wgetfile($sourcefile, $url); unzip($sourcefile, $tmpdir); - extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24479, "$tmpdir/fwtmp"); + extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478, "$tmpdir/fwtmp"); verify("$tmpdir/fwtmp", $hash); copy("$tmpdir/fwtmp", $outfile); -- cgit v1.2.1 From daeb6aa40be55b0750aea92dea78b8ebc40ca9a8 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:40 -0700 Subject: [PATCH] dvb: bt8xx: update documentation update bt8xx documentation (Uwe Bugla) Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/bt8xx.txt | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt index e3cacf4f2345..d84df8072d7e 100644 --- a/Documentation/dvb/bt8xx.txt +++ b/Documentation/dvb/bt8xx.txt @@ -17,34 +17,23 @@ Because of this, you need to enable "Device drivers" => "Multimedia devices" => "Video For Linux" => "BT848 Video For Linux" +Furthermore you need to enable +"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices" + => "DVB for Linux" "DVB Core Support" "Nebula/Pinnacle PCTV/TwinHan PCI Cards" + 2) Loading Modules ================== In general you need to load the bttv driver, which will handle the gpio and -i2c communication for us. Next you need the common dvb-bt8xx device driver -and one frontend driver. - -The bttv driver will HANG YOUR SYSTEM IF YOU DO NOT SPECIFY THE CORRECT -CARD ID! - -(If you don't get your card running and you suspect that the card id you're -using is wrong, have a look at "bttv-cards.c" for a list of possible card -ids.) - -Pay attention to failures when you load the frontend drivers -(e.g. dmesg, /var/log/messages). +i2c communication for us, plus the common dvb-bt8xx device driver. +The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and +TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver. 3a) Nebula / Pinnacle PCTV -------------------------- - $ modprobe bttv i2c_hw=1 card=0x68 - $ modprobe dvb-bt8xx - -For Nebula cards use the "nxt6000" frontend driver: - $ modprobe nxt6000 - -For Pinnacle PCTV cards use the "cx24110" frontend driver: - $ modprobe cx24110 + $ modprobe bttv (normally bttv is being loaded automatically by kmod) + $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading) 3b) TwinHan ----------- -- cgit v1.2.1 From 50b215a05878ce9636dace6cd21f7e91ff005058 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:41 -0700 Subject: [PATCH] dvb: DST: reorganize Twinhan DST driver to support CI - reorganize Twinhan DST driver to support CI - add support for more cards (Manu Abraham) Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/ci.txt | 219 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 Documentation/dvb/ci.txt (limited to 'Documentation') diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt new file mode 100644 index 000000000000..62e0701b542a --- /dev/null +++ b/Documentation/dvb/ci.txt @@ -0,0 +1,219 @@ +* For the user +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +NOTE: This document describes the usage of the high level CI API as +in accordance to the Linux DVB API. This is a not a documentation for the, +existing low level CI API. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To utilize the High Level CI capabilities, + +(1*) This point is valid only for the Twinhan/clones + For the Twinhan/Twinhan clones, the dst_ca module handles the CI + hardware handling.This module is loaded automatically if a CI + (Common Interface, that holds the CAM (Conditional Access Module) + is detected. + +(2) one requires a userspace application, ca_zap. This small userland + application is in charge of sending the descrambling related information + to the CAM. + +This application requires the following to function properly as of now. + + (a) Tune to a valid channel, with szap. + eg: $ szap -c channels.conf -r "TMC" -x + + (b) a channels.conf containing a valid PMT PID + + eg: TMC:11996:h:0:27500:278:512:650:321 + + here 278 is a valid PMT PID. the rest of the values are the + same ones that szap uses. + + (c) after running a szap, you have to run ca_zap, for the + descrambler to function, + + eg: $ ca_zap patched_channels.conf "TMC" + + The patched means a patch to apply to scan, such that scan can + generate a channels.conf_with pmt, which has this PMT PID info + (NOTE: szap cannot use this channels.conf with the PMT_PID) + + + (d) Hopeflly Enjoy your favourite subscribed channel as you do with + a FTA card. + +(3) Currently ca_zap, and dst_test, both are meant for demonstration + purposes only, they can become full fledged applications if necessary. + + +* Cards that fall in this category +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +At present the cards that fall in this category are the Twinhan and it's +clones, these cards are available as VVMER, Tomato, Hercules, Orange and +so on. + +* CI modules that are supported +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The CI module support is largely dependant upon the firmware on the cards +Some cards do support almost all of the available CI modules. There is +nothing much that can be done in order to make additional CI modules +working with these cards. + +Modules that have been tested by this driver at present are + +(1) Irdeto 1 and 2 from SCM +(2) Viaccess from SCM +(3) Dragoncam + +* The High level CI API +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* For the programmer +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +With the High Level CI approach any new card with almost any random +architecture can be implemented with this style, the definitions +insidethe switch statement can be easily adapted for any card, thereby +eliminating the need for any additional ioctls. + +The disadvantage is that the driver/hardware has to manage the rest. For +the application programmer it would be as simple as sending/receiving an +array to/from the CI ioctls as defined in the Linux DVB API. No changes +have been made in the API to accomodate this feature. + + +* Why the need for another CI interface ? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This is one of the most commonly asked question. Well a nice question. +Strictly speaking this is not a new interface. + +The CI interface is defined in the DVB API in ca.h as + +typedef struct ca_slot_info { + int num; /* slot number */ + + int type; /* CA interface this slot supports */ +#define CA_CI 1 /* CI high level interface */ +#define CA_CI_LINK 2 /* CI link layer level interface */ +#define CA_CI_PHYS 4 /* CI physical layer level interface */ +#define CA_DESCR 8 /* built-in descrambler */ +#define CA_SC 128 /* simple smart card interface */ + + unsigned int flags; +#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */ +#define CA_CI_MODULE_READY 2 +} ca_slot_info_t; + + + +This CI interface follows the CI high level interface, which is not +implemented by most applications. Hence this area is revisited. + +This CI interface is quite different in the case that it tries to +accomodate all other CI based devices, that fall into the other categories + +This means that this CI interface handles the EN50221 style tags in the +Application layer only and no session management is taken care of by the +application. The driver/hardware will take care of all that. + +This interface is purely an EN50221 interface exchanging APDU's. This +means that no session management, link layer or a transport layer do +exist in this case in the application to driver communication. It is +as simple as that. The driver/hardware has to take care of that. + + +With this High Level CI interface, the interface can be defined with the +regular ioctls. + +All these ioctls are also valid for the High level CI interface + +#define CA_RESET _IO('o', 128) +#define CA_GET_CAP _IOR('o', 129, ca_caps_t) +#define CA_GET_SLOT_INFO _IOR('o', 130, ca_slot_info_t) +#define CA_GET_DESCR_INFO _IOR('o', 131, ca_descr_info_t) +#define CA_GET_MSG _IOR('o', 132, ca_msg_t) +#define CA_SEND_MSG _IOW('o', 133, ca_msg_t) +#define CA_SET_DESCR _IOW('o', 134, ca_descr_t) +#define CA_SET_PID _IOW('o', 135, ca_pid_t) + + +On querying the device, the device yields information thus + +CA_GET_SLOT_INFO +---------------------------- +Command = [info] +APP: Number=[1] +APP: Type=[1] +APP: flags=[1] +APP: CI High level interface +APP: CA/CI Module Present + +CA_GET_CAP +---------------------------- +Command = [caps] +APP: Slots=[1] +APP: Type=[1] +APP: Descrambler keys=[16] +APP: Type=[1] + +CA_SEND_MSG +---------------------------- +Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1] +Found CA descriptor @ program level + +(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)] +(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)] +ca_message length is 25 (0x19) bytes +EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00] + + +Not all ioctl's are implemented in the driver from the API, the other +features of the hardware that cannot be implemented by the API are achieved +using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is +used to exchange the data to maintain compatibility with other hardware. + + +/* a message to/from a CI-CAM */ +typedef struct ca_msg { + unsigned int index; + unsigned int type; + unsigned int length; + unsigned char msg[256]; +} ca_msg_t; + + +The flow of data can be described thus, + + + + + + App (User) + ----- + parse + | + | + v + en50221 APDU (package) + -------------------------------------- + | | | High Level CI driver + | | | + | v | + | en50221 APDU (unpackage) | + | | | + | | | + | v | + | sanity checks | + | | | + | | | + | v | + | do (H/W dep) | + -------------------------------------- + | Hardware + | + v + + + + +The High Level CI interface uses the EN50221 DVB standard, following a +standard ensures futureproofness. -- cgit v1.2.1 From df481ae59074756f1d0b2712d8b3fe8d04eb16c1 Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Mon, 16 May 2005 21:54:45 -0700 Subject: [PATCH] dvb: bt8xx: updated documentation updated documentation (Manu Abraham) Signed-off-by: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/dvb/bt8xx.txt | 42 ++++++++++++++++-------------------------- 1 file changed, 16 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt index d84df8072d7e..d64430bf4bb6 100644 --- a/Documentation/dvb/bt8xx.txt +++ b/Documentation/dvb/bt8xx.txt @@ -35,45 +35,35 @@ TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver. $ modprobe bttv (normally bttv is being loaded automatically by kmod) $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading) -3b) TwinHan ------------ + +3b) TwinHan and Clones +-------------------------- $ modprobe bttv i2c_hw=1 card=0x71 $ modprobe dvb-bt8xx $ modprobe dst -The value 0x71 will override the PCI type detection for dvb-bt8xx, which -is necessary for TwinHan cards.# +The value 0x71 will override the PCI type detection for dvb-bt8xx, +which is necessary for TwinHan cards. -If you're having an older card (blue color circuit) and card=0x71 locks your -machine, try using 0x68, too. If that does not work, ask on the DVB mailing list. +If you're having an older card (blue color circuit) and card=0x71 locks +your machine, try using 0x68, too. If that does not work, ask on the +mailing list. -The DST module takes a couple of useful parameters, in case the -dst drivers fails to detect your type of card correctly. +The DST module takes a couple of useful parameters. -dst_type takes values 0 (satellite), 1 (terrestial TV), 2 (cable). +verbose takes values 0 to 5. These values control the verbosity level. -dst_type_flags takes bit combined values: -1 = new tuner type packets. You can use this if your card is detected - and you have debug and you continually see the tuner packets not - working (make sure not a basic problem like dish alignment etc.) +debug takes values 0 and 1. You can either disable or enable debugging. -2 = TS 204. If your card tunes OK, but the picture is terrible, seemingly - breaking up in one half continually, and crc fails a lot, then - this is worth a try (or trying to turn off) +dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card. +0x20 means it has a Conditional Access slot. -4 = has symdiv. Some cards, mostly without new tuner packets, require - a symbol division algorithm. Doesn't apply to terrestial TV. - -You can also specify a value to have the autodetected values turned off -(e.g. 0). The autodected values are determined bythe cards 'response +The autodected values are determined bythe cards 'response string' which you can see in your logs e.g. -dst_check_ci: recognize DST-MOT - -or +dst_get_device_id: Recognise [DSTMCI] -dst_check_ci: unable to recognize DSTXCI or STXCI -- -Authors: Richard Walker, Jamie Honan, Michael Hunold +Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham -- cgit v1.2.1 From 0b405a0f7e4d4d18fd1fe46ddf5ff465443036ab Mon Sep 17 00:00:00 2001 From: David Brownell Date: Thu, 12 May 2005 12:06:27 -0700 Subject: [PATCH] Driver Core: remove driver model detach_state The driver model has a "detach_state" mechanism that: - Has never been used by any in-kernel drive; - Is superfluous, since driver remove() methods can do the same thing; - Became buggy when the suspend() parameter changed semantics and type; - Could self-deadlock when called from certain suspend contexts; - Is effectively wasted documentation, object code, and headspace. This removes that "detach_state" mechanism; net code shrink, as well as a per-device saving in the driver model and sysfs. Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman --- Documentation/filesystems/sysfs-pci.txt | 6 ++---- Documentation/power/devices.txt | 21 --------------------- Documentation/powerpc/hvcs.txt | 4 ++-- 3 files changed, 4 insertions(+), 27 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt index e97d024eae77..988a62fae11f 100644 --- a/Documentation/filesystems/sysfs-pci.txt +++ b/Documentation/filesystems/sysfs-pci.txt @@ -7,7 +7,6 @@ that support it. For example, a given bus might look like this: |-- 0000:17:00.0 | |-- class | |-- config - | |-- detach_state | |-- device | |-- irq | |-- local_cpus @@ -19,7 +18,7 @@ that support it. For example, a given bus might look like this: | |-- subsystem_device | |-- subsystem_vendor | `-- vendor - `-- detach_state + `-- ... The topmost element describes the PCI domain and bus number. In this case, the domain number is 0000 and the bus number is 17 (both values are in hex). @@ -31,7 +30,6 @@ files, each with their own function. ---- -------- class PCI class (ascii, ro) config PCI config space (binary, rw) - detach_state connection status (bool, rw) device PCI device (ascii, ro) irq IRQ number (ascii, ro) local_cpus nearby CPU mask (cpumask, ro) @@ -85,4 +83,4 @@ useful return codes should be provided. Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms wishing to support legacy functionality should define it and provide -pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. \ No newline at end of file +pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 5d4ae9a39f1d..f987afe43e28 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -207,27 +207,6 @@ SYSTEM_SHUTDOWN, I do not understand this one too much. probably event #READY_AFTER_RESUME # -Driver Detach Power Management - -The kernel now supports the ability to place a device in a low-power -state when it is detached from its driver, which happens when its -module is removed. - -Each device contains a 'detach_state' file in its sysfs directory -which can be used to control this state. Reading from this file -displays what the current detach state is set to. This is 0 (On) by -default. A user may write a positive integer value to this file in the -range of 1-4 inclusive. - -A value of 1-3 will indicate the device should be placed in that -low-power state, which will cause ->suspend() to be called for that -device. A value of 4 indicates that the device should be shutdown, so -->shutdown() will be called for that device. - -The driver is responsible for reinitializing the device when the -module is re-inserted during it's ->probe() (or equivalent) method. -The driver core will not call any extra functions when binding the -device to the driver. pm_message_t meaning diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt index c0a62e116e6e..dca75cbda6f8 100644 --- a/Documentation/powerpc/hvcs.txt +++ b/Documentation/powerpc/hvcs.txt @@ -347,8 +347,8 @@ address that is created by firmware. An example vty-server sysfs entry looks like the following: Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls - . current_vty devspec name partner_vtys - .. detach_state index partner_clcs vterm_state + . current_vty devspec name partner_vtys + .. index partner_clcs vterm_state Each entry is provided, by default with a "name" attribute. Reading the "name" attribute will reveal the device type as shown in the following -- cgit v1.2.1 From b39c4fab259b216148e705344a892c96efe1946d Mon Sep 17 00:00:00 2001 From: Paul Jackson Date: Fri, 20 May 2005 13:59:15 -0700 Subject: [PATCH] cpusets+hotplug+preepmt broken This patch removes the entwining of cpusets and hotplug code in the "No more Mr. Nice Guy" case of sched.c move_task_off_dead_cpu(). Since the hotplug code is holding a spinlock at this point, we cannot take the cpuset semaphore, cpuset_sem, as would seem to be required either to update the tasks cpuset, or to scan up the nested cpuset chain, looking for the nearest cpuset ancestor that still has some CPUs that are online. So we just punt and blast the tasks cpus_allowed with all bits allowed. This reverts these lines of code to what they were before the cpuset patch. And it updates the cpuset Doc file, to match. The one known alternative to this that seems to work came from Dinakar Guniguntala, and required the hotplug code to take the cpuset_sem semaphore much earlier in its processing. So far as we know, the increased locking entanglement between cpusets and hot plug of this alternative approach is not worth doing in this case. Signed-off-by: Paul Jackson Acked-by: Nathan Lynch Acked-by: Dinakar Guniguntala Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cpusets.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 1ad26d2c20ae..2f8f24eaefd9 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt @@ -252,8 +252,7 @@ in a tasks processor placement. There is an exception to the above. If hotplug funtionality is used to remove all the CPUs that are currently assigned to a cpuset, then the kernel will automatically update the cpus_allowed of all -tasks attached to CPUs in that cpuset with the online CPUs of the -nearest parent cpuset that still has some CPUs online. When memory +tasks attached to CPUs in that cpuset to allow all CPUs. When memory hotplug functionality for removing Memory Nodes is available, a similar exception is expected to apply there as well. In general, the kernel prefers to violate cpuset placement, over starving a task -- cgit v1.2.1 From 14d98cad82b78956957e95567b8b5fb38ec5859f Mon Sep 17 00:00:00 2001 From: Andi Kleen Date: Fri, 20 May 2005 14:27:59 -0700 Subject: [PATCH] x86_64: Add option to disable timer check This works around the too fast timer seen on some ATI boards. I don't feel confident enough about it yet to enable it by default, but give users the option. Patch and debugging from Christopher Allen Wing , with minor tweaks (renamed the option and documented it) Signed-off-by: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/x86_64/boot-options.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index 44b6eea60ece..b9e6be00cadf 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt @@ -25,6 +25,9 @@ APICs noapictimer Don't set up the APIC timer + no_timer_check Don't check the IO-APIC timer. This can work around + problems with incorrect timer initialization on some boards. + Early Console syntax: earlyprintk=vga -- cgit v1.2.1