Re: Re: [Kernel-bugs] h5400 patch - merge h5400_bt.c back to h5400.c

Hello,

On Mon, 18 Feb 2008 23:55:29 +0100
"Michal Panczyk" <mpanczyk_at_gmail.com> wrote:

> Paul ....
>

> Or maybe should I forget about the whole BT stuff for now and
> concentrate on more important things .... ?

I'd suggest to lead things to logical end. That should be compatible
with your own aims too - you want not just do some cleanup to source,
but make sure that h5000 was well supported and maintained in OE, right?

> >>Bottom line: it's worth to detect HWUART, but fortunately it's as
> >>easy as checking if /dev/ttyS3 exists and if not, falling back
> >>to /dev/ttyS1.
>
> Both /dev/ttyS1 and /dev/ttyS3 existed in all the images that I have
> played with. But only one of the gave positive response to :
> /sbin/hciattach /dev/ttySX any 921600

Was it with older images, before your changes? If so, then yes, you
added supported for using both ports with your patches. So, just test
if that works as expected ;-).

>
> Sometimes, depending on the image, it was 1 sometimes it was 3.

This is *very* strange ;-). Let's attribute it to lack of formal
testing, ok?

> There
> was no possibility to check if only one of them exist....

Ok, few words about how this works. There're no actually devices in
OE images (or to be more exact, there're some static once, but only
minimal set required for initial boot stage). The devices you see are
created dynamically by udev based on info exported by the kernel. Have
a look at arch/arm/mach-pxa/generic.c:655:

        /* Only add HWUART for PXA255/26x; PXA210/250/27x do not have
it. */ cpuid = read_cpuid(CPUID_ID);
        if (((cpuid >> 4) & 0xfff) == 0x2d0 ||
            ((cpuid >> 4) & 0xfff) == 0x290)
                ret = platform_device_register(&hwuart_device);

(So, extra detail: not even PXA27x has HWUART!)

So, based on that, ttyS3 internal kernel device will be registered only
for PXA255/26x, on other CPUs udev will never see it and never will
create /dev/ttyS3 device node in filesystem. So, all stuff as I
described should work. If it won't, there's bug elsewhere, and we will
find it too ;-).

>
>
> > > As you see in another message, starting to think about the stuff
> > together is the best incentive to brainstorm the issue ;-). So, we
> > should use ttyS3 when it is available.
> >
> I like brainstorming too..... I have one more coming to kernel-bugs in
> few minutes ....
> But getting back to the subject - as it goes for me - I can get used
> to checking on what ttySx bluetooth shows up - but I guess blueprobe
> is not that flexible....

The talk is exactly about teaching blueprobe do the right thing ;-).

> I was about to provide a patch to OE but I
> got lost ....
> Shoul I/we think of better solution than blueprobe does :
>
> module_id() {
> awk 'BEGIN { FS=": " } /Hardware/ { print $2 } ' </proc/cpuinfo
> }
> and then assign the ttySx.

As usual, a patch should be optimized by criteria to be as minimal as
required to do what it is intended for. So no, we don't want to change
that.

>
> Should there be some extra code like for h2200 versions (Zeevo and CSR
> )?

Yes, exactly.

> Or should there be a command forcing the use of HWUART ?

We cannot force its use - it doesn't exist in h5400, period! ;-)

So, my try on that is:

--- blueprobe.init.1 2007-11-12 20:43:46.000000000 +0200
+++ blueprobe.init 2008-02-20 00:29:44.000000000 +0200
@@ -46,7 +46,11 @@
         ;;
     "HP iPAQ H5400")
         BLUETOOTH=yes
- PORT=/dev/ttyS3
+ if [ -a /dev/ttyS3 ]; then
+ PORT=/dev/ttyS3
+ else
+ PORT=/dev/ttyS1
+ fi
         SPEED=921600
         PROTO=any
         PROBE=yes

That's my little gift, you'd still need to provide complete patch for
OE ;-).

>
>
> Cheers
>
> Michal Panczyk

-- 
Best regards,
 Paul                          mailto:pmiscml_at_gmail.com