Re: com(4) and LSI bug workaround
Hi! From: Izumi Tsutsui Date: Wed, 2 Oct 2013 22:29:52 +0900 >> > First of all, your guess has no evidence and actually it seems incorrect. >> > >> > There are some articles that indicate it's a documented future: >> > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/203948 >> >> Yes. >> Although that those are not the things for 16750 understood me, I did >> not know that it was IP of Synopsys DesignWare. And although his mail >> does not have a corroboration which is a fact, either, probably it is >> right. > > Then can you revert your changes? Is it better to revirt right now? >> > Isn't it much simpler and explicit to call such a MD workaround >> > function directly from comintr() and wrap those blocks with >> > #if COM_XXXMDname > 0 / #endif with "needs-flag" declaration >> > in the config(9) file? >> >> I think that I should check not by "needs-flag" but by COM_TYPE_. >> Since ARMADAXP has some PCIe, com should be able to be attached there. > > What makes you think the com at PCIe will also have the same quirk? > > If the quirks is not chip specific, the workaround function should > also be in the MI com.c, then no need to wrap them with #ifdef. > >> COM_TYPE_APBUART or COM_TYPE_SNPS or ... ? > > In ARMADAXP case I don't see any reason to put #ifdef at all. > > If IIR_BUSY is returned we should always check the USR register. > It's no worth to have a separate mvuart_armadaxp_workaround() function > you suggested. Please let me confirm. Is it wrong although I understood that you desired "#ifdef ARMADAXP ... #endif"? I desire a method of setting COM_TYPE_ to sc_type like OMAP and PXA2x0. it is like COM_TYPE_APBUART. # It may be better for the name of sinopsys to enter. COM_TYPE_SNPS? And actual processing will move to com.c. This is because it is not dependent on ARMADAXP. This understands that you also agree. Thanks, -- kiyohara
Re: com(4) and LSI bug workaround
Hi! From: Izumi Tsutsui Date: Tue, 1 Oct 2013 21:19:01 +0900 > First of all, your guess has no evidence and actually it seems incorrect. > > There are some articles that indicate it's a documented future: > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/203948 Yes. Although that those are not the things for 16750 understood me, I did not know that it was IP of Synopsys DesignWare. And although his mail does not have a corroboration which is a fact, either, probably it is right. > Isn't it much simpler and explicit to call such a MD workaround > function directly from comintr() and wrap those blocks with > #if COM_XXXMDname > 0 / #endif with "needs-flag" declaration > in the config(9) file? I think that I should check not by "needs-flag" but by COM_TYPE_. Since ARMADAXP has some PCIe, com should be able to be attached there. COM_TYPE_APBUART or COM_TYPE_SNPS or ... ? Thanks, -- kiyohara
Re: com(4) and LSI bug workaround
Hi!
From: Izumi Tsutsui
Date: Mon, 30 Sep 2013 23:02:17 +0900
>> > It looks meaningless that the (*sc_vendor_workaround)() hook function
>> > is inside of MD if (sc->sc_type == COM_TYPE_ARMADAXP) statement.
>> >
>> > Isn't it simpler to prepare a MD hook function that returns
>> > (possible pre-processed) IIR register value that can be used
>> > to check if the interrupt for the device is pending or not?
>>
>> I performed operation to a com register into com.c.
>> I think that it is not so brief to return the value of both IIR(u_char)
>> and an error moreover.
>
> Sorry I don't understand what you mean.
>
> Do you think the name of "sc_vendor_workaround" is really appropriate
> for the function that is called only in COM_TYPE_ARMADAXP case?
I apologize for the first explanation having been lacking.
I consider calling this method for evasion processing of the problem
of LSI. Only ARMADAXP uses it only in comintr() now.
However, this may be used during the processing from which LSI besides
the future differs.
In such a case, is a different method from this prepared?
For example
void *sc_vendor_workaround{1,2,3...}(void);
We are evaluating the conditions of COM_TYPE_ARMADAXP and can cope with
it by one method.
When it depends especially, LSI with much fault may come out to a market.
In this case, it may be able to be coped with by making a fault number
(tag ?) and a reason into an argument, and calling a method.
void *sc_vendor_workaround(int reason, int value);
> The requirement in the MI interrupt handler is just
> "whether interrupts are pending or not," isn't it?
Yes, it is.
Thanks,
--
kiyohara
Re: com(4) and LSI bug workaround
Hi! From: Izumi Tsutsui Date: Sat, 28 Sep 2013 17:24:27 +0900 > It looks meaningless that the (*sc_vendor_workaround)() hook function > is inside of MD if (sc->sc_type == COM_TYPE_ARMADAXP) statement. > > Isn't it simpler to prepare a MD hook function that returns > (possible pre-processed) IIR register value that can be used > to check if the interrupt for the device is pending or not? I performed operation to a com register into com.c. I think that it is not so brief to return the value of both IIR(u_char) and an error moreover. Thanks, -- kiyohara
com(4) and LSI bug workaround
Hi!
I mistook commit the other day.
http://mail-index.NetBSD.org/source-changes/2013/09/01/msg047120.html
Although the processing for this ARMADAXP was moved to com_mv.c, IIR of
com is reset by reading. That is, since IIR was read by mvuart_intr(),
IIR was not able to be correctly read by comintr().
I would like to add the next member to com_softc, in order to solve this
problem.
/* : vendor workaround functions */
int (*sc_vendor_workaround)(struct com_softc *);
Processing which avoids BUSY of ARMADAXP is performed by calling this
from comintr() at the time of COM_TYPE_ARMADAXP. Probably addition of
this member will consume many several bytes of memories by almost all
your machines.
However, no machines other than ARMADAXP call this. I would like to
merge this correction.
Please let me know your opinion.
Probably, it will be more desirable for this member to add reasoncode
and value of int to an argument for other LSI with fault.
int (*sc_vendor_workaround)(struct com_softc *, int reasoncode, int val);
Thanks,
--
kiyohara
Index: ic/com.c
===
RCS file: /cvsroot/src/sys/dev/ic/com.c,v
retrieving revision 1.314
diff -u -r1.314 com.c
--- ic/com.c 1 Sep 2013 04:58:15 - 1.314
+++ ic/com.c 24 Sep 2013 11:00:02 -
@@ -1938,6 +1938,18 @@
mutex_spin_enter(&sc->sc_lock);
iir = CSR_READ_1(regsp, COM_REG_IIR);
+ if (sc->sc_type == COM_TYPE_ARMADAXP) {
+ if ((iir & IIR_BUSY) == IIR_BUSY) {
+ if (sc->sc_vendor_workaround != NULL &&
+ sc->sc_vendor_workaround(sc) != 0) {
+mutex_spin_exit(&sc->sc_lock);
+return (0);
+ }
+ CSR_WRITE_1(regsp, COM_REG_LCR, sc->sc_lcr);
+ iir = CSR_READ_1(regsp, COM_REG_IIR);
+ }
+ }
+
if (ISSET(iir, IIR_NOPEND)) {
mutex_spin_exit(&sc->sc_lock);
return (0);
Index: ic/comvar.h
===
RCS file: /cvsroot/src/sys/dev/ic/comvar.h,v
retrieving revision 1.76
diff -u -r1.76 comvar.h
--- ic/comvar.h 1 Sep 2013 04:51:24 - 1.76
+++ ic/comvar.h 24 Sep 2013 11:00:02 -
@@ -226,6 +226,9 @@
void (*disable)(struct com_softc *);
int enabled;
+ /* : vendor workaround functions */
+ int (*sc_vendor_workaround)(struct com_softc *);
+
struct pps_state sc_pps_state; /* pps state */
#ifdef RND_COM
Index: marvell/com_mv.c
===
RCS file: /cvsroot/src/sys/dev/marvell/com_mv.c,v
retrieving revision 1.6
diff -u -r1.6 com_mv.c
--- marvell/com_mv.c 1 Sep 2013 04:51:24 - 1.6
+++ marvell/com_mv.c 24 Sep 2013 11:00:04 -
@@ -53,7 +53,7 @@
static int mvuart_match(device_t, struct cfdata *, void *);
static void mvuart_attach(device_t, device_t, void *);
-static int mvuart_intr(void *);
+static int mvuart_armadaxp_workaround(struct com_softc *);
CFATTACH_DECL_NEW(mvuart_gt, sizeof(struct com_softc),
mvuart_match, mvuart_attach, NULL, NULL);
@@ -88,12 +88,14 @@
struct {
int model;
int type;
+ int (*workaround)(struct com_softc *);
} mvuart_extensions[] = {
- { MARVELL_ARMADAXP_MV78130, COM_TYPE_ARMADAXP },
- { MARVELL_ARMADAXP_MV78160, COM_TYPE_ARMADAXP },
- { MARVELL_ARMADAXP_MV78230, COM_TYPE_ARMADAXP },
- { MARVELL_ARMADAXP_MV78260, COM_TYPE_ARMADAXP },
- { MARVELL_ARMADAXP_MV78460, COM_TYPE_ARMADAXP },
+#define MV(x) MARVELL_ ## x
+ { MV(ARMADAXP_MV78130), COM_TYPE_ARMADAXP, mvuart_armadaxp_workaround },
+ { MV(ARMADAXP_MV78160), COM_TYPE_ARMADAXP, mvuart_armadaxp_workaround },
+ { MV(ARMADAXP_MV78230), COM_TYPE_ARMADAXP, mvuart_armadaxp_workaround },
+ { MV(ARMADAXP_MV78260), COM_TYPE_ARMADAXP, mvuart_armadaxp_workaround },
+ { MV(ARMADAXP_MV78460), COM_TYPE_ARMADAXP, mvuart_armadaxp_workaround },
};
/* ARGSUSED */
@@ -157,56 +159,40 @@
for (i = 0; i < __arraycount(mvuart_extensions); i++)
if (mva->mva_model == mvuart_extensions[i].model) {
sc->sc_type = mvuart_extensions[i].type;
+ sc->sc_vendor_workaround =
+ mvuart_extensions[i].workaround;
break;
}
com_attach_subr(sc);
- if (sc->sc_type == COM_TYPE_ARMADAXP)
- marvell_intr_establish(mva->mva_irq, IPL_SERIAL,
- mvuart_intr, sc);
- else
- marvell_intr_establish(mva->mva_irq, IPL_SERIAL, comintr, sc);
+ marvell_intr_establish(mva->mva_irq, IPL_SERIAL, comintr, sc);
}
static int
-mvuart_intr(void *arg)
+mvuart_armadaxp_workaround(struct com_softc *sc)
{
- struct com_softc *sc = arg;
struct com_regs *regsp = &sc->sc_regs;
int timeout;
- uint8_t iir, v;
+ uint8_t v;
- if (!device_is_active(sc->sc_dev))
- return 0;
-
- KASSERT(regsp != NULL);
-
- mutex_spin_enter(&sc->sc_lock);
- iir = CSR_READ_1(regsp, COM_REG_IIR);
- if ((iir & IIR_BUSY) == IIR_BUSY) {
- /*
- * X: What is this? I don't found in Marvell datasheet.
- *Maybe workaround for BUG in UART.
- */
+ /*
+ * X: What is this? I don't found in Marvell datasheet.
+ *Maybe workaround for BUG in UART.
+ */
+ v = bus_space_read_1(regsp->
Re: pchb@acpi again
Hi!
From: Chuck Silvers
Date: Sun, 5 May 2013 18:54:54 -0700
> On Mon, Apr 22, 2013 at 09:21:50PM +0900, KIYOHARA Takashi wrote:
> > Hi!
> >
> >
> > From: Chuck Silvers
> > Date: Sun, 21 Apr 2013 08:33:24 -0700
> >
> > > On Mon, Apr 15, 2013 at 09:14:51PM +0900, KIYOHARA Takashi wrote:
> > > > > > > in acpi_pci.c, why do you need to skip the check for
> > > > > > > ACPI_VALID_ADR?
> > > > > > > does the ACPI info on ia64 not have that flag set when it should?
> > > > > >
> > > > > > In my memory, YES. :-<
> > > > > > But I can't access to my ia64 now. I will try and check at next
> > > > > > weekend.
> > > > >
> > > > > In my ia64(zx6000), it looked that AcpiNsSearchAndEnter() returned
> > > > > AE_NOT_FOUND.
> > > > > How enable ACPI_DEBUG_PRINT or others many print?
> > > >
> > > > I look this messages on my ia64. (e.g. PCI0)
> > > >
> > > > _ADR Not found in 0xe0003f9dd1e8 [Not adding]
> > > > Name [_ADR] not found in scope [PCI0] 0xe0003f9dd1e8
> > > >
> > > >
> > > > I think that no this problem crops up by all ia64 machines. Do you know
> > > > the better evasion method?
> > > > # Can I fixup by acpi_md_callback()? I look and find that now.
> > >
> > > I was thinking that acpi_md_callback() was called before the code where
> > > you
> > > removed the check for ACPI_VALID_ADR, so you could have acpi_md_callback()
> > > walk through the device tree constructed by acpi_build_tree() and set
> > > ACPI_VALID_ADR on any devices where it was missing, as well as
> > > initializing
> > > ad->ad_devinfo->Address. but the check for ACPI_VALID_ADR in question is
> > > in
> > > acpi_pcidev_scan(), which is called at the end of acpi_build_tree(),
> > > so it's actually called before acpi_md_callback() is called.
> > >
> > > it happens that ad->ad_devinfo->Address will be zero if ACPI_VALID_ADR
> > > isn't set, I guess that value is actually correct on your system?
> >
> > By my ia64 machine, it cannot ensure that address of pchb is right.
> > I checked the boot log(typescript) of FreeBSD and Debian.
> > FreeBSD had returned AE_NOT_FOUND. The value of device and function
> > was not displayed in Linux.
> >
> >
> > http://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript.FreeBSD_ia64
> > http://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript.ia64.debian
>
> if you don't know the right value for ad->ad_devinfo->Address should be,
> how would you know how to set ap->ap_device and ap->ap_function?
> setting those two fields are what ad->ad_devinfo->Address is used for
> in acpi_pcidev_scan(). if you know how you should set those fields,
> then I think you should be able to just initialize ad->ad_devinfo->Address
> and set ACPI_VALID_ADR in ad->ad_devinfo->Valid.
>
> I looked at the diff you sent later, but it wasn't clear how that
> was supposed to work. could you also send the ia64 version of that
> new callback so we can see how the MI and MD parts would fit together?
I add this change to my ia64.
Index: acpi_machdep.c
===
RCS file: /cvsroot/src/sys/arch/ia64/acpi/acpi_machdep.c,v
retrieving revision 1.6
diff -u -r1.6 acpi_machdep.c
--- acpi_machdep.c 23 Sep 2012 00:31:05 - 1.6
+++ acpi_machdep.c 8 May 2013 11:49:39 -
@@ -195,6 +195,20 @@
}
int
+acpi_node_md_callback(struct acpi_devnode *ad)
+{
+
+ if (ad->ad_devinfo->Flags & ACPI_PCI_ROOT_BRIDGE)
+ if (!(ad->ad_devinfo->Valid & ACPI_VALID_ADR)) {
+ /* Fixup no _ADR */
+ ad->ad_devinfo->Valid |= ACPI_VALID_ADR;
+ return 1;
+ }
+
+ return 0;
+}
+
+int
acpi_md_sleep(int state)
{
printf("%s: not yet...\n", __func__);
Thanks,
--
kiyohara
Re: pchb@acpi again
Hi! Chuck,
From: KIYOHARA Takashi
Date: Mon, 22 Apr 2013 21:21:50 +0900 (JST)
> > so I guess the easiest thing for now would be to add another MD callback
> > that is called from acpi_build_tree() just before the call to
> > acpi_pcidev_scan(). in that callback you could adjust ACPI_VALID_ADR
> > and ad->ad_devinfo->Address as I was originally thinking.
> > once we eventually migrate more of the logic from x86/mpacpi.c
> > to dev/acpi/*.c, maybe we'll find that we can merge some of these
> > callbacks.
>
> I wish to call each device(or node?), like acpi_device_md_callback().
> Please add new callback.
I have wrote new patch.
It call acpi_node_md_callback() and retry.
Thanks,
--
kiyohara
Index: acpi_pci.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpi_pci.c,v
retrieving revision 1.18
diff -u -r1.18 acpi_pci.c
--- acpi_pci.c 31 Dec 2010 10:56:39 - 1.18
+++ acpi_pci.c 27 Apr 2013 07:21:35 -
@@ -45,6 +45,8 @@
#include
#include
+#include
+
#include "locators.h"
#define _COMPONENT ACPI_BUS_COMPONENT
@@ -175,6 +177,9 @@
ACPI_STATUS rv;
ad->ad_pciinfo = NULL;
+ ap = NULL;
+
+retry:
/*
* We attach PCI information only to devices that are present,
@@ -189,11 +194,11 @@
goto rec;
if (ad->ad_devinfo->Flags & ACPI_PCI_ROOT_BRIDGE) {
-
- ap = kmem_zalloc(sizeof(*ap), KM_SLEEP);
-
- if (ap == NULL)
- return AE_NO_MEMORY;
+ if (ap == NULL) {
+ ap = kmem_zalloc(sizeof(*ap), KM_SLEEP);
+ if (ap == NULL)
+ return AE_NO_MEMORY;
+ }
/*
* If no _SEG exist, all PCI bus segments are assumed
@@ -224,6 +229,7 @@
}
ap->ap_flags |= ACPI_PCI_INFO_BRIDGE;
+ ad->ad_pciinfo = ap;
/*
* This ACPI node denotes a PCI root bridge, but it may also
@@ -242,11 +248,8 @@
"invalid PCI address for %s\n",
ad->ad_name);
else
ap->ap_flags |= ACPI_PCI_INFO_DEVICE;
+ goto rec;
}
-
- ad->ad_pciinfo = ap;
-
- goto rec;
}
if ((ad->ad_parent != NULL) &&
@@ -259,10 +262,11 @@
* bridge. We have the same PCI segment number, and
* our bus number is its downstream bus number.
*/
- ap = kmem_zalloc(sizeof(*ap), KM_SLEEP);
-
- if (ap == NULL)
- return AE_NO_MEMORY;
+ if (ap == NULL) {
+ ap = kmem_zalloc(sizeof(*ap), KM_SLEEP);
+ if (ap == NULL)
+ return AE_NO_MEMORY;
+ }
ap->ap_segment = ad->ad_parent->ad_pciinfo->ap_segment;
ap->ap_bus = ad->ad_parent->ad_pciinfo->ap_downbus;
@@ -279,6 +283,7 @@
}
ap->ap_flags |= ACPI_PCI_INFO_DEVICE;
+ ad->ad_pciinfo = ap;
if (ap->ap_function == 0x) {
/*
@@ -295,12 +300,12 @@
if (ACPI_SUCCESS(rv))
ap->ap_flags |= ACPI_PCI_INFO_BRIDGE;
- }
- ad->ad_pciinfo = ap;
-
- goto rec;
+ goto rec;
+ }
}
+ if (acpi_node_md_callback(ad) != 0)
+ goto retry;
rec:
SIMPLEQ_FOREACH(child, &ad->ad_child_head, ad_child_list) {
Re: pchb@acpi again
Hi! From: Chuck Silvers Date: Sun, 21 Apr 2013 08:33:24 -0700 > On Mon, Apr 15, 2013 at 09:14:51PM +0900, KIYOHARA Takashi wrote: > > > > > in acpi_pci.c, why do you need to skip the check for ACPI_VALID_ADR? > > > > > does the ACPI info on ia64 not have that flag set when it should? > > > > > > > > In my memory, YES. :-< > > > > But I can't access to my ia64 now. I will try and check at next > > > > weekend. > > > > > > In my ia64(zx6000), it looked that AcpiNsSearchAndEnter() returned > > > AE_NOT_FOUND. > > > How enable ACPI_DEBUG_PRINT or others many print? > > > > I look this messages on my ia64. (e.g. PCI0) > > > > _ADR Not found in 0xe0003f9dd1e8 [Not adding] > > Name [_ADR] not found in scope [PCI0] 0xe0003f9dd1e8 > > > > > > I think that no this problem crops up by all ia64 machines. Do you know > > the better evasion method? > > # Can I fixup by acpi_md_callback()? I look and find that now. > > I was thinking that acpi_md_callback() was called before the code where you > removed the check for ACPI_VALID_ADR, so you could have acpi_md_callback() > walk through the device tree constructed by acpi_build_tree() and set > ACPI_VALID_ADR on any devices where it was missing, as well as initializing > ad->ad_devinfo->Address. but the check for ACPI_VALID_ADR in question is in > acpi_pcidev_scan(), which is called at the end of acpi_build_tree(), > so it's actually called before acpi_md_callback() is called. > > it happens that ad->ad_devinfo->Address will be zero if ACPI_VALID_ADR > isn't set, I guess that value is actually correct on your system? By my ia64 machine, it cannot ensure that address of pchb is right. I checked the boot log(typescript) of FreeBSD and Debian. FreeBSD had returned AE_NOT_FOUND. The value of device and function was not displayed in Linux. http://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript.FreeBSD_ia64 http://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript.ia64.debian > so I guess the easiest thing for now would be to add another MD callback > that is called from acpi_build_tree() just before the call to > acpi_pcidev_scan(). in that callback you could adjust ACPI_VALID_ADR > and ad->ad_devinfo->Address as I was originally thinking. > once we eventually migrate more of the logic from x86/mpacpi.c > to dev/acpi/*.c, maybe we'll find that we can merge some of these > callbacks. I wish to call each device(or node?), like acpi_device_md_callback(). Please add new callback. Thanks, -- kiyohara
Re: pchb@acpi again
Hi! Chuck, From: Chuck Silvers Date: Sun, 21 Apr 2013 07:32:29 -0700 > On Mon, Apr 15, 2013 at 12:26:06AM +0300, Jukka Ruohonen wrote: > > On Sat, Apr 13, 2013 at 06:26:19PM -0700, Chuck Silvers wrote: > > > anyway, there are more problems with the new pchb, > > > it's unhappy with the other two PCI root bridges in this system: > > > > > > pchb7 at acpi0 (PCI1, PNP0A03-8): ACPI Host-PCI Bridge > > > pchb7: Can't get _PRT > > > pchb8 at acpi0 (PCI2, PNP0A03-9): ACPI Host-PCI Bridge > > > pchb8: Can't get _PRT > > > > > > these really don't have a _PRT method, but the rest of the code doesn't > > > mind. > > > they still attach fine with the mainbus attachment: > > > > > > I guess that's because even though these root bridges themselves don't > > > have > > > _PRT methods, the PCI bridges directly under them do have them. > > > so we'll need to accomodate that somehow. > > > > Why not just probe _PRT in the match()? According to the spec, _PRT should > > be mandatory for all PCI root bridges. > > I'm confused... if we were to make pchb_acpi_match() fail to match when the > root bridge device doesn't have a _PRT object, then how would you propose to > support systems like mine where some of the PCI root bridge devices don't have > _PRT objects? hmm... Can you try processing of _CRS of pci_intr_map() written to the patch of ia64? http://mail-index.NetBSD.org/tech-kern/2013/04/15/msg015173.html Linux was performing this processing by MI layer(under drivers/acpi/). This processing is also implemented by pchb_acpi.c. Thanks, -- kiyohara
Re: pchb@acpi again
Hi!, Chuck, From: Chuck Silvers Date: Sat, 13 Apr 2013 18:26:19 -0700 > ah, yes, removing it from that list lets it be found. and initializing > the new aa_dmat and aa_dmat64 fields lets pchb_acpi attach successfully. > all the PCI devices work fine, it turns out that we already have logic > to prevent a PCI bus from being attached twice. but the ISA devices are > are found twice: hmm... I disabled that isa devices in my config-file at 3 years old. And pchb found twice in my memory. (pchb@acpi, pchb@pci) Don`t you find these? This problem can avoid implement to pci_tag_equal(). Skip to call pci_probe_device(), if equal bridgetag and device's tag in pci_enumlate_bus(). Thanks, -- kiyohara
Re: pchb@acpi again
Hi!
From: KIYOHARA Takashi
Date: Sat, 13 Apr 2013 19:55:44 +0900 (JST)
> From: KIYOHARA Takashi
> Date: Tue, 09 Apr 2013 07:44:25 +0900 (JST)
>
> > From: Chuck Silvers
> > Date: Mon, 8 Apr 2013 09:34:06 -0700
> >
> > > in acpi_pci.c, why do you need to skip the check for ACPI_VALID_ADR?
> > > does the ACPI info on ia64 not have that flag set when it should?
> >
> > In my memory, YES. :-<
> > But I can't access to my ia64 now. I will try and check at next weekend.
>
> In my ia64(zx6000), it looked that AcpiNsSearchAndEnter() returned
> AE_NOT_FOUND.
> How enable ACPI_DEBUG_PRINT or others many print?
I look this messages on my ia64. (e.g. PCI0)
_ADR Not found in 0xe0003f9dd1e8 [Not adding]
Name [_ADR] not found in scope [PCI0] 0xe0003f9dd1e8
I think that no this problem crops up by all ia64 machines. Do you know
the better evasion method?
# Can I fixup by acpi_md_callback()? I look and find that now.
Also my ia64 patch attach to this mail.
Thanks,
--
kiyohara
? ia64/bus_dma.c
Index: conf/GENERIC
===
RCS file: /cvsroot/src/sys/arch/ia64/conf/GENERIC,v
retrieving revision 1.5
diff -u -r1.5 GENERIC
--- conf/GENERIC28 Apr 2012 23:03:40 - 1.5
+++ conf/GENERIC14 Apr 2013 04:02:03 -
@@ -55,6 +55,7 @@
# These options enable verbose messages for several subsystems.
# Warning, these may compile large string tables into the kernel!
optionsACPIVERBOSE # verbose ACPI device autoconfig messages
+optionsPCIVERBOSE # verbose PCI device autoconfig messages
# Kernel root file system and dump configuration.
@@ -75,8 +76,10 @@
# ACPI devices
acpitz*at acpi?# ACPI Thermal Zone
com* at acpi?# Serial communications interface
+pchb* at acpi?
-# PCI bus support
-#pci* at mainbus? bus ?
+# PCI Bus support
+pci* at pchb?
+
# Pull in optional local configuration
cinclude "arch/ia64/conf/GENERIC.local"
Index: conf/files.ia64
===
RCS file: /cvsroot/src/sys/arch/ia64/conf/files.ia64,v
retrieving revision 1.7
diff -u -r1.7 files.ia64
--- conf/files.ia64 1 Oct 2011 15:59:27 - 1.7
+++ conf/files.ia64 14 Apr 2013 04:02:03 -
@@ -86,6 +87,7 @@
# PCI fixup options# XX: Oops, required by acpi.c
defflag opt_pcifixup.h ACPI_PCI_FIXUP
+device pchb: pcibus
include "dev/acpi/files.acpi"
include "arch/ia64/conf/majors.ia64"
Index: ia64/autoconf.c
===
RCS file: /cvsroot/src/sys/arch/ia64/ia64/autoconf.c,v
retrieving revision 1.6
diff -u -r1.6 autoconf.c
--- ia64/autoconf.c 29 Jul 2012 18:05:43 - 1.6
+++ ia64/autoconf.c 14 Apr 2013 04:02:03 -
@@ -36,6 +36,13 @@
#include
#include
+#include
+
+#include
+
+#include "pci.h"
+
+
void
cpu_rootconf(void)
{
@@ -58,3 +65,20 @@
spl0();
}
+
+void
+device_register(device_t dev, void *aux)
+{
+ device_t parent = device_parent(dev);
+
+#if NPCI > 0
+ if (parent != NULL &&
+ device_is_a(parent, "pci")) {
+ struct pci_attach_args *pa = aux;
+ pcitag_t tag = pci_make_tag(pa->pa_pc,
+ pa->pa_bus, pa->pa_device, pa->pa_function);
+
+ pci_device_register(tag, dev);
+ }
+#endif
+}
Index: ia64/mainbus.c
===
RCS file: /cvsroot/src/sys/arch/ia64/ia64/mainbus.c,v
retrieving revision 1.9
diff -u -r1.9 mainbus.c
--- ia64/mainbus.c 17 May 2011 17:34:50 - 1.9
+++ ia64/mainbus.c 14 Apr 2013 04:02:03 -
@@ -118,6 +118,8 @@
aaa.aa_iot = IA64_BUS_SPACE_IO;
aaa.aa_memt = IA64_BUS_SPACE_MEM;
+ aaa.aa_dmat = 0;
+ aaa.aa_dmat64 = 0;
aaa.aa_pc = 0;
aaa.aa_pciflags =
PCI_FLAGS_IO_OKAY | PCI_FLAGS_MEM_OKAY |
Index: pci/pci_machdep.c
===
RCS file: /cvsroot/src/sys/arch/ia64/pci/pci_machdep.c,v
retrieving revision 1.3
diff -u -r1.3 pci_machdep.c
--- pci/pci_machdep.c 12 Jan 2013 08:40:51 - 1.3
+++ pci/pci_machdep.c 14 Apr 2013 04:02:04 -
@@ -1,6 +1,6 @@
/* $NetBSD: pci_machdep.c,v 1.3 2013/01/12 08:40:51 kiyohara Exp $ */
/*
- * Copyright (c) 2009, 2010 KIYOHARA Takashi
+ * Copyright (c) 2009, 2010, 2013 KIYOHARA Takashi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -27,6 +27,11 @@
#include
__KERNEL_RCSID(0, "$NetBSD: pci_machdep.c,v 1.3 2013/01/12 08:40:51 kiyohara
Exp $");
+#include
+#include
+#include
+#include
Re: pchb@acpi again
Hi! From: KIYOHARA Takashi Date: Tue, 09 Apr 2013 07:44:25 +0900 (JST) > From: Chuck Silvers > Date: Mon, 8 Apr 2013 09:34:06 -0700 > > > in acpi_pci.c, why do you need to skip the check for ACPI_VALID_ADR? > > does the ACPI info on ia64 not have that flag set when it should? > > In my memory, YES. :-< > But I can't access to my ia64 now. I will try and check at next weekend. In my ia64(zx6000), it looked that AcpiNsSearchAndEnter() returned AE_NOT_FOUND. How enable ACPI_DEBUG_PRINT or others many print? Thanks, -- kiyohara epoc32 again coming soon.
Re: pchb@acpi again
Hi! From: Chuck Silvers Date: Mon, 8 Apr 2013 09:34:06 -0700 > in acpi_pci.c, why do you need to skip the check for ACPI_VALID_ADR? > does the ACPI info on ia64 not have that flag set when it should? In my memory, YES. :-< But I can't access to my ia64 now. I will try and check at next weekend. Also my pchb on my ia64 has invalid vendor and product IDs(0x). > should the x86 ports be able to use this driver? Yes I shall maybe. My amd64 boots at last 3-4 years ago. > I tried adding "pchb* at acpi?" on amd64, but it isn't found. Please see acpi_ignored_ids[] in sys/dev/acpi/acpi.c. Thanks, -- kiyohara
Re: rbus support one-cardbus only?
Hi! I appologize. From: David Young Date: Mon, 9 Apr 2012 10:23:11 -0500 > On Tue, Apr 10, 2012 at 12:01:20AM +0900, KIYOHARA Takashi wrote: > > OPENBLOCKS266 supports two cardbus slots optionaly. > > But I think, MI-rbus not supports multiple cardbus slots. > > [Y/N]? OpenBlockS266 supports two cbb@pci. $ grep cbb dmesg.boot cbb0 at pci0 dev 1 function 0: Ricoh 5C475 PCI-CardBus Bridge (rev. 0x80) cbb1 at pci0 dev 2 function 0: Ricoh 5C475 PCI-CardBus Bridge (rev. 0x80) cbb0: cacheline 0x0 lattimer 0x40 cbb0: bhlc 0x24000 cbb0: interrupting at irq 28 cardslot0 at cbb0 cbb1: cacheline 0x0 lattimer 0x40 cbb1: bhlc 0x24000 cbb1: interrupting at irq 29 cardslot1 at cbb1 Do you support this case? Thanks, -- kiyohara
rbus size and end confuse
Hi! all,
I think, rbus is confusing 'size' and 'end'. rbus uses 'end' to extent
functions. man extent(9) describes
extent_create() creates an extent map managing the space from start to
end inclusive.
However some functions assumes 'end' is not inclusive.
for example, see attahed patch.
Thanks,
--
kiyohara
Index: arch/sparc64/sparc64/rbus_machdep.c
===
RCS file: /cvsroot/src/sys/arch/sparc64/sparc64/rbus_machdep.c,v
retrieving revision 1.16
diff -u -r1.16 rbus_machdep.c
--- arch/sparc64/sparc64/rbus_machdep.c 1 Jul 2011 18:49:24 - 1.16
+++ arch/sparc64/sparc64/rbus_machdep.c 9 Apr 2012 15:04:48 -
@@ -90,7 +90,7 @@
panic("rbus_pccbb_parent_mem: extent is not initialized");
start = ex->ex_start;
- size = ex->ex_end - start;
+ size = ex->ex_end - start + 1;
return rbus_new_root_share(pa->pa_memt, ex, start, size, 0);
}
@@ -108,7 +108,7 @@
panic("rbus_pccbb_parent_io: extent is not initialized");
start = ex->ex_start;
- size = ex->ex_end - start;
+ size = ex->ex_end - start + 1;
return rbus_new_root_share(pa->pa_iot, ex, start, size, 0);
}
Index: dev/cardbus/rbus.c
===
RCS file: /cvsroot/src/sys/dev/cardbus/rbus.c,v
retrieving revision 1.29
diff -u -r1.29 rbus.c
--- dev/cardbus/rbus.c 27 Jan 2012 18:53:07 - 1.29
+++ dev/cardbus/rbus.c 9 Apr 2012 15:04:48 -
@@ -253,7 +253,7 @@
{
rbus_tag_t rb;
struct extent *ex = NULL;
- bus_addr_t end = start + size;
+ bus_addr_t end = start + size - 1;
if (flags == RBUS_SPACE_SHARE) {
ex = parent->rb_ext;
@@ -269,7 +269,7 @@
return 0;
}
- rb = rbus_new_body(parent->rb_bt, parent, ex, start, start + size,
+ rb = rbus_new_body(parent->rb_bt, parent, ex, start, end,
offset, flags);
if ((rb == NULL) && (flags == RBUS_SPACE_DEDICATE)) {
@@ -293,13 +293,14 @@
{
rbus_tag_t rb;
struct extent *ex;
+ bus_addr_t end = start + size - 1;
- if (NULL == (ex = extent_create("rbus root", start, start + size,
+ if (NULL == (ex = extent_create("rbus root", start, end,
NULL, 0, EX_NOCOALESCE|EX_NOWAIT))) {
return NULL;
}
- rb = rbus_new_body(bt, NULL, ex, start, start + size, offset,
+ rb = rbus_new_body(bt, NULL, ex, start, end, offset,
RBUS_SPACE_DEDICATE);
if (rb == NULL) {
@@ -320,17 +321,19 @@
rbus_tag_t
rbus_new_root_share(bus_space_tag_t bt, struct extent *ex, bus_addr_t start,
bus_size_t size, bus_addr_t offset)
{
+ bus_addr_t end = start + size - 1;
+
/* sanity check */
- if (start < ex->ex_start || start + size > ex->ex_end) {
+ if (start < ex->ex_start || end > ex->ex_end) {
/*
-* out of range: [start, size] should be contained in
+* out of range: [start, end] should be contained in
* parent space
*/
return 0;
/* Should I invoke panic? */
}
- return rbus_new_body(bt, NULL, ex, start, start + size, offset,
+ return rbus_new_body(bt, NULL, ex, start, end, offset,
RBUS_SPACE_SHARE);
}
rbus support one-cardbus only?
Hi! all, I have a question. OPENBLOCKS266 supports two cardbus slots optionaly. But I think, MI-rbus not supports multiple cardbus slots. [Y/N]? OPENBLOCKS266 should support in MD layer? (i.e. in rbus_pccbb_parent_mem()) Thanks, -- kiyohara
Re: EHCI of SoC
Hi! all,
I make re-new patch.
I will commit next weekend.
Thanks,
--
kiyohara
Index: ehci.c
===
RCS file: /cvsroot/src/sys/dev/usb/ehci.c,v
retrieving revision 1.169
diff -u -r1.169 ehci.c
--- ehci.c 7 Jul 2010 03:55:01 - 1.169
+++ ehci.c 8 Oct 2010 11:06:58 -
@@ -392,6 +392,8 @@
aprint_error("%s: reset timeout\n", device_xname(sc->sc_dev));
return (USBD_IOERROR);
}
+ if (sc->sc_vendor_init)
+ sc->sc_vendor_init(sc);
/* XXX need proper intr scheduling */
sc->sc_rand = 96;
@@ -2260,6 +2262,8 @@
if (v & EHCI_PS_PEC)i |= UPS_C_PORT_ENABLED;
if (v & EHCI_PS_OCC)i |= UPS_C_OVERCURRENT_INDICATOR;
if (sc->sc_isreset[index]) i |= UPS_C_PORT_RESET;
+ if (sc->sc_vendor_port_status)
+ i = sc->sc_vendor_port_status(sc, v, i);
USETW(ps.wPortChange, i);
l = min(len, sizeof ps);
memcpy(buf, &ps, l);
@@ -2289,7 +2293,7 @@
case UHF_PORT_RESET:
DPRINTFN(5,("ehci_root_ctrl_start: reset port %d\n",
index));
- if (EHCI_PS_IS_LOWSPEED(v)) {
+ if (EHCI_PS_IS_LOWSPEED(v) && sc->sc_ncomp > 0) {
/* Low speed device, give up ownership. */
ehci_disown(sc, index, 1);
break;
@@ -2304,7 +2308,8 @@
goto ret;
}
/* Terminate reset sequence. */
- EOWRITE4(sc, port, v);
+ v = EOREAD4(sc, port);
+ EOWRITE4(sc, port, v & ~EHCI_PS_PR);
/* Wait for HC to complete reset. */
usb_delay_ms(&sc->sc_bus, EHCI_PORT_RESET_COMPLETE);
if (sc->sc_dying) {
Index: ehcivar.h
===
RCS file: /cvsroot/src/sys/dev/usb/ehcivar.h,v
retrieving revision 1.36
diff -u -r1.36 ehcivar.h
--- ehcivar.h 24 Feb 2010 22:38:09 - 1.36
+++ ehcivar.h 8 Oct 2010 11:06:59 -
@@ -167,6 +167,9 @@
device_t sc_child; /* /dev/usb# device */
char sc_dying;
struct usb_dma_reserve sc_dma_reserve;
+
+ void (*sc_vendor_init)(struct ehci_softc *);
+ int (*sc_vendor_port_status)(struct ehci_softc *, uint32_t, int);
} ehci_softc_t;
#define EREAD1(sc, a) bus_space_read_1((sc)->iot, (sc)->ioh, (a))
Re: EHCI of SoC
Hi! Matthias, From: Matthias Drochner Date: Sat, 11 Sep 2010 13:28:32 +0200 > > kiyoh...@kk.iij4u.or.jp said: > > + if (sc->sc_flags & EHCIF_HAVE_TT) > > [...] > > +#define EHCI_PS_PSPD_HS0x0800 /* High speed */ > > The way this is put into the "ehci" namespage suggests that > there is only a single blessed way to have a Transaction > Translator as an integral part of an EHCI. In the spec I know, > these bits are "reserved". > Are these extensions somehow on a standards track? If not, > I suggest to use a naming which makes clear that this is > just a vendor extension. Or better, add only hooks to > ehci.c and put the code into a new attachment frontend. No, I track not standards. > > +#define EHCI_PS_PSPD_HS0x0800 /* High speed */ Is better name EHCI_VENDOR_EXT_PS_PSPD_HS? Do we create new file named ehci_vext.c? Thanks, -- kiyohara
Re: EHCI of SoC
Hi! Adam,
From: Adam Hoka
Date: Thu, 9 Sep 2010 17:39:19 +0200
> On Thu, 09 Sep 2010 16:17:04 +0900 (JST)
> KIYOHARA Takashi wrote:
>
> > I know different additional initialization to be necessary for i.MX35.
> > We also should initialize to LSI dependent registers by callback
> > function.
>
> By LSI, you mean IC/chip here?
Yes.
LSI -> large scale integration
IC -> integrated circuit
> > @@ -392,6 +392,17 @@
> > aprint_error("%s: reset timeout\n",
> > device_xname(sc->sc_dev));
> > return (USBD_IOERROR);
> > }
> > + if (sc->sc_lsidep_init != NULL)
> > + sc->sc_lsidep_init(sc);
> >
> > /* XXX need proper intr scheduling */
> > sc->sc_rand = 96;
Thanks,
--
kiyohara
EHCI of SoC
Hi! all,
We know these fixes to be necessary for some EHCI core of SoC.
Index: ehci.c
===
RCS file: /cvsroot/src/sys/dev/usb/ehci.c,v
retrieving revision 1.169
diff -u -r1.169 ehci.c
--- ehci.c 7 Jul 2010 03:55:01 - 1.169
+++ ehci.c 8 Sep 2010 14:16:51 -
@@ -2247,8 +2255,27 @@
v = EOREAD4(sc, EHCI_PORTSC(index));
DPRINTFN(8,("ehci_root_ctrl_start: port status=0x%04x\n",
v));
- i = UPS_HIGH_SPEED;
- if (v & EHCI_PS_CS) i |= UPS_CURRENT_CONNECT_STATUS;
+ i = 0;
+ if (v & EHCI_PS_CS) {
+ if (sc->sc_flags & EHCIF_HAVE_TT)
+#define EHCI_PS_PSPD 0x0c00 /* Port speed */
+#define EHCI_PS_PSPD_FS0x /* Full speed */
+#define EHCI_PS_PSPD_LS0x0400 /* Low speed */
+#define EHCI_PS_PSPD_HS0x0800 /* High speed */
+ switch (v & EHCI_PS_PSPD) {
+ case EHCI_PS_PSPD_FS:
+ break;
+ case EHCI_PS_PSPD_LS:
+ i |= UPS_LOW_SPEED;
+ break;
+ case EHCI_PS_PSPD_HS:
+ default:
+ i |= UPS_HIGH_SPEED;
+ }
+ else
+ i |= UPS_HIGH_SPEED;
+ i |= UPS_CURRENT_CONNECT_STATUS;
+ }
if (v & EHCI_PS_PE) i |= UPS_PORT_ENABLED;
if (v & EHCI_PS_SUSP) i |= UPS_SUSPEND;
if (v & EHCI_PS_OCA)i |= UPS_OVERCURRENT_INDICATOR;
I think that this EHCIF_HAVE_TT is not a better name. This is necessary
in Marvell SoC. i.MX35 is also necessary. In addition, Oxford OXU210HP
is set in Linux.
Or, it is a condition "Companion is 0" and there is a possibility enough.
- i = UPS_HIGH_SPEED;
- if (v & EHCI_PS_CS) i |= UPS_CURRENT_CONNECT_STATUS;
+ i = 0;
+ if (v & EHCI_PS_CS) {
+ if (sc->sc_ncomp == 0) {
+ /*
+* We do not have a companion. However, we have
+* Transaction Translator built into the root
+* hub maybe.
+*/
+ switch (v & EHCI_PS_PSPD) {
:
+ }
+} else
:
+}
And,
@@ -2304,7 +2331,8 @@
goto ret;
}
/* Terminate reset sequence. */
- EOWRITE4(sc, port, v);
+ v = EOREAD4(sc, port);
+ EOWRITE4(sc, port, v & ~EHCI_PS_PR);
/* Wait for HC to complete reset. */
usb_delay_ms(&sc->sc_bus, EHCI_PORT_RESET_COMPLETE);
if (sc->sc_dying) {
In addition, some SoC loses some flags. Please know the newest flag.
For instance, it is Kirkwood, Orion, and i.MX35.
Moreover, this change was able to be accepted also with my e...@pci.
ehci0 at pci0 dev 2 function 2: NVIDIA nForce3 USB2 Host Controller
Next, this additional initialization is necessary for Marvell SoC
(eg. Kirkwood, Orion, ...). I understood that it was initialization
for USB IP Core of ARC and TransDimension(TDI) from the source of
Linux.
@@ -392,6 +392,17 @@
aprint_error("%s: reset timeout\n", device_xname(sc->sc_dev));
return (USBD_IOERROR);
}
+ if (sc->sc_flags & EHCIF_MARVELL) {
+ /* put TDI/ARC silicon into EHCI mode */
+ mode = EOREAD4(sc, EHCI_USBMODE);
+ mode &= ~EHCI_MODE_HDMASK; /* Host/Device Mask */
+ mode |= EHCI_MODE_HOST;
+ mode |= EHCI_MODE_STRMDIS;
+ EOWRITE4(sc, EHCI_USBMODE, mode);
+ }
/* XXX need proper intr scheduling */
sc->sc_rand = 96;
I know different additional initialization to be necessary for i.MX35.
We also should initialize to LSI dependent registers by callback
function.
@@ -392,6 +392,17 @@
aprint_error("%s: reset timeout\n", device_xname(sc->sc_dev));
return (USBD_IOERROR);
}
+ if (sc->sc_lsidep_init != NULL)
+ sc->sc_lsidep_init(sc);
/* XXX need proper intr scheduling */
sc->sc_rand = 96;
Plaese give me your idei. ;-)
Thanks,
--
kiyohara
Re: pchb@acpi
Hi! Quentin, From: Quentin Garnier Date: Sun, 1 Aug 2010 15:21:18 + > On Sun, Aug 01, 2010 at 11:17:54PM +0900, KIYOHARA Takashi wrote: > > All recent PC has information on PCI in ACPI. > > We can attach pchb in acpi like a lot of other acpi devices. > > p...@acpi has been fairly supported in FreeBSD since before. > > > > ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/p...@acpi-support.diff > > Do you have anything further in mind? This patch is only dmesg > cosmetics. No, I don't. My ia64 machine not need it. However it pass segment information to pci(4) in the future possibly. Thanks, -- kiyohara
pchb@acpi
Hi! all, I want p...@acpi support. All recent PC has information on PCI in ACPI. We can attach pchb in acpi like a lot of other acpi devices. p...@acpi has been fairly supported in FreeBSD since before. ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/p...@acpi-support.diff dmesg+ia64: ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript-20100801 Thanks, -- kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
From: Iain Hibbert
Date: Thu, 18 Feb 2010 11:53:50 + (GMT)
> On Thu, 18 Feb 2010, KIYOHARA Takashi wrote:
> > > +static int
> > > +btuart_dtl_probe(dev_t dev)
> > > +{
> > > +#if NCOM > 0
> >:
> > > +#endif
> > > + return 0;
> > > +}
> > >
> > > I really dislike this function, it depends on internals of com driver [btw
> > > COMUNIT(x) would be (minor(x) & COMUNIT_MASK)] and pcmcia and using this
> > > method prevents a soft emulator and/or needs kernel modifications to
> > > handle any new device.
> >
> > We are expecting the minor number to be obtained. In my opinion, it is
> > necessary to open() the device node for that. Therefore, only minor()
> > is called. It thinks dependence on the structure of pcmcia(4) for other
> > way not to exist though it is very regrettable. ;-<
>
> I don't understand why you want to make it complex in this way?
>
> in the beginning, the admin must recognise that they have a Nokia DTL
> device, eg:
>
> # btattach dtl /dev/tty03 19200
>
> btattach will perform the device specific initialisation, and set the line
> to use the protocol that is required. Why do you desire to forget this
> knowledge of the protocol type and require the btuart.c to depend on
> possibly unrelated parts of the kernel to re-discover it later?
hmm..
I do not like to make new line disc for LSI named NOKIA DTL.
> I find it makes no sense to do it that way, and furthermore the method
> will cause problems for any user who wishes to use the Nokia DTL protocol
> in a way that is not previously defined by you.
To begin with, what is the NOKIA DTL protocol?
NOKIA DTL is LSI.
We might separately make btdtl.c.
# However, I will not make it...
Thanks,
--
kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
From: Iain Hibbert
Date: Wed, 17 Feb 2010 10:12:28 + (GMT)
> On Tue, 16 Feb 2010, KIYOHARA Takashi wrote:
>
> /* sc_state */
> -#define BTUART_RECV_PKT_TYPE 0 /* packet type */
> +enum state {
> + BTUART_RECV_PKT_TYPE, /* packet type */
>
> please don't make this unrelated change. I don't like it because sc_state
> should really become "enum state" rather than int but then you need to add
> forward declarations..
It relates.
I have increased the value for DTL. However, this value doesn't have
the meaning. And, this is not used to calculate. Then, I think that
the enum that should not consider the value is more convenient. There
is danger of defining the same value for the macro.
> (btw, no comma is permitted on final enum values)
This is because of convenient for the addition in the future. The diff
becomes smaller. ;-)
> --- btattach.c6 Dec 2009 12:55:46 - 1.5
> +++ btattach.c16 Feb 2010 03:28:53 -
> @@ -54,13 +54,6 @@
:
> This is unrelated, and I did it just now..
Thanks.
> +static int
> +btuart_dtl_probe(dev_t dev)
> +{
> +#if NCOM > 0
:
> +#endif
> + return 0;
> +}
>
> I really dislike this function, it depends on internals of com driver [btw
> COMUNIT(x) would be (minor(x) & COMUNIT_MASK)] and pcmcia and using this
> method prevents a soft emulator and/or needs kernel modifications to
> handle any new device.
We are expecting the minor number to be obtained. In my opinion, it is
necessary to open() the device node for that. Therefore, only minor()
is called. It thinks dependence on the structure of pcmcia(4) for other
way not to exist though it is very regrettable. ;-<
Thanks,
--
kiyohara
Index: btuart.c
===
RCS file: /cvsroot/src/sys/dev/bluetooth/btuart.c,v
retrieving revision 1.24
diff -u -r1.24 btuart.c
--- btuart.c18 Feb 2010 07:24:16 - 1.24
+++ btuart.c18 Feb 2010 07:30:01 -
@@ -1,7 +1,7 @@
/* $NetBSD: btuart.c,v 1.24 2010/02/18 07:24:16 kiyohara Exp $ */
/*-
- * Copyright (c) 2006, 2007 KIYOHARA Takashi
+ * Copyright (c) 2006, 2007, 2010 KIYOHARA Takashi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -29,6 +29,8 @@
#include
__KERNEL_RCSID(0, "$NetBSD: btuart.c,v 1.24 2010/02/18 07:24:16 kiyohara Exp
$");
+#include "com.h"
+
#include
#include
#include
@@ -49,8 +51,14 @@
#include
#include
+#if NCOM > 0
+#include
+#include
+#endif
+
#include "ioconf.h"
+
struct btuart_softc {
device_tsc_dev;
struct tty *sc_tp; /* tty pointer */
@@ -61,6 +69,7 @@
int sc_state; /* receive state */
int sc_want;/* how much we want */
+ boolsc_pad; /* pad will receive before next pkt */
struct mbuf * sc_rxp; /* incoming packet */
boolsc_xmit;/* transmit is active */
@@ -73,13 +82,25 @@
};
/* sc_state */
-#define BTUART_RECV_PKT_TYPE 0 /* packet type */
-#define BTUART_RECV_ACL_HDR1 /* acl header */
-#define BTUART_RECV_SCO_HDR2 /* sco header */
-#define BTUART_RECV_EVENT_HDR 3 /* event header */
-#define BTUART_RECV_ACL_DATA 4 /* acl packet data */
-#define BTUART_RECV_SCO_DATA 5 /* sco packet data */
-#define BTUART_RECV_EVENT_DATA 6 /* event packet data */
+#define BTUART_RECV_PKT_TYPE 0 /* packet type */
+#define BTUART_RECV_ACL_HDR1 /* acl header */
+#define BTUART_RECV_SCO_HDR2 /* sco header */
+#define BTUART_RECV_EVENT_HDR 3 /* event header */
+#define BTUART_RECV_ACL_DATA 4 /* acl packet data */
+#define BTUART_RECV_SCO_DATA 5 /* sco packet data */
+#define BTUART_RECV_EVENT_DATA 6 /* event packet data */
+#define BTUART_RECV_DTL_HDR7 /* DTL header */
+#define BTUART_RECV_DTL_CTRL_DATA 8 /* DTL control data */
+#define BTUART_RECV_DTL_ACL_DATA 9 /* DTL acl data */
+#define BTUART_RECV_DTL_SCO_DATA 10 /* DTL sco data */
+#define BTUART_RECV_DTL_EVENT_DATA 11 /* DTL event data */
+
+struct btuart_dtl_header { /* NOKIA DTL-1/4 header */
+ uint8_t type; /* packet type */
+ uint8_t rsvd;
+ uint16_t len; /* data length */
+} __packed;
+#define BTUART_DTL_HEADER_TYPE 0x80
void btuartattach(int);
static int btuart_match(device_t, cfdata_t, void *);
@@ -99,12 +120,20 @@
static void btuart_output_sco(device_t, struct mbuf *);
static void btuart_stats(device_t, struct bt_stats *, int);
+static int btuart_dtl_probe(dev_t);
+static void btuart_dtl_atta
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
From: Iain Hibbert
Date: Sun, 14 Feb 2010 10:44:43 + (GMT)
> On Sun, 14 Feb 2010, KIYOHARA Takashi wrote:
> You didn't count the whole lifetime of that byte..
Oops. I missunderstand. Fix.
> > I devised a different method. This executes processing to attach
> > different according to cfdata->cf_atname.
>
> I think depending on ldisc->l_name was cleaner. (no need for #ifdef)
Is it '#if NCOM > 0' that you indicate?
The variable com_cdevsw is necessary for us. It is declared in com.c.
As for NOKIA DTL, it is all supported that I know with c...@pcmcia.
However, some btuart modules seems to be provided by the serial dongle.
In a word, you can use with zs(4).
> in btuart_dtl_output_*(), M_WAITOK is not permitted, and m_copyback() can
> fail, the result should be tested..
Fix. ;-)
Thanks,
--
kiyohara
Index: btuart.c
===
RCS file: /cvsroot/src/sys/dev/bluetooth/btuart.c,v
retrieving revision 1.23
diff -u -r1.23 btuart.c
--- btuart.c12 May 2009 12:10:46 - 1.23
+++ btuart.c16 Feb 2010 05:47:11 -
@@ -1,7 +1,7 @@
/* $NetBSD: btuart.c,v 1.23 2009/05/12 12:10:46 cegger Exp $ */
/*-
- * Copyright (c) 2006, 2007 KIYOHARA Takashi
+ * Copyright (c) 2006, 2007, 2010 KIYOHARA Takashi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -29,6 +29,8 @@
#include
__KERNEL_RCSID(0, "$NetBSD: btuart.c,v 1.23 2009/05/12 12:10:46 cegger Exp $");
+#include "com.h"
+
#include
#include
#include
@@ -49,8 +51,14 @@
#include
#include
+#if NCOM > 0
+#include
+#include
+#endif
+
#include "ioconf.h"
+
struct btuart_softc {
device_tsc_dev;
struct tty *sc_tp; /* tty pointer */
@@ -61,6 +69,7 @@
int sc_state; /* receive state */
int sc_want;/* how much we want */
+ boolsc_pad; /* pad will receive before next pkt */
struct mbuf * sc_rxp; /* incoming packet */
boolsc_xmit;/* transmit is active */
@@ -73,13 +82,28 @@
};
/* sc_state */
-#define BTUART_RECV_PKT_TYPE 0 /* packet type */
-#define BTUART_RECV_ACL_HDR1 /* acl header */
-#define BTUART_RECV_SCO_HDR2 /* sco header */
-#define BTUART_RECV_EVENT_HDR 3 /* event header */
-#define BTUART_RECV_ACL_DATA 4 /* acl packet data */
-#define BTUART_RECV_SCO_DATA 5 /* sco packet data */
-#define BTUART_RECV_EVENT_DATA 6 /* event packet data */
+enum state {
+ BTUART_RECV_PKT_TYPE, /* packet type */
+ BTUART_RECV_ACL_HDR,/* acl header */
+ BTUART_RECV_SCO_HDR,/* sco header */
+ BTUART_RECV_EVENT_HDR, /* event header */
+ BTUART_RECV_ACL_DATA, /* acl packet data */
+ BTUART_RECV_SCO_DATA, /* sco packet data */
+ BTUART_RECV_EVENT_DATA, /* event packet data */
+
+ BTUART_RECV_DTL_HDR,/* DTL header */
+ BTUART_RECV_DTL_CTRL_DATA, /* DTL control data */
+ BTUART_RECV_DTL_ACL_DATA, /* DTL acl data */
+ BTUART_RECV_DTL_SCO_DATA, /* DTL sco data */
+ BTUART_RECV_DTL_EVENT_DATA, /* DTL event data */
+};
+
+struct btuart_dtl_header { /* NOKIA DTL-1/4 header */
+ uint8_t type; /* packet type */
+ uint8_t rsvd;
+ uint16_t len; /* data length */
+} __packed;
+#define BTUART_DTL_HEADER_TYPE 0x80
void btuartattach(int);
static int btuart_match(device_t, cfdata_t, void *);
@@ -99,12 +123,20 @@
static void btuart_output_sco(device_t, struct mbuf *);
static void btuart_stats(device_t, struct bt_stats *, int);
+static int btuart_dtl_probe(dev_t);
+static void btuart_dtl_attach(device_t, device_t, void *);
+static void btuart_dtl_output_cmd(device_t, struct mbuf *);
+static void btuart_dtl_output_acl(device_t, struct mbuf *);
+static void btuart_dtl_output_sco(device_t, struct mbuf *);
+
/*
* It doesn't need to be exported, as only btuartattach() uses it,
* but there's no "official" way to make it static.
*/
CFATTACH_DECL_NEW(btuart, sizeof(struct btuart_softc),
btuart_match, btuart_attach, btuart_detach, NULL);
+CFATTACH_DECL_NEW(btuart_dtl, sizeof(struct btuart_softc),
+btuart_match, btuart_dtl_attach, btuart_detach, NULL);
static struct linesw btuart_disc = {
.l_name = "btuart",
@@ -128,6 +160,15 @@
.get_stats =btuart_stats,
.ipl = IPL_TTY,
};
+static const struct hci_if btuart_dtl_hci = {
+ .enable = btuart_enable,
+ .disable = btuart_disable,
+ .output_cmd = btuart_dtl_output_cmd,
+ .output_acl = btuart_dtl_output_acl,
Re: btuart and SOCKET Bluetooth CF
Hi! Iain and all,
From: Iain Hibbert
Date: Wed, 27 Jan 2010 20:35:31 + (GMT)
> "output" path. On the input at least I think it would be more efficient
> to just use the sc_drop flag instead of adding the pad byte into the mbuf
> and using m_adj to remove it later - mbuf operations can be quite
> expensive in this manner.. for the output you also cannot sleep at this
> time, so must deal with failure to prepend/append data to the mbuf.
Why?
DTL always adjusts the header. And, the pad is adjusted if necessary.
Is the efficiency that you think about a memory size? Or, is it a speed?
The count of the m_adj() and the 'if (...)' is the same as you and me in
the source of C. And, I leave efficiency to the compiler.
> > In my understanding, the cfdata->cf_flags is a flag that each driver
> > can use. You can find it used in arch/PORT/conf/GENERIC by wdc(4)
> > and wd(4).
>
> imo all of cfdata is not for drivers to set
hmm... There are none of discussions about this. ;-<
I devised a different method. This executes processing to attach
different according to cfdata->cf_atname.
Thanks,
--
kiyohara
Index: btuart.c
===
RCS file: /cvsroot/src/sys/dev/bluetooth/btuart.c,v
retrieving revision 1.23
diff -u -r1.23 btuart.c
--- btuart.c12 May 2009 12:10:46 - 1.23
+++ btuart.c8 Feb 2010 18:05:29 -
@@ -1,7 +1,7 @@
/* $NetBSD: btuart.c,v 1.23 2009/05/12 12:10:46 cegger Exp $ */
/*-
- * Copyright (c) 2006, 2007 KIYOHARA Takashi
+ * Copyright (c) 2006, 2007, 2010 KIYOHARA Takashi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -29,6 +29,8 @@
#include
__KERNEL_RCSID(0, "$NetBSD: btuart.c,v 1.23 2009/05/12 12:10:46 cegger Exp $");
+#include "com.h"
+
#include
#include
#include
@@ -49,8 +51,14 @@
#include
#include
+#if NCOM > 0
+#include
+#include
+#endif
+
#include "ioconf.h"
+
struct btuart_softc {
device_tsc_dev;
struct tty *sc_tp; /* tty pointer */
@@ -73,13 +81,28 @@
};
/* sc_state */
-#define BTUART_RECV_PKT_TYPE 0 /* packet type */
-#define BTUART_RECV_ACL_HDR1 /* acl header */
-#define BTUART_RECV_SCO_HDR2 /* sco header */
-#define BTUART_RECV_EVENT_HDR 3 /* event header */
-#define BTUART_RECV_ACL_DATA 4 /* acl packet data */
-#define BTUART_RECV_SCO_DATA 5 /* sco packet data */
-#define BTUART_RECV_EVENT_DATA 6 /* event packet data */
+enum state {
+ BTUART_RECV_PKT_TYPE, /* packet type */
+ BTUART_RECV_ACL_HDR,/* acl header */
+ BTUART_RECV_SCO_HDR,/* sco header */
+ BTUART_RECV_EVENT_HDR, /* event header */
+ BTUART_RECV_ACL_DATA, /* acl packet data */
+ BTUART_RECV_SCO_DATA, /* sco packet data */
+ BTUART_RECV_EVENT_DATA, /* event packet data */
+
+ BTUART_RECV_DTL_HDR,/* DTL header */
+ BTUART_RECV_DTL_CTRL_DATA, /* DTL control data */
+ BTUART_RECV_DTL_ACL_DATA, /* DTL acl data */
+ BTUART_RECV_DTL_SCO_DATA, /* DTL sco data */
+ BTUART_RECV_DTL_EVENT_DATA, /* DTL event data */
+};
+
+struct btuart_dtl_header { /* NOKIA DTL-1/4 header */
+ uint8_t type; /* packet type */
+ uint8_t rsvd;
+ uint16_t len; /* data length */
+} __packed;
+#define BTUART_DTL_HEADER_TYPE 0x80
void btuartattach(int);
static int btuart_match(device_t, cfdata_t, void *);
@@ -99,12 +122,20 @@
static void btuart_output_sco(device_t, struct mbuf *);
static void btuart_stats(device_t, struct bt_stats *, int);
+static int btuart_dtl_probe(dev_t);
+static void btuart_dtl_attach(device_t, device_t, void *);
+static void btuart_dtl_output_cmd(device_t, struct mbuf *);
+static void btuart_dtl_output_acl(device_t, struct mbuf *);
+static void btuart_dtl_output_sco(device_t, struct mbuf *);
+
/*
* It doesn't need to be exported, as only btuartattach() uses it,
* but there's no "official" way to make it static.
*/
CFATTACH_DECL_NEW(btuart, sizeof(struct btuart_softc),
btuart_match, btuart_attach, btuart_detach, NULL);
+CFATTACH_DECL_NEW(btuart_dtl, sizeof(struct btuart_softc),
+btuart_match, btuart_dtl_attach, btuart_detach, NULL);
static struct linesw btuart_disc = {
.l_name = "btuart",
@@ -128,6 +159,15 @@
.get_stats =btuart_stats,
.ipl = IPL_TTY,
};
+static const struct hci_if btuart_dtl_hci = {
+ .enable = btuart_enable,
+ .disable = btuart_disable,
+ .output_cmd = btuart_dtl_output_cmd,
+ .output_acl = btuart_d
Re: btuart and SOCKET Bluetooth CF
Hi! Iain, From: Iain Hibbert Date: Sat, 23 Jan 2010 17:49:28 + (GMT) > On Sat, 23 Jan 2010, KIYOHARA Takashi wrote: > However, I'm not sure if it is permitted to use cfdata->cf_flags in this > manner? There seem to be some rare instances of similar use but there is > no mention in the API specification.. Oops. I can't agree your patch. :-< DTL always has the header. It is a big penalty to check this by all packets. And, btuart(4) is used perhaps on a very slow machine. So it is a slow machine without usb(ubt(4)) perhaps. # My main machine is hpcsh 100MHz with PCMCIA. ;-) # It not have Cardbus and USB. In my understanding, the cfdata->cf_flags is a flag that each driver can use. You can find it used in arch/PORT/conf/GENERIC by wdc(4) and wd(4). Thanks, -- kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
From: Iain Hibbert
Date: Fri, 22 Jan 2010 12:06:50 + (GMT)
> On Fri, 22 Jan 2010, KIYOHARA Takashi wrote:
>
> > > These drivers are only a line filter and it makes no sense to me to start
> > > a wrong filter then apply a correction when we could just start the
> > > correct one in the beginning. There is a little autoconf glue the same it
> > > is true, but the thing which is different (the IO routines) are the
> > > majority of the driver..
> >
> > A little more brief description, please. I do not understand your
> > explanation. ;-<
>
> Ok, I will (try to be :) clear then - from my viewpoint I like this:
>
> UART device - com - tty - btuart - netbt
>
> Nokia device - com - tty - btdtl - netbt
>
> but you are trying to make this:
>
> UART device - com - tty - btuart - uart - netbt
>
> Nokia device - com - tty - btuart - dtl - netbt
Yes. However, I want to make the same operation a function and to
separate.
> But, we already have a method (TIOCSLINED, "btuart") to select the line
> protocol and the autoconf glue is small. So, I think adding this layer
> becomes complex for no good reason.
hmm... No one participates in this discussion... ;-<
My acquaintance said that should use TIOCSLINED. Instead of
BTUART_SELECT_PROTOCOL.
> Ultimately, for this method I think the attach phase becomes subject to
> race conditions. There is a time between (TIOCSLINED, "btuart") and
> (BTUART_SELECT_PROTOCOL, DTL) when the driver can not know what to do with
> received data, which it must process. If you throw it away you risk
> becoming out of sync with no way to resync. You can add more complexity to
> handle this.. but I prefer simplicity.
NOKIA DTL doesn't act until our bt-pkt is received in the initial state.
Also we can reset its state by MODEM Control Register.
I made new btuart.c.
In my opinion, that it is foolish to create btdtl.c. Because there is
little functional difference, and it is work of sed(1).
# However I not test new btuart.c yet. ;-)
Thanks,
--
kiyohara
/* $NetBSD: btuart.c,v 1.23 2009/05/12 12:10:46 cegger Exp $ */
/*-
* Copyright (c) 2006, 2007, 2010 KIYOHARA Takashi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include
__KERNEL_RCSID(0, "$NetBSD: btuart.c,v 1.23 2009/05/12 12:10:46 cegger Exp $");
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "ioconf.h"
#define BTUART_TYPE_DEFAULT 0
#define BTUART_TYPE_DTL 1
struct btuart_softc {
device_tsc_dev;
struct tty *sc_tp; /* tty pointer */
boolsc_enabled; /* device is enabled */
struct hci_unit *sc_unit; /* Bluetooth HCI handle */
struct bt_stats sc_stats;
int sc_state; /* receive state */
int sc_want;/* how much we want */
struct mbuf * sc_rxp; /* incoming packet */
boolsc_xmit;/* transmit is active */
struct mbuf * sc_txp; /* outgoing packet */
/* transmit queues */
MBUFQ_HEAD()sc_cmdq;
MBUFQ_HEAD()sc_aclq;
MBUFQ_HEAD()sc_scoq;
};
/* sc_state */
#define BTUART_RECV_PKT_TYPE0 /* packet type */
#define BTUART_RECV_ACL_HDR 1 /* acl header */
#define BTUART_RECV_SCO_HDR 2 /* sco header */
#define BTUART_RECV_EVENT_HDR 3 /* even
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
First of all, I changed as follows.
In case cmd_pkt---
static void
btuart_dtl_output_cmd(device_t self, struct mbuf *m)
{
:
m_adj(m, sizeof(uint8_t)); /* remove hci_cmd_hdr_t's type */
M_PREPEND(m, sizeof(struct btuart_dtl_header), M_WAITOK);
dtlh = mtod(m, struct btuart_dtl_header *);
dtlh->type = HCI_CMD_PKT | BTUART_DTL_HEADER_TYPE;
dtlh->rsvd = 0;
dtlh->len = m->m_pkthdr.len - sizeof(struct btuart_dtl_header);
if (m->m_pkthdr.len & 0x1)
m_copyback(m, m->m_pkthdr.len, 1, &dtlh->rsvd); /* Add pad */
:
}
---
However...
From: Iain Hibbert
Date: Wed, 20 Jan 2010 11:03:43 +0000 (GMT)
> On Wed, 20 Jan 2010, KIYOHARA Takashi wrote:
>
> > In my opinion, I think that NOKIA DTL is subspecies of btuart(H4). This
> > header is only a little different. Therefore, I feel that it is strange
> > to prepare a line discipline new different for NOKIA DTL.
> with the DTL it is much simpler - we don't care about the packet contents
> at this level because we can always know the length of the packet. All the
> 7 states are not needed, as 2 only are sufficient (header & data)
hmm...
Five states are necessary for NOKIA DTL. If NOKIA DTL is supported in two
states, it is should support btuart in five states.
switch (sc->sc_state) {
case BTUART_RECV_PKT_TYPE:
:
case BTUART_RECV_ACL_HDR:
sc->sc_hci_input = hci_input_acl;
sc->sc_stats_rx = &sc->sc_stats.acl_rx;
:
case BTUART_RECV_SCO_HDR:
sc->sc_hci_input = hci_input_sco;
sc->sc_stats_rx = &sc->sc_stats.sco_rx;
:
case BTUART_RECV_EVENT_HDR:
sc->sc_hci_input = hci_input_event;
sc->sc_stats_rx = &sc->sc_stats.evt_rx;
:
case BTUART_RECV_DATA: /* Packet Complete */
if (!sc->sc_hci_input(sc->sc_unit, sc->sc_rxp))
sc->sc_stats.err_rx++;
*sc->sc_stats_rx++;
sc->sc_state = BTUART_RECV_PKT_TYPE;
sc->sc_want = 1;
sc->sc_rxp = NULL;
break;
}
> These drivers are only a line filter and it makes no sense to me to start
> a wrong filter then apply a correction when we could just start the
> correct one in the beginning. There is a little autoconf glue the same it
> is true, but the thing which is different (the IO routines) are the
> majority of the driver..
A little more brief description, please. I do not understand your
explanation. ;-<
Thanks,
--
kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! all, From: Iain Hibbert Date: Wed, 20 Jan 2010 11:11:21 + (GMT) > On Wed, 20 Jan 2010, Iain Hibbert wrote: > > > Ok - my question is, for a 5 byte ACL packet: > > > > 82 00 09 00 01 00 05 00 aa bb cc dd ee 00 > > ^ [] > > > > or > > > > 82 00 0a 00 01 00 05 00 aa bb cc dd ee 00 > > ^ [...] > > > > ? > > > > I think the second (but I did not design the NOKIA DTL-1 device :) > > further to this, on your input path > > + case BTUART_RECV_DTL_ACL_DATA: /* ACL Packet Complete */ > + if (dtlh->len & 0x0001) > + m_adj(m, -1); > > this seems to be incorrect logic.. in the first case, it will chop a > valid byte and in the second it will not chop the pad byte. The com(4) port is sequentially transferred by one byte though NOKIA DTL treats 2byte/word. COM port c...@pcmcia < NOKIA DTL 0x82 rsvd lenL lenH ... dd ee 00 Thanks, -- kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! Iain, From: Iain Hibbert Date: Wed, 20 Jan 2010 10:20:24 + (GMT) > On Wed, 20 Jan 2010, KIYOHARA Takashi wrote: > > > > also - should this value reflect the real length (including the pad)? eg > > > data stream: > Ok - my question is, for a 5 byte ACL packet: > > 82 00 09 00 01 00 05 00 aa bb cc dd ee 00 > ^ [] > > or > > 82 00 0a 00 01 00 05 00 aa bb cc dd ee 00 > ^ [...] > > ? > > I think the second (but I did not design the NOKIA DTL-1 device :) NOKIA DTL is former. Thanks, -- kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! Iain, From: Iain Hibbert Date: Wed, 20 Jan 2010 10:04:49 + (GMT) > On Wed, 20 Jan 2010, KIYOHARA Takashi wrote: > > > > Further, I think for simplicity you don't need to interpret the HCI packet > > > header directly during output, just use the m->m_pkthdr.len value which is > > > correct. > > > > What do you meaning? > > Please more explain. > in btuart_dtl_output_acl() > > + hci_acldata_hdr_t hdr; > > this "hdr" is not needed, we don't need to examine the packet to find that > information, as the type and length values are already known.. Oh! I understand. ;-) I will fix. Thanks, -- kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
From: Iain Hibbert
Date: Tue, 19 Jan 2010 14:03:22 + (GMT)
> On Tue, 19 Jan 2010, Iain Hibbert wrote:
> also - should this value reflect the real length (including the pad)? eg
> data stream:
>
> [type] [rsvd] [len0] [len1] [.. data[len] ..]
> [type] [rsvd] [len0] [len1] [.. data[len] ..]
> [type] [rsvd] [len0] [len1] [.. data[len] ..]
> [type] [rsvd] [len0] [len1] [.. data[len] ..]
I know, DTL operates following packet format.
In acldata case:
{
{
uint8 type;
uint8 rsvd;
uint16 len;
} NOKIA DTL header;
{
uint16_tcon_handle;
uint16_tlength;
};
{
data ...
};
[uint8_t pad;]/* need, if len is odd. */
}
NOKIA DTL parses little-endian. And operates each 2bytes/word. When
the length of data is an odd byte because headers are four bytes always,
padding is necessary.
> Further, I think for simplicity you don't need to interpret the HCI packet
> header directly during output, just use the m->m_pkthdr.len value which is
> correct.
What do you meaning?
Please more explain.
Thanks,
--
kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
From: Iain Hibbert
Date: Tue, 19 Jan 2010 12:36:39 + (GMT)
> On Tue, 19 Jan 2010, KIYOHARA Takashi wrote:
> > I apologizes for insufficient explanation. I want to call btuartioctl()
> > for NOKIA DTL. Therefore, it is necessary to return btuart.h removed
> > before. (btuart.h v1.4)
>
> what extra do you need to control with the ioctl() ?
>
> (I think your direction is wrong and it may be unnecessary - see below)
>
> > > I think there is some specialist 'nokia' control packets possible with
> > > this protocol, do we need to use them during the operation of the device?
> > > (in setup, the btattach module can send/recv what it likes..)
> >
> > NOKIA DTL always need btuart_dtl_header for all packet. However it not
> > need process for setup. It detect clock speed automatically perhaps.
> > I could operate 9600 and 115200.
> >
> > # btattach -f /dev/tty01 (9600|115200)
>
> my thought is that for example, add
>
> --- btattach.c6 Dec 2009 12:55:46 - 1.5
> +++ btattach.c19 Jan 2010 12:23:03 -
> @@ -97,6 +97,12 @@
> .speed = B9600,
> },
> {
> + .name = "dtl",
> + .line = "btdtl",
> + .descr = "Nokia DTL-1/4",
> + .speed = B115200,
> +},
> +{
> .name = "ericsson",
> .line = "btuart",
> .descr = "Ericsson based modules",
> and the "btdtl" line driver handles accumulating the packets in the
> correct manner and passing it to the netbt stack. I think btuart.c is
> unnecesssary for this device to work? The protocol used is different..
In my opinion, I think that NOKIA DTL is subspecies of btuart(H4). This
header is only a little different. Therefore, I feel that it is strange
to prepare a line discipline new different for NOKIA DTL.
Thanks,
--
kiyohara
Re: btuart and SOCKET Bluetooth CF
Hi! Iain, From: Iain Hibbert Date: Mon, 18 Jan 2010 13:43:09 + (GMT) > On Mon, 18 Jan 2010, KIYOHARA Takashi wrote: > > > I am supporting NOKIA DTL-1/4 now. > > (SOCKET Bluetooth CF 8510-00159F and older version) > > Linux supported it by drivers/bluetooth/dtl1_cs.c. > > > > This obtains BDADDR now and does inquiry. > > Hm, does it work with ACL data yet? I think that your > btuart_dtl_output_acl() function strips the ACLDATA header.. I don't > understand how does the device know the connection handle? Only type (1byte) of acldata adjust to me. Perhaps, the problem is not in this. > > However, this should attach/ detach the 4byte header at btuart. > > Is this the only difference, that there is an extra wrapper around every > packet in and out? I looked like that. > > Should we support ioctl for this? Or, do you have a better idea? > > As you may recall, I don't want the driver to be poking inside the netbt > stack structures. The way you have that has catastrophy pending :) > > I think that because the btuart driver is fairly simple, it would be best > to just clone it and make a btdtl.c that handles the appropriate IO > directly.. that way, btattach can attach it with a different name and no > ioctl is needed to activate the difference..? I apologizes for insufficient explanation. I want to call btuartioctl() for NOKIA DTL. Therefore, it is necessary to return btuart.h removed before. (btuart.h v1.4) > I think there is some specialist 'nokia' control packets possible with > this protocol, do we need to use them during the operation of the device? > (in setup, the btattach module can send/recv what it likes..) NOKIA DTL always need btuart_dtl_header for all packet. However it not need process for setup. It detect clock speed automatically perhaps. I could operate 9600 and 115200. # btattach -f /dev/tty01 (9600|115200) Moreover, I understood there was a method where it reset it by using the MODEM control register (com(4)'s MCR). Thanks, -- kiyohara
btuart and SOCKET Bluetooth CF
Hi! Iain and all,
I am supporting NOKIA DTL-1/4 now.
(SOCKET Bluetooth CF 8510-00159F and older version)
Linux supported it by drivers/bluetooth/dtl1_cs.c.
This obtains BDADDR now and does inquiry. However, this should attach/
detach the 4byte header at btuart.
The support of DTL can change some parameters. I think that ioctl is
necessary for that.
@@ -191,6 +210,24 @@
sc->sc_unit = hci_attach(&btuart_hci, self, 0);
if (sc->sc_unit == NULL)
aprint_error_dev(self, "HCI attach failed\n");
+
+if (1) {
+ struct hci_if *btuart_dtl_hci =
+ malloc(sizeof(struct hci_if), M_BLUETOOTH, M_ZERO | M_WAITOK);
+
+ memcpy(btuart_dtl_hci, sc->sc_unit->hci_if, sizeof(struct hci_if));
+ btuart_dtl_hci->output_cmd = btuart_dtl_output_cmd;
+ btuart_dtl_hci->output_acl = btuart_dtl_output_acl;
+ btuart_dtl_hci->output_sco = btuart_dtl_output_sco;
+ sc->sc_unit->hci_if = btuart_dtl_hci;
+ sc->sc_input = btuart_dtl_input;
+ sc->sc_state = BTUART_RECV_DTL_HDR;
+ sc->sc_want = sizeof(struct btuart_dtl_header);
+} else {
+ sc->sc_input = btuart_input;
+ sc->sc_state = BTUART_RECV_PKT_TYPE;
+ sc->sc_want = 1;
+}
Should we support ioctl for this? Or, do you have a better idea?
Thanks,
--
kiyohara
Index: btuart.c
===
RCS file: /cvsroot/src/sys/dev/bluetooth/btuart.c,v
retrieving revision 1.23
diff -u -r1.23 btuart.c
--- btuart.c12 May 2009 12:10:46 - 1.23
+++ btuart.c18 Jan 2010 12:01:42 -
@@ -1,7 +1,7 @@
/* $NetBSD: btuart.c,v 1.23 2009/05/12 12:10:46 cegger Exp $ */
/*-
- * Copyright (c) 2006, 2007 KIYOHARA Takashi
+ * Copyright (c) 2006, 2007, 2010 KIYOHARA Takashi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -59,6 +59,7 @@
struct hci_unit *sc_unit; /* Bluetooth HCI handle */
struct bt_stats sc_stats;
+ void(*sc_input)(struct btuart_softc *, struct mbuf *);
int sc_state; /* receive state */
int sc_want;/* how much we want */
struct mbuf * sc_rxp; /* incoming packet */
@@ -73,13 +74,25 @@
};
/* sc_state */
-#define BTUART_RECV_PKT_TYPE 0 /* packet type */
-#define BTUART_RECV_ACL_HDR1 /* acl header */
-#define BTUART_RECV_SCO_HDR2 /* sco header */
-#define BTUART_RECV_EVENT_HDR 3 /* event header */
-#define BTUART_RECV_ACL_DATA 4 /* acl packet data */
-#define BTUART_RECV_SCO_DATA 5 /* sco packet data */
-#define BTUART_RECV_EVENT_DATA 6 /* event packet data */
+#define BTUART_RECV_PKT_TYPE 0 /* packet type */
+#define BTUART_RECV_ACL_HDR1 /* acl header */
+#define BTUART_RECV_SCO_HDR2 /* sco header */
+#define BTUART_RECV_EVENT_HDR 3 /* event header */
+#define BTUART_RECV_ACL_DATA 4 /* acl packet data */
+#define BTUART_RECV_SCO_DATA 5 /* sco packet data */
+#define BTUART_RECV_EVENT_DATA 6 /* event packet data */
+#define BTUART_RECV_DTL_HDR7 /* DTL header */
+#define BTUART_RECV_DTL_CTRL_DATA 8 /* DTL control data */
+#define BTUART_RECV_DTL_ACL_DATA 9 /* DTL acl data */
+#define BTUART_RECV_DTL_SCO_DATA 10 /* DTL sco data */
+#define BTUART_RECV_DTL_EVENT_DATA 11 /* DTL event data */
+
+struct btuart_dtl_header { /* NOKIA DTL-1/4 header */
+ uint8_t type;
+ uint8_t rsvd;
+ uint16_t len;
+} __packed;
+#define BTUART_DTL_HEADER_TYPE 0x80
void btuartattach(int);
static int btuart_match(device_t, cfdata_t, void *);
@@ -99,6 +112,12 @@
static void btuart_output_sco(device_t, struct mbuf *);
static void btuart_stats(device_t, struct bt_stats *, int);
+static void btuart_input(struct btuart_softc *, struct mbuf *);
+static void btuart_dtl_input(struct btuart_softc *, struct mbuf *);
+static void btuart_dtl_output_cmd(device_t, struct mbuf *);
+static void btuart_dtl_output_acl(device_t, struct mbuf *);
+static void btuart_dtl_output_sco(device_t, struct mbuf *);
+
/*
* It doesn't need to be exported, as only btuartattach() uses it,
* but there's no "official" way to make it static.
@@ -191,6 +210,24 @@
sc->sc_unit = hci_attach(&btuart_hci, self, 0);
if (sc->sc_unit == NULL)
aprint_error_dev(self, "HCI attach failed\n");
+
+if (1) {
+ struct hci_if *btuart_dtl_hci =
+ malloc(sizeof(struct hci_if), M_BLUETOOTH, M_ZERO | M_WAITOK);
+
+ memcpy(btuart_dtl_hci, sc->sc_unit->hci_if, sizeof(struct hci_if));
+ btuart_dtl_hci->output_cmd = btuart_dtl_output_cmd;
+ btuart_dtl_hci->output_acl = btuart_dtl_outpu
MIPS Alchemy machine don't boot
Hi! all, This original message posted To: port-mips@ and port-evbmips@ by me. Also this file too. http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/20100105Z/evbmips/binary/sets/kern-OMSAL400.tgz I cannot solve this problem... X-< Thanks, --- original message --- Hi! all My MIPS Alchemy machine(OMSAL400) is reported on the error the other day and doesn't boot. YAMON> go 8010 MIPS32/64 params: cpu arch: 32 MIPS32/64 params: TLB entries: 32 MIPS32/64 params: Icache: line = 32, total = 16384, ways = 4 sets = 128 MIPS32/64 params: Dcache: line = 32, total = 16384, ways = 4 sets = 128 picache_stride= 4096 picache_loopcount = 4 pdcache_stride= 4096 pdcache_loopcount = 4 Dcache is coherent Icache is coherent against Dcache Memory size: 0x0800 pid 0(system): trap: reserved instruction in kernel mode status=0x2, cause=0x80808028, epc=0x8020b8a4, vaddr=0xc7df50df tf=0x804f8de8 ksp =0x804f8e48 ra=0x802e2e58 Stopped in pid 0.1 (system) at 0x8020b8a4: bne t0,zero,0x8020b8c0 bdslot: daddu t2,s7,zero I look the current kernel and the old kernel. The instruction is obviously different. current kernel: 8020b8a0 : 8020b8a0: c088lwc0$8,0(a0) 8020b8a4: 1506bnezt0,8020b8c0 8020b8a8: 02e0502d0x2e0502d 8020b8ac: e08aswc0$10,0(a0) 8020b8b0: 1140fffcbeqzt2,8020b8a4 8020b8b4: c088lwc0$8,0(a0) old kernel: 8020a4ec : 8020a4ec: c088lwc0$8,0(a0) 8020a4f0: 1506bnezt0,8020a50c 8020a4f4: 00175021addut2,zero,s7 8020a4f8: e08aswc0$10,0(a0) 8020a4fc: 1140fffcbeqzt2,8020a4f0 8020a500: c088lwc0$8,0(a0) I do not know to solve this error. Do I only have to specify optional CPUFLAGS? or other better method? Thanks, -- kiyohara Also you can see port-sgim...@... ;-<
