* RE: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Savoy, Pavan @ 2010-10-07 21:53 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: linux-bluetooth@vger.kernel.org, marcel@holtmann.org,
greg@kroah.com, linux-kernel@vger.kernel.org
In-Reply-To: <20101007184534.GB13602@vigoh>
Gustavo / Marcel,
=20
> -----Original Message-----
> From: Gustavo F. Padovan [mailto:pao@profusion.mobi] On Behalf Of Gustavo=
F.
> Padovan
> Sent: Thursday, October 07, 2010 1:46 PM
> To: Savoy, Pavan
> Cc: linux-bluetooth@vger.kernel.org; marcel@holtmann.org; greg@kroah.com;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
>=20
> Hi Pavan,
>=20
> Change the commit subject to "Bluetooth: TI_ST bluetooth driver"
>=20
> * pavan_savoy@ti.com <pavan_savoy@ti.com> [2010-10-07 14:47:16 -0400]:
>=20
> > From: Pavan Savoy <pavan_savoy@ti.com>
> >
> > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > Texas Instrument's WiLink chipsets combine wireless technologies
> > like BT, FM, GPS and WLAN onto a single chip.
> >
> > This Bluetooth driver works on top of the TI_ST shared transport
> > line discipline driver which also allows other drivers like
> > FM V4L2 and GPS character driver to make use of the same UART interface=
.
> >
> > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > ---
> > drivers/bluetooth/bt_ti.c | 489
> +++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 489 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/bluetooth/bt_ti.c
>=20
> We don't have filename with bt_.. in drivers/bluetooth/. Maybe ti_st.c
> should be a better name, or something like that.
>=20
> >
> > diff --git a/drivers/bluetooth/bt_ti.c b/drivers/bluetooth/bt_ti.c
> > new file mode 100644
> > index 0000000..dffbb56
> > --- /dev/null
> > +++ b/drivers/bluetooth/bt_ti.c
> > @@ -0,0 +1,489 @@
> > +/*
> > + * Texas Instrument's Bluetooth Driver For Shared Transport.
> > + *
> > + * Bluetooth Driver acts as interface between HCI CORE and
> > + * TI Shared Transport Layer.
> > + *
> > + * Copyright (C) 2009-2010 Texas Instruments
> > + * Author: Raja Mani <raja_mani@ti.com>
> > + * Pavan Savoy <pavan_savoy@ti.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modi=
fy
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-13=
07
> USA
> > + *
> > + */
> > +
> > +#include <linux/platform_device.h>
> > +#include <net/bluetooth/bluetooth.h>
> > +#include <net/bluetooth/hci_core.h>
> > +
> > +#include <linux/ti_wilink_st.h>
> > +
> > +/* Bluetooth Driver Version */
> > +#define VERSION "1.0"
> > +
> > +/* Defines number of seconds to wait for reg completion
> > + * callback getting called from ST (in case,registration
> > + * with ST returns PENDING status)
> > + */
> > +#define BT_REGISTER_TIMEOUT 6000 /* 6 sec */
> > +
> > +/* BT driver's local status */
> > +#define BT_DRV_RUNNING 0
> > +#define BT_ST_REGISTERED 1
> > +
> > +/**
> > + * struct hci_st - BT driver operation structure
> > + * @hdev: hci device pointer which binds to bt driver
> > + * @flags: used locally,to maintain various BT driver status
> > + * @streg_cbdata: to hold ST registration callback status
> > + * @st_write: write function pointer of ST driver
> > + * @wait_for_btdrv_reg_completion - completion sync between hci_st_ope=
n
> > + * and hci_st_registration_completion_cb.
> > + */
> > +struct hci_st {
> > + struct hci_dev *hdev;
> > + unsigned long flags;
> > + char streg_cbdata;
> > + long (*st_write) (struct sk_buff *);
> > + struct completion wait_for_btdrv_reg_completion;
> > +};
> > +
> > +static int reset;
> > +
> > +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
> > +static inline void hci_st_tx_complete(struct hci_st *hst, int pkt_type=
)
> > +{
> > + struct hci_dev *hdev;
> > + hdev =3D hst->hdev;
> > +
> > + /* Update HCI stat counters */
> > + switch (pkt_type) {
> > + case HCI_COMMAND_PKT:
> > + hdev->stat.cmd_tx++;
> > + break;
> > +
> > + case HCI_ACLDATA_PKT:
> > + hdev->stat.acl_tx++;
> > + break;
> > +
> > + case HCI_SCODATA_PKT:
> > + hdev->stat.cmd_tx++;
>=20
> it should be sco_tx here.
>=20
> > + break;
> > + }
> > +}
> > +
> > +/* ------- Interfaces to Shared Transport ------ */
> > +
> > +/* Called by ST layer to indicate protocol registration completion
> > + * status.hci_st_open() function will wait for signal from this
> > + * API when st_register() function returns ST_PENDING.
> > + */
> > +static void hci_st_registration_completion_cb(void *priv_data, char da=
ta)
>=20
> That is not the hci layer, so rename this function (and the others) to
> something that reflect where they are really doing.
>=20
> > +{
> > + struct hci_st *lhst =3D (struct hci_st *)priv_data;
> > + /* hci_st_open() function needs value of 'data' to know
> > + * the registration status(success/fail),So have a back
> > + * up of it.
> > + */
> > + lhst->streg_cbdata =3D data;
> > +
> > + /* Got a feedback from ST for BT driver registration
> > + * request.Wackup hci_st_open() function to continue
> > + * it's open operation.
> > + */
> > + complete(&lhst->wait_for_btdrv_reg_completion);
> > +}
> > +
> > +/* Called by Shared Transport layer when receive data is
> > + * available */
> > +static long hci_st_receive(void *priv_data, struct sk_buff *skb)
> > +{
> > + int err;
> > + int len;
>=20
> you can put err and len in the same line.
>=20
> > + struct hci_st *lhst =3D (struct hci_st *)priv_data;
> > +
> > + err =3D 0;
> > + len =3D 0;
>=20
> and no need to set them to 0 here.
>=20
> > +
> > + if (skb =3D=3D NULL) {
> > + BT_ERR("Invalid SKB received from ST");
> > + return -EFAULT;
> > + }
>=20
> We need a empty line here.
>=20
> > + if (!lhst) {
> > + kfree_skb(skb);
> > + BT_ERR("Invalid hci_st memory,freeing SKB");
> > + return -EFAULT;
> > + }
>=20
> And also here. Check the rest of the code for similar issues.
>=20
> > + if (!test_bit(BT_DRV_RUNNING, &lhst->flags)) {
> > + kfree_skb(skb);
> > + BT_ERR("Device is not running,freeing SKB");
> > + return -EINVAL;
> > + }
>=20
> If you are here, your device is running, right? Or am I missing
> something?
>=20
> > +
> > + len =3D skb->len;
> > + skb->dev =3D (struct net_device *)lhst->hdev;
> > +
> > + /* Forward skb to HCI CORE layer */
> > + err =3D hci_recv_frame(skb);
> > + if (err) {
> > + kfree_skb(skb);
> > + BT_ERR("Unable to push skb to HCI CORE(%d),freeing SKB",
> > + err);
> > + return err;
> > + }
> > + lhst->hdev->stat.byte_rx +=3D len;
>=20
> actually you even don't need len, just use skb->len
>=20
> > +
> > + return 0;
> > +}
> > +
> > +/* ------- Interfaces to HCI layer ------ */
> > +
> > +/* Called from HCI core to initialize the device */
> > +static int hci_st_open(struct hci_dev *hdev)
> > +{
> > + static struct st_proto_s hci_st_proto;
> > + unsigned long timeleft;
> > + struct hci_st *hst;
> > + int err;
> > + err =3D 0;
> > +
> > + BT_DBG("%s %p", hdev->name, hdev);
> > + hst =3D hdev->driver_data;
> > +
> > + /* Populate BT driver info required by ST */
> > + memset(&hci_st_proto, 0, sizeof(hci_st_proto));
> > +
> > + /* BT driver ID */
> > + hci_st_proto.type =3D ST_BT;
> > +
> > + /* Receive function which called from ST */
> > + hci_st_proto.recv =3D hci_st_receive;
> > +
> > + /* Packet match function may used in future */
> > + hci_st_proto.match_packet =3D NULL;
>=20
> It is already NULL, you dua a memset.
>=20
> > +
> > + /* Callback to be called when registration is pending */
> > + hci_st_proto.reg_complete_cb =3D hci_st_registration_completion_cb;
> > +
> > + /* This is write function pointer of ST. BT driver will make use of
> this
> > + * for sending any packets to chip. ST will assign and give to us, so
> > + * make it as NULL */
> > + hci_st_proto.write =3D NULL;
>=20
> Same here.
>=20
> > +
> > + /* send in the hst to be received at registration complete callback
> > + * and during st's receive
> > + */
> > + hci_st_proto.priv_data =3D hst;
> > +
> > + /* Register with ST layer */
> > + err =3D st_register(&hci_st_proto);
> > + if (err =3D=3D -EINPROGRESS) {
> > + /* Prepare wait-for-completion handler data structures.
> > + * Needed to syncronize this and st_registration_completion_cb()
> > + * functions.
> > + */
> > + init_completion(&hst->wait_for_btdrv_reg_completion);
>=20
> I'm not liking that, but I'll leave for Marcel and others comment.
Thanks for the comments, I will take care of them all, but I want to
tell why I do this here.
"st_register" function takes time. It takes about 2 seconds for us
to download the firmware. (or longer based on UART baud-rate).
This is intended to happen in the process context. Say hciconfig hci0 up
takes a while longer than usual or if someone doing an ioctl(HCIDEVUP)
and this is also the reason I have a callback, as and when firmware downloa=
d
completes, I call the Bluetooth driver's callback.
and I await marcel's comment on this.
> > +
> > + /* Reset ST registration callback status flag , this value
> > + * will be updated in hci_st_registration_completion_cb()
> > + * function whenever it called from ST driver.
> > + */
> > + hst->streg_cbdata =3D -EINPROGRESS;
> > +
> > + /* ST is busy with other protocol registration(may be busy with
> > + * firmware download).So,Wait till the registration callback
> > + * (passed as a argument to st_register() function) getting
> > + * called from ST.
> > + */
> > + BT_DBG(" %s waiting for reg completion signal from ST",
> > + __func__);
> > +
> > + timeleft =3D
> > + wait_for_completion_timeout
> > + (&hst->wait_for_btdrv_reg_completion,
> > + msecs_to_jiffies(BT_REGISTER_TIMEOUT));
> > + if (!timeleft) {
> > + BT_ERR("Timeout(%d sec),didn't get reg"
> > + "completion signal from ST",
> > + BT_REGISTER_TIMEOUT / 1000);
> > + return -ETIMEDOUT;
> > + }
> > +
> > + /* Is ST registration callback called with ERROR value? */
> > + if (hst->streg_cbdata !=3D 0) {
> > + BT_ERR("ST reg completion CB called with invalid"
> > + "status %d", hst->streg_cbdata);
> > + return -EAGAIN;
> > + }
> > + err =3D 0;
> > + } else if (err =3D=3D -1) {
>=20
> Use the proper error macro instead "-1"
>=20
> > + BT_ERR("st_register failed %d", err);
> > + return -EAGAIN;
> > + }
> > +
> > + /* Do we have proper ST write function? */
> > + if (hci_st_proto.write !=3D NULL) {
> > + /* We need this pointer for sending any Bluetooth pkts */
> > + hst->st_write =3D hci_st_proto.write;
> > + } else {
> > + BT_ERR("failed to get ST write func pointer");
> > +
> > + /* Undo registration with ST */
> > + err =3D st_unregister(ST_BT);
> > + if (err < 0)
> > + BT_ERR("st_unregister failed %d", err);
> > +
> > + hst->st_write =3D NULL;
> > + return -EAGAIN;
> > + }
> > +
> > + /* Registration with ST layer is completed successfully,
> > + * now chip is ready to accept commands from HCI CORE.
> > + * Mark HCI Device flag as RUNNING
> > + */
> > + set_bit(HCI_RUNNING, &hdev->flags);
> > +
> > + /* Registration with ST successful */
> > + set_bit(BT_ST_REGISTERED, &hst->flags);
> > +
> > + return err;
> > +}
> > +
> > +/* Close device */
> > +static int hci_st_close(struct hci_dev *hdev)
> > +{
> > + int err;
> > + struct hci_st *hst;
>=20
> Skip a line after declarations.
>=20
> > + err =3D 0;
>=20
> you can set err to 0 in the declaration if you really need that.
>=20
> > +
> > + hst =3D hdev->driver_data;
> > + /* Unregister from ST layer */
> > + if (test_and_clear_bit(BT_ST_REGISTERED, &hst->flags)) {
> > + err =3D st_unregister(ST_BT);
> > + if (err !=3D 0) {
> > + BT_ERR("st_unregister failed %d", err);
> > + return -EBUSY;
> > + }
> > + }
> > +
> > + hst->st_write =3D NULL;
> > +
> > + /* ST layer would have moved chip to inactive state.
> > + * So,clear HCI device RUNNING flag.
> > + */
> > + if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
> > + return 0;
>=20
> Looks you are screwing up the flags here, if it fails on st_unregister()
> and returns HCI_RUNNING should keep set?
>=20
> > +
> > + return err;
>=20
> Rethink how you are doing error handling here, it should no be
> complicated like that.
>=20
> > +}
> > +
> > +/* Called from HCI CORE , Sends frames to Shared Transport */
> > +static int hci_st_send_frame(struct sk_buff *skb)
> > +{
> > + struct hci_dev *hdev;
> > + struct hci_st *hst;
> > + long len;
> > +
> > + if (skb =3D=3D NULL) {
> > + BT_ERR("Invalid skb received from HCI CORE");
> > + return -ENOMEM;
> > + }
> > + hdev =3D (struct hci_dev *)skb->dev;
> > + if (!hdev) {
> > + BT_ERR("SKB received for invalid HCI Device (hdev=3DNULL)");
> > + return -ENODEV;
> > + }
> > + if (!test_bit(HCI_RUNNING, &hdev->flags)) {
> > + BT_ERR("Device is not running");
> > + return -EBUSY;
> > + }
> > +
> > + hst =3D (struct hci_st *)hdev->driver_data;
> > +
> > + /* Prepend skb with frame type */
> > + memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
> > +
> > + BT_DBG(" %s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
> > + skb->len);
> > +
> > + /* Insert skb to shared transport layer's transmit queue.
> > + * Freeing skb memory is taken care in shared transport layer,
> > + * so don't free skb memory here.
> > + */
> > + if (!hst->st_write) {
> > + kfree_skb(skb);
> > + BT_ERR(" Can't write to ST, st_write null?");
> > + return -EAGAIN;
> > + }
> > + len =3D hst->st_write(skb);
> > + if (len < 0) {
> > + /* Something went wrong in st write , free skb memory */
>=20
> IMHO we don't need comments like that, clearly we now that something
> went wrong.
>=20
> > + kfree_skb(skb);
> > + BT_ERR(" ST write failed (%ld)", len);
> > + return -EAGAIN;
> > + }
> > +
> > + /* ST accepted our skb. So, Go ahead and do rest */
> > + hdev->stat.byte_tx +=3D len;
> > + hci_st_tx_complete(hst, bt_cb(skb)->pkt_type);
> > +
> > + return 0;
>=20
> goto might be better to handle error here.
>=20
>=20
> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: XFS causes Kernel trace with Jeremy's pv_ops kernel
From: Jeremy Fitzhardinge @ 2010-10-07 21:53 UTC (permalink / raw)
To: Ulf Kreutzberg; +Cc: xen-devel
In-Reply-To: <4CAD9D97.5070800@hosteurope.de>
On 10/07/2010 03:14 AM, Ulf Kreutzberg wrote:
> Hi Jeremy,
> hi all,
>
>
> I have checked out Jeremy's last git built of dom0 pv_ops kernel 2.6.32.23:
>
> commit 41a85de5caef68bbd58e11ed7b781b7867d96eaa
> Merge: 62bf426... 0ee0f94...
> Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Date: Tue Sep 28 11:20:40 2010 -0700
>
> I have set up on a Dell PE1950 2xDualXeon 5130 an LVM2 partition
> containing XFS. I have built Jeremy's kernel successfully, so the
> running dom0 Kernel is the one mentioned above.
> System is Debian-Lenny, Xen and Xen-tools are self-built.
>
> If I make some I/O, eg:
> cd linux-2.6-xen-git (which is then on the lv with the XFS filesystem)
> make -j 7 ; make install; make -j 7 modules; make modules_install
>
> in dmesg appears a kernel trace after a while. But compiling continues
> and all keeps up and running. This only happens if the kernel is running
> under xen 4.0.2-rc1-pre hypervisor. Nothing strange happens if I run it
> on bare-metal (same machine) without hypervisor.
> I have not tested bonnie or iozone yet.
>
> I have attached booting output of xen 4.0.2-rc1-pre
> as well as the trace (file console-kerneltrace.txt).
> Kernel config is also attached (config-2.6.32.23.txt)
This doesn't look obviously Xen specific. At least at one point XFS was
prone to spurious lockdep warnings that were hard to eliminate. I
wonder if its possible you're seeing this under Xen because of some kind
of timing issue?
Of course it could be Xen related too, but as I said, nothing stands out.
J
> Perhaps you can help. Please let me know if I have forgotten any
> important information.
>
> Many thanks and best regards,
> Ulf Kreutzberg
>
>
> Viele Grüße,
> Ulf
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Mario Limonciello @ 2010-10-07 21:52 UTC (permalink / raw)
To: Matthew Garrett
Cc: Dmitry Torokhov, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <20101007214927.GA2292@srcf.ucam.org>
On Thu, Oct 7, 2010 at 16:49, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Thu, Oct 07, 2010 at 04:45:22PM -0500, Mario Limonciello wrote:
>> Matthew:
>>
>> On Thu, Oct 7, 2010 at 16:42, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> > I don't understand this. You know which code is broken - surely you're
>> > able to determine which products shipped with BIOSes derived from the
>> > broken code?
>>
>> Not all product's BIOS are developed in-house. The ones that are, yes
>> it quite possible to identify. Matter of fact, this issue tends to
>> not exist on the in-house developed BIOS codebase.
>
> Ok, so let's approach this differently. What is it that results in this
> issue not affecting Windows?
>
> --
> Matthew Garrett | mjg59@srcf.ucam.org
>
Depending on the third-party vendor that worked on the BIOS, they may
have an additional method for modifying the wireless and another tool
in addition to the standard one used on a majority of the machines.
That method is not necessarily documented.
--
Mario Limonciello
superm1@gmail.com
^ permalink raw reply
* Re: memory clobber in rx path, maybe related to ath9k.
From: Ben Greear @ 2010-10-07 21:52 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimxp703Gy_Atg8=wpFszRDR=OJCXwOUKRh-a-d7@mail.gmail.com>
On 10/07/2010 02:31 PM, Luis R. Rodriguez wrote:
> On Thu, Oct 7, 2010 at 12:27 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Thu, 2010-10-07 at 12:22 -0700, Ben Greear wrote:
>>
>>> After reboot, and re-run of the script,
>>> I saw this in the logs, and shortly after,
>>> the SLUB poison warning dumped to screen.
>>>
>>> Maybe those DMA errors are serious?
>>
>>> ath: Failed to stop TX DMA in 100 msec after killing last frame
>>> ath: Failed to stop TX DMA. Resetting hardware!
>>
>> That's TX DMA, it can hardly result in invalid memory writes like the
>> ones you've been seeing.
>>
>> I'm still convinced something is wrong with ath9k RX DMA, as you've seen
>> the contents of frames written to already freed memory regions. Since I
>> don't know anything about ath9k, you should probably not rely on me
>> though :-)
>
> I'm on this now. Lets play.
>
> I had to remove /lib/udev/rules.d/75-persistent-net-generator.rules
> to avoid Ubuntu trying to remember the device names and it creating
> stax_rename names.
Right, we disable udev for 'sta*' devices.
> I just ran your script with some modifications. You can find it here:
>
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/scripts/poo.pl
Can you post your kernel .config somewhere, and confirm which
kernel you are using?
Also, what ath9k NIC, platform, etc?
We see the problem on two different systems (haven't tried more). I can
figure out the brands of the NICs if that helps, and have included
lspci information below.
I've uploaded my kernel config to here:
http://www.candelatech.com/~greearb/ctwl_kernel.cfg
* Dual core Intel Pentium-D 32-bit
2GB RAM
Fedora 13 (but with custom compiled top-of-tree iw, hostap, libnl
Atheros NIC: from lspci -vv:
08:01.0 Network controller: Atheros Communications Inc. AR922X Wireless Network Adapter (rev 01)
Subsystem: Device 0777:4002
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B+ DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 17
Region 0: Memory at d0300000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=100mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel modules: ath9k
* Dual-core Intel Atom, 32-bit
1GB RAM
Fedora 13 (custom compiled top-of-tree iw, hostap, libnl)
Atheros mini-pcie NIC, from lspci -vv:
03:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
Subsystem: Device 0777:4e05
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at febf0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM unknown, Latency L0 <512ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [90] MSI-X: Enable- Count=1 Masked-
Vector table: BAR=0 offset=00000000
PBA: BAR=0 offset=00000000
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntrySize=0
Arb: Fixed- WRR32- WRR64- WRR128- 100ns- onfig- - - TableOffset=0
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Fixed- RR32-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: ath9k
Kernel modules: ath9k
>
> I then ran:
>
> for i in $(seq 0 31) ; do sudo dhclient seq$i; done
>
> It took about 10 minutes to get IP addresses for all interfaces but it
> got there eventually. Odd enough I was unable to ping the AP from any
> interface though. Not sure what that was about. But I got no oops, no
> slub dump. All I got was some more delba warnings which seems to
> indicate we haven't caught all the cases for its use:
If you just create one or two interfaces, can you ping as expected?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3/3] compat-wireless: backport kfifo for rt2x00
From: Luis R. Rodriguez @ 2010-10-07 21:51 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1286486469-18904-3-git-send-email-hauke@hauke-m.de>
On Thu, Oct 7, 2010 at 2:21 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied all 3 thanks!!!
Luis
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 21:50 UTC (permalink / raw)
To: Mike Frysinger
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <AANLkTimPrvj=NkJ0eN5kAmRTNof1N2nfo4U-THRnqikF@mail.gmail.com>
On Thu, 2010-10-07 at 17:32 -0400, Mike Frysinger wrote:
> > Ideally you would want this driver to work in any situation .. If it's
> > setup to use ttyS0 for debugging, even if it doesn't exist, then this
> > driver would be able to stand in for that interface.
>
> i dont think that's the case. "any situation" is way too vague and
> invites mounds of crap to be included in the kernel which really
> should be in userspace. ive never had a problem with my embedded work
> using ttyBF# or ttyBFJC# or ttySS# for the Blackfin serial devices,
> nor have i heard customers complain that the file absolutely must be
> named "ttyS#". ive found that simply informing them "to use ttyBF#"
> has always been sufficient.
> -mike
It's kind of a "your milage may vary" situation .. From my perspective
it doesn't hurt anything to have an exception for this, considering what
it is used for.
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Matthew Garrett @ 2010-10-07 21:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mario Limonciello, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <20101007214628.GB18628@core.coreip.homeip.net>
On Thu, Oct 07, 2010 at 02:46:28PM -0700, Dmitry Torokhov wrote:
> On Thu, Oct 07, 2010 at 10:37:54PM +0100, Matthew Garrett wrote:
> > Dell laptop driver is reasonable. All we need is a list of hardware, and
> > I'd really hope that Dell know which BIOS versions contain this code!
> >
>
> Unfortunately this kind of crap tends to flow from one BIOS version to
> another.. How many DMI entries do we know about so far? Did Dell issue
> firmware updates correcting the issue so new boxes will not exhibit the
> problem?
Pushing this out to userspace doesn't help. If it's sufficiently
prevelant that it's impossible to have a comprehensive list, then a
module option makes it too easy for people to just post the fix on a
forum somewhere and never actually get it upstream.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH 2/2] compat: rename member in struct mmc_host.
From: Luis R. Rodriguez @ 2010-10-07 21:49 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1286486544-18975-2-git-send-email-hauke@hauke-m.de>
On Thu, Oct 7, 2010 at 2:22 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied the two patches, thanks!
Luis
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Mario Limonciello @ 2010-10-07 21:49 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Matthew Garrett, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <20101007214628.GB18628@core.coreip.homeip.net>
Hi Dmitry:
On Thu, Oct 7, 2010 at 16:46, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Thu, Oct 07, 2010 at 10:37:54PM +0100, Matthew Garrett wrote:
>> On Thu, Oct 07, 2010 at 02:30:28PM -0700, Dmitry Torokhov wrote:
>>
>> > We have this strategy for bunch of input stuff (force release, keymap)
>> > and I think it works better than dding more and more DMI quirks into
>> > kernel itself.
>>
>> It's limited to Dell hardware, so I think keeping a static list in the
>> Dell laptop driver is reasonable. All we need is a list of hardware, and
>> I'd really hope that Dell know which BIOS versions contain this code!
>>
>
> Unfortunately this kind of crap tends to flow from one BIOS version to
> another.. How many DMI entries do we know about so far? Did Dell issue
> firmware updates correcting the issue so new boxes will not exhibit the
> problem?
>
> --
> Dmitry
>
I've seen this on 2 machines thus far. One of them is still under
development and this was caught in time to be fixed properly in the
firmware (thanks to the patch above). The other will not be receiving
a firmware update to resolve it.
There are likely others out there, but I've not encountered them yet.
--
Mario Limonciello
superm1@gmail.com
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Matthew Garrett @ 2010-10-07 21:49 UTC (permalink / raw)
To: Mario Limonciello
Cc: Dmitry Torokhov, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <AANLkTimh649Lhj-sBYzViq_G-2Bva0U-TPCMGfSdK=QE@mail.gmail.com>
On Thu, Oct 07, 2010 at 04:45:22PM -0500, Mario Limonciello wrote:
> Matthew:
>
> On Thu, Oct 7, 2010 at 16:42, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > I don't understand this. You know which code is broken - surely you're
> > able to determine which products shipped with BIOSes derived from the
> > broken code?
>
> Not all product's BIOS are developed in-house. The ones that are, yes
> it quite possible to identify. Matter of fact, this issue tends to
> not exist on the in-house developed BIOS codebase.
Ok, so let's approach this differently. What is it that results in this
issue not affecting Windows?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Yehuda Sadeh Weinraub @ 2010-10-07 21:49 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, ceph-devel, qemu-devel, kvm, Christian Brunner
In-Reply-To: <4CAE35C5.2010809@codemonkey.ws>
On Thu, Oct 7, 2010 at 2:04 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 10/07/2010 03:47 PM, Yehuda Sadeh Weinraub wrote:
>>>
>>> How is that possible? Are the callbacks delivered in the context of a
>>> different thread? If so, don't you need locking?
>>>
>>
>> Not sure I'm completely following you. The callbacks are delivered in
>> the context of a different thread, but won't run concurrently.
>
> Concurrently to what? How do you prevent them from running concurrently
> with qemu?
There are two types of callbacks. The first is for rados aio
completions, and the second one is the one added later for the fd glue
layer.
The first callback, called by librados whenever aio completes, runs in
the context of a single librados thread:
+static void rbd_finish_aiocb(rados_completion_t c, RADOSCB *rcb)
+{
+ RBDAIOCB *acb = rcb->acb;
rcb is per a single aio. Was created before and will be destroyed
here, whereas acb is shared between a few aios, however, it was
generated before the first aio was created.
+ int64_t r;
+ uint64_t buf = 1;
+ int i;
+
+ acb->aiocnt--;
acb->aiocnt has been set before initiating all the aios, so it's ok to
touch it now. Same goes to all acb fields.
+ r = rados_aio_get_return_value(c);
+ rados_aio_release(c);
+ if (acb->write) {
+ if (r < 0) {
+ acb->ret = r;
+ acb->error = 1;
+ } else if (!acb->error) {
+ acb->ret += rcb->segsize;
+ }
+ } else {
+ if (r == -ENOENT) {
+ memset(rcb->buf, 0, rcb->segsize);
+ if (!acb->error) {
+ acb->ret += rcb->segsize;
+ }
+ } else if (r < 0) {
+ acb->ret = r;
+ acb->error = 1;
+ } else if (r < rcb->segsize) {
+ memset(rcb->buf + r, 0, rcb->segsize - r);
+ if (!acb->error) {
+ acb->ret += rcb->segsize;
+ }
+ } else if (!acb->error) {
+ acb->ret += r;
+ }
+ }
+ if (write(acb->s->efd, &buf, sizeof(buf)) < 0)
This will wake up the io_read()
+ error_report("failed writing to acb->s->efd\n");
+ qemu_free(rcb);
+ i = 0;
+ if (!acb->aiocnt && acb->bh) {
+ qemu_bh_schedule(acb->bh);
This is the only qemu related call in here, seems safe to call it.
+ }
+}
The scheduled bh function will be called only after all aios that
relate to this specific aio set are done, so the following seems ok,
as there's no more acb references.
+static void rbd_aio_bh_cb(void *opaque)
+{
+ RBDAIOCB *acb = opaque;
+ uint64_t buf = 1;
+
+ if (!acb->write) {
+ qemu_iovec_from_buffer(acb->qiov, acb->bounce, acb->qiov->size);
+ }
+ qemu_vfree(acb->bounce);
+ acb->common.cb(acb->common.opaque, (acb->ret > 0 ? 0 : acb->ret));
+ qemu_bh_delete(acb->bh);
+ acb->bh = NULL;
+
+ if (write(acb->s->efd, &buf, sizeof(buf)) < 0)
+ error_report("failed writing to acb->s->efd\n");
+ qemu_aio_release(acb);
+}
Now, the second ones are the io_read(), in which we have our glue fd.
We send uint64 per each completed io
+static void rbd_aio_completion_cb(void *opaque)
+{
+ BDRVRBDState *s = opaque;
+
+ uint64_t val;
+ ssize_t ret;
+
+ do {
+ if ((ret = read(s->efd, &val, sizeof(val))) > 0) {
+ s->qemu_aio_count -= val;
There is an issue here with s->qemu_aio_count which needs to be
protected by a mutex. Other than that, it just reads from s->efd.
+ }
+ } while (ret < 0 && errno == EINTR);
+
+ return;
+}
+
+static int rbd_aio_flush_cb(void *opaque)
+{
+ BDRVRBDState *s = opaque;
+
+ return (s->qemu_aio_count > 0);
Same here as with the previous one, needs a mutex around s->qemu_aio_count.
+}
>
> If you saw lock ups, I bet that's what it was from.
>
As I explained before, before introducing the fd glue layer, the lack
of fd associated with our block device caused that there was no way
for qemu to check whether all aios were flushed or not, which didn't
work well when doing migration/savevm.
Thanks,
Yehuda
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Yehuda Sadeh Weinraub @ 2010-10-07 21:49 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, kvm, qemu-devel, ceph-devel, Christian Brunner
In-Reply-To: <4CAE35C5.2010809@codemonkey.ws>
On Thu, Oct 7, 2010 at 2:04 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 10/07/2010 03:47 PM, Yehuda Sadeh Weinraub wrote:
>>>
>>> How is that possible? Are the callbacks delivered in the context of a
>>> different thread? If so, don't you need locking?
>>>
>>
>> Not sure I'm completely following you. The callbacks are delivered in
>> the context of a different thread, but won't run concurrently.
>
> Concurrently to what? How do you prevent them from running concurrently
> with qemu?
There are two types of callbacks. The first is for rados aio
completions, and the second one is the one added later for the fd glue
layer.
The first callback, called by librados whenever aio completes, runs in
the context of a single librados thread:
+static void rbd_finish_aiocb(rados_completion_t c, RADOSCB *rcb)
+{
+ RBDAIOCB *acb = rcb->acb;
rcb is per a single aio. Was created before and will be destroyed
here, whereas acb is shared between a few aios, however, it was
generated before the first aio was created.
+ int64_t r;
+ uint64_t buf = 1;
+ int i;
+
+ acb->aiocnt--;
acb->aiocnt has been set before initiating all the aios, so it's ok to
touch it now. Same goes to all acb fields.
+ r = rados_aio_get_return_value(c);
+ rados_aio_release(c);
+ if (acb->write) {
+ if (r < 0) {
+ acb->ret = r;
+ acb->error = 1;
+ } else if (!acb->error) {
+ acb->ret += rcb->segsize;
+ }
+ } else {
+ if (r == -ENOENT) {
+ memset(rcb->buf, 0, rcb->segsize);
+ if (!acb->error) {
+ acb->ret += rcb->segsize;
+ }
+ } else if (r < 0) {
+ acb->ret = r;
+ acb->error = 1;
+ } else if (r < rcb->segsize) {
+ memset(rcb->buf + r, 0, rcb->segsize - r);
+ if (!acb->error) {
+ acb->ret += rcb->segsize;
+ }
+ } else if (!acb->error) {
+ acb->ret += r;
+ }
+ }
+ if (write(acb->s->efd, &buf, sizeof(buf)) < 0)
This will wake up the io_read()
+ error_report("failed writing to acb->s->efd\n");
+ qemu_free(rcb);
+ i = 0;
+ if (!acb->aiocnt && acb->bh) {
+ qemu_bh_schedule(acb->bh);
This is the only qemu related call in here, seems safe to call it.
+ }
+}
The scheduled bh function will be called only after all aios that
relate to this specific aio set are done, so the following seems ok,
as there's no more acb references.
+static void rbd_aio_bh_cb(void *opaque)
+{
+ RBDAIOCB *acb = opaque;
+ uint64_t buf = 1;
+
+ if (!acb->write) {
+ qemu_iovec_from_buffer(acb->qiov, acb->bounce, acb->qiov->size);
+ }
+ qemu_vfree(acb->bounce);
+ acb->common.cb(acb->common.opaque, (acb->ret > 0 ? 0 : acb->ret));
+ qemu_bh_delete(acb->bh);
+ acb->bh = NULL;
+
+ if (write(acb->s->efd, &buf, sizeof(buf)) < 0)
+ error_report("failed writing to acb->s->efd\n");
+ qemu_aio_release(acb);
+}
Now, the second ones are the io_read(), in which we have our glue fd.
We send uint64 per each completed io
+static void rbd_aio_completion_cb(void *opaque)
+{
+ BDRVRBDState *s = opaque;
+
+ uint64_t val;
+ ssize_t ret;
+
+ do {
+ if ((ret = read(s->efd, &val, sizeof(val))) > 0) {
+ s->qemu_aio_count -= val;
There is an issue here with s->qemu_aio_count which needs to be
protected by a mutex. Other than that, it just reads from s->efd.
+ }
+ } while (ret < 0 && errno == EINTR);
+
+ return;
+}
+
+static int rbd_aio_flush_cb(void *opaque)
+{
+ BDRVRBDState *s = opaque;
+
+ return (s->qemu_aio_count > 0);
Same here as with the previous one, needs a mutex around s->qemu_aio_count.
+}
>
> If you saw lock ups, I bet that's what it was from.
>
As I explained before, before introducing the fd glue layer, the lack
of fd associated with our block device caused that there was no way
for qemu to check whether all aios were flushed or not, which didn't
work well when doing migration/savevm.
Thanks,
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] eglibc-package.bbclass: fix missing RPROVIDES for virtual-locale-*
From: Khem Raj @ 2010-10-07 21:48 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1286480697-28494-1-git-send-email-Martin.Jansa@gmail.com>
On Thu, Oct 7, 2010 at 12:44 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
seems fine
Acked-by: Khem Raj <raj.khem@gmail.com>
> ---
> recipes/eglibc/eglibc-package.bbclass | 4 +++-
> recipes/eglibc/eglibc.inc | 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/recipes/eglibc/eglibc-package.bbclass b/recipes/eglibc/eglibc-package.bbclass
> index 5871be0..dbca1ab 100644
> --- a/recipes/eglibc/eglibc-package.bbclass
> +++ b/recipes/eglibc/eglibc-package.bbclass
> @@ -351,7 +351,9 @@ python package_do_split_gconvs () {
> else:
> glibc_name = name
> bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('eglibc-binary-localedata-%s' % glibc_name), d)
> - bb.data.setVar('RPROVIDES_%s' % pkgname, 'glibc-binary-localedata-%s' % glibc_name, d)
> + rprovides = bb.data.getVar("RPROVIDES_%s" % pkgname, d, 1)
> + rprovides += ' glibc-binary-localedata-%s' % glibc_name
> + bb.data.setVar('RPROVIDES_%s' % pkgname, rprovides, d)
>
> def output_locale_binary(name, pkgname, locale, encoding):
> # This is a hack till linux-libc-headers gets patched for the missing arm syscalls and all arm device kernels as well
> diff --git a/recipes/eglibc/eglibc.inc b/recipes/eglibc/eglibc.inc
> index a68f343..754a12b 100644
> --- a/recipes/eglibc/eglibc.inc
> +++ b/recipes/eglibc/eglibc.inc
> @@ -3,7 +3,7 @@ HOMEPAGE = "http://www.eglibc.org/home"
> SECTION = "libs"
> PRIORITY = "required"
> LICENSE = "LGPL"
> -INC_PR = "r14"
> +INC_PR = "r15"
> # nptl needs unwind support in gcc, which can't be built without glibc.
> DEPENDS = "virtual/${TARGET_PREFIX}gcc-intermediate linux-libc-headers"
> #this leads to circular deps, so lets not add it yet
> --
> 1.7.3.1
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
^ permalink raw reply
* Re: [PATCH v4] compat: backport netlink changes used in the nl80211 cleanup
From: Luis R. Rodriguez @ 2010-10-07 21:48 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <4CAE25F6.2010707@openwrt.org>
On Thu, Oct 7, 2010 at 12:56 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
applied, thanks!!!
Luis
^ permalink raw reply
* [U-Boot] [PATCH V5 2/2] ARMV7: Fixed baudrate setting in pl01x driver
From: matt.waddel at linaro.org @ 2010-10-07 21:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1280373167-20890-2-git-send-email-matt.waddel@linaro.org>
From: Matt Waddel <matt.waddel@linaro.org>
The pl01x serial driver was lacking the code to switch baudrates from the
command line. Fixed by simply saving the new baudrate and calling
serial_init() again. Also fixed CamelCase variables, I/O accessors and
comment style.
Signed-off-by: Matt Waddel <matt.waddel@linaro.org>
---
drivers/serial/serial_pl01x.c | 93 +++++++++++++++++------------------------
1 files changed, 38 insertions(+), 55 deletions(-)
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index c645cef..c0ae947 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -29,25 +29,23 @@
#include <common.h>
#include <watchdog.h>
-
+#include <asm/io.h>
#include "serial_pl01x.h"
-#define IO_WRITE(addr, val) (*(volatile unsigned int *)(addr) = (val))
-#define IO_READ(addr) (*(volatile unsigned int *)(addr))
-
/*
* Integrator AP has two UARTs, we use the first one, at 38400-8-N-1
* Integrator CP has two UARTs, use the first one, at 38400-8-N-1
* Versatile PB has four UARTs.
*/
#define CONSOLE_PORT CONFIG_CONS_INDEX
-#define baudRate CONFIG_BAUDRATE
static volatile unsigned char *const port[] = CONFIG_PL01x_PORTS;
#define NUM_PORTS (sizeof(port)/sizeof(port[0]))
static void pl01x_putc (int portnum, char c);
static int pl01x_getc (int portnum);
static int pl01x_tstc (int portnum);
+unsigned int baudrate = CONFIG_BAUDRATE;
+DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_PL010_SERIAL
@@ -55,16 +53,11 @@ int serial_init (void)
{
unsigned int divisor;
- /*
- ** First, disable everything.
- */
- IO_WRITE (port[CONSOLE_PORT] + UART_PL010_CR, 0x0);
+ /* First, disable everything */
+ writel(0x0, port[CONSOLE_PORT] + UART_PL010_CR);
- /*
- ** Set baud rate
- **
- */
- switch (baudRate) {
+ /* Set baud rate */
+ switch (baudrate) {
case 9600:
divisor = UART_PL010_BAUD_9600;
break;
@@ -89,20 +82,15 @@ int serial_init (void)
divisor = UART_PL010_BAUD_38400;
}
- IO_WRITE (port[CONSOLE_PORT] + UART_PL010_LCRM,
- ((divisor & 0xf00) >> 8));
- IO_WRITE (port[CONSOLE_PORT] + UART_PL010_LCRL, (divisor & 0xff));
+ writel(((divisor & 0xf00) >> 8), port[CONSOLE_PORT] + UART_PL010_LCRM);
+ writel((divisor & 0xff), port[CONSOLE_PORT] + UART_PL010_LCRL);
- /*
- ** Set the UART to be 8 bits, 1 stop bit, no parity, fifo enabled.
- */
- IO_WRITE (port[CONSOLE_PORT] + UART_PL010_LCRH,
- (UART_PL010_LCRH_WLEN_8 | UART_PL010_LCRH_FEN));
+ /* Set the UART to be 8 bits, 1 stop bit, no parity, fifo enabled */
+ writel((UART_PL010_LCRH_WLEN_8 | UART_PL010_LCRH_FEN),
+ port[CONSOLE_PORT] + UART_PL010_LCRH);
- /*
- ** Finally, enable the UART
- */
- IO_WRITE (port[CONSOLE_PORT] + UART_PL010_CR, (UART_PL010_CR_UARTEN));
+ /* Finally, enable the UART */
+ writel((UART_PL010_CR_UARTEN), port[CONSOLE_PORT] + UART_PL010_CR);
return 0;
}
@@ -118,38 +106,31 @@ int serial_init (void)
unsigned int remainder;
unsigned int fraction;
- /*
- ** First, disable everything.
- */
- IO_WRITE (port[CONSOLE_PORT] + UART_PL011_CR, 0x0);
+ /* First, disable everything */
+ writel(0x0, port[CONSOLE_PORT] + UART_PL011_CR);
/*
- ** Set baud rate
- **
- ** IBRD = UART_CLK / (16 * BAUD_RATE)
- ** FBRD = ROUND((64 * MOD(UART_CLK,(16 * BAUD_RATE))) / (16 * BAUD_RATE))
+ * Set baud rate
+ *
+ * IBRD = UART_CLK / (16 * BAUD_RATE)
+ * FBRD = RND((64 * MOD(UART_CLK,(16 * BAUD_RATE))) / (16 * BAUD_RATE))
*/
- temp = 16 * baudRate;
+ temp = 16 * baudrate;
divider = CONFIG_PL011_CLOCK / temp;
remainder = CONFIG_PL011_CLOCK % temp;
- temp = (8 * remainder) / baudRate;
+ temp = (8 * remainder) / baudrate;
fraction = (temp >> 1) + (temp & 1);
- IO_WRITE (port[CONSOLE_PORT] + UART_PL011_IBRD, divider);
- IO_WRITE (port[CONSOLE_PORT] + UART_PL011_FBRD, fraction);
+ writel(divider, port[CONSOLE_PORT] + UART_PL011_IBRD);
+ writel(fraction, port[CONSOLE_PORT] + UART_PL011_FBRD);
- /*
- ** Set the UART to be 8 bits, 1 stop bit, no parity, fifo enabled.
- */
- IO_WRITE (port[CONSOLE_PORT] + UART_PL011_LCRH,
- (UART_PL011_LCRH_WLEN_8 | UART_PL011_LCRH_FEN));
+ /* Set the UART to be 8 bits, 1 stop bit, no parity, fifo enabled */
+ writel((UART_PL011_LCRH_WLEN_8 | UART_PL011_LCRH_FEN),
+ port[CONSOLE_PORT] + UART_PL011_LCRH);
- /*
- ** Finally, enable the UART
- */
- IO_WRITE (port[CONSOLE_PORT] + UART_PL011_CR,
- (UART_PL011_CR_UARTEN | UART_PL011_CR_TXE |
- UART_PL011_CR_RXE));
+ /* Finally, enable the UART */
+ writel((UART_PL011_CR_UARTEN | UART_PL011_CR_TXE | UART_PL011_CR_RXE),
+ port[CONSOLE_PORT] + UART_PL011_CR);
return 0;
}
@@ -183,16 +164,18 @@ int serial_tstc (void)
void serial_setbrg (void)
{
+ baudrate = gd->baudrate;
+ serial_init();
}
static void pl01x_putc (int portnum, char c)
{
/* Wait until there is space in the FIFO */
- while (IO_READ (port[portnum] + UART_PL01x_FR) & UART_PL01x_FR_TXFF)
+ while (readl(port[portnum] + UART_PL01x_FR) & UART_PL01x_FR_TXFF)
WATCHDOG_RESET();
/* Send the character */
- IO_WRITE (port[portnum] + UART_PL01x_DR, c);
+ writel(c, port[portnum] + UART_PL01x_DR);
}
static int pl01x_getc (int portnum)
@@ -200,15 +183,15 @@ static int pl01x_getc (int portnum)
unsigned int data;
/* Wait until there is data in the FIFO */
- while (IO_READ (port[portnum] + UART_PL01x_FR) & UART_PL01x_FR_RXFE)
+ while (readl(port[portnum] + UART_PL01x_FR) & UART_PL01x_FR_RXFE)
WATCHDOG_RESET();
- data = IO_READ (port[portnum] + UART_PL01x_DR);
+ data = readl(port[portnum] + UART_PL01x_DR);
/* Check for an error flag */
if (data & 0xFFFFFF00) {
/* Clear the error */
- IO_WRITE (port[portnum] + UART_PL01x_ECR, 0xFFFFFFFF);
+ writel(0xFFFFFFFF, port[portnum] + UART_PL01x_ECR);
return -1;
}
@@ -218,6 +201,6 @@ static int pl01x_getc (int portnum)
static int pl01x_tstc (int portnum)
{
WATCHDOG_RESET();
- return !(IO_READ (port[portnum] + UART_PL01x_FR) &
+ return !(readl(port[portnum] + UART_PL01x_FR) &
UART_PL01x_FR_RXFE);
}
--
1.7.1
^ permalink raw reply related
* [U-Boot] [PATCH V5 1/2] ARMV7: Versatile Express Coretile CortexA9x4 support
From: matt.waddel at linaro.org @ 2010-10-07 21:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1280373167-20890-2-git-send-email-matt.waddel@linaro.org>
From: Matt Waddel <matt.waddel@linaro.org>
Adds support for the ARM quad-core Cortex-A9 processor
This system includes a motherboard(Versatile Express), daughterboard
(Coretile), and SOC(Cortex-A9 quad core). The serial port, ethernet,
and flash systems work with these additions. The naming convention
is:
SOC -> CortexA9 quad core = ca9x4
daughterboard -> Coretile = ct
motherboard -> Versatile Express = vxp
This gives ca9x4_ct_vxp.c as the board support file.
Signed-off-by: Matt Waddel <matt.waddel@linaro.org>
---
MAINTAINERS | 4 +
MAKEALL | 1 +
arch/arm/include/asm/arch-armv7/sysctrl.h | 70 +++++++++
arch/arm/include/asm/arch-armv7/systimer.h | 50 +++++++
arch/arm/include/asm/arch-armv7/wdt.h | 55 +++++++
board/armltd/vexpress/Makefile | 49 ++++++
board/armltd/vexpress/ca9x4_ct_vxp.c | 220 ++++++++++++++++++++++++++++
board/armltd/vexpress/config.mk | 23 +++
board/armltd/vexpress/u-boot.lds | 65 ++++++++
boards.cfg | 1 +
include/configs/ca9x4_ct_vxp.h | 196 +++++++++++++++++++++++++
11 files changed, 734 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-armv7/sysctrl.h
create mode 100644 arch/arm/include/asm/arch-armv7/systimer.h
create mode 100644 arch/arm/include/asm/arch-armv7/wdt.h
create mode 100644 board/armltd/vexpress/Makefile
create mode 100644 board/armltd/vexpress/ca9x4_ct_vxp.c
create mode 100644 board/armltd/vexpress/config.mk
create mode 100644 board/armltd/vexpress/u-boot.lds
create mode 100644 include/configs/ca9x4_ct_vxp.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 5e3a3fa..71dcd5b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -802,6 +802,10 @@ Hugo Villeneuve <hugo.villeneuve@lyrtech.com>
SFFSDR ARM926EJS
+Matt Waddel <matt.waddel@linaro.org>
+
+ ca9x4_ct_vxp ARM ARMV7 (Quad Core)
+
Prafulla Wadaskar <prafulla@marvell.com>
mv88f6281gtw_ge ARM926EJS (Kirkwood SoC)
diff --git a/MAKEALL b/MAKEALL
index 1b506d6..abceccd 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -489,6 +489,7 @@ LIST_ARM11=" \
#########################################################################
LIST_ARMV7=" \
am3517_evm \
+ ca9x4_ct_vxp \
devkit8000 \
mx51evk \
omap3_beagle \
diff --git a/arch/arm/include/asm/arch-armv7/sysctrl.h b/arch/arm/include/asm/arch-armv7/sysctrl.h
new file mode 100644
index 0000000..4e45167
--- /dev/null
+++ b/arch/arm/include/asm/arch-armv7/sysctrl.h
@@ -0,0 +1,70 @@
+/*
+ * (C) Copyright 2010 Linaro
+ * Matt Waddel, <matt.waddel@linaro.org>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#ifndef _SYSCTRL_H_
+#define _SYSCTRL_H_
+
+/* System controller (SP810) register definitions */
+#define SP810_TIMER0_ENSEL (1 << 15)
+#define SP810_TIMER1_ENSEL (1 << 17)
+#define SP810_TIMER2_ENSEL (1 << 19)
+#define SP810_TIMER3_ENSEL (1 << 21)
+
+struct sysctrl {
+ u32 scctrl; /* 0x000 */
+ u32 scsysstat;
+ u32 scimctrl;
+ u32 scimstat;
+ u32 scxtalctrl;
+ u32 scpllctrl;
+ u32 scpllfctrl;
+ u32 scperctrl0;
+ u32 scperctrl1;
+ u32 scperen;
+ u32 scperdis;
+ u32 scperclken;
+ u32 scperstat;
+ u32 res1[0x006];
+ u32 scflashctrl; /* 0x04c */
+ u32 res2[0x3a4];
+ u32 scsysid0; /* 0xee0 */
+ u32 scsysid1;
+ u32 scsysid2;
+ u32 scsysid3;
+ u32 scitcr;
+ u32 scitir0;
+ u32 scitir1;
+ u32 scitor;
+ u32 sccntctrl;
+ u32 sccntdata;
+ u32 sccntstep;
+ u32 res3[0x32];
+ u32 scperiphid0; /* 0xfe0 */
+ u32 scperiphid1;
+ u32 scperiphid2;
+ u32 scperiphid3;
+ u32 scpcellid0;
+ u32 scpcellid1;
+ u32 scpcellid2;
+ u32 scpcellid3;
+};
+#endif /* _SYSCTRL_H_ */
diff --git a/arch/arm/include/asm/arch-armv7/systimer.h b/arch/arm/include/asm/arch-armv7/systimer.h
new file mode 100644
index 0000000..e745e37
--- /dev/null
+++ b/arch/arm/include/asm/arch-armv7/systimer.h
@@ -0,0 +1,50 @@
+/*
+ * (C) Copyright 2010 Linaro
+ * Matt Waddel, <matt.waddel@linaro.org>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#ifndef _SYSTIMER_H_
+#define _SYSTIMER_H_
+
+/* AMBA timer register base address */
+#define SYSTIMER_BASE 0x10011000
+
+#define SYSHZ_CLOCK 1000000 /* Timers -> 1Mhz */
+#define SYSTIMER_RELOAD 0xFFFFFFFF
+#define SYSTIMER_EN (1 << 7)
+#define SYSTIMER_32BIT (1 << 1)
+
+struct systimer {
+ u32 timer0load; /* 0x00 */
+ u32 timer0value;
+ u32 timer0control;
+ u32 timer0intclr;
+ u32 timer0ris;
+ u32 timer0mis;
+ u32 timer0bgload;
+ u32 timer1load; /* 0x20 */
+ u32 timer1value;
+ u32 timer1control;
+ u32 timer1intclr;
+ u32 timer1ris;
+ u32 timer1mis;
+ u32 timer1bgload;
+};
+#endif /* _SYSTIMER_H_ */
diff --git a/arch/arm/include/asm/arch-armv7/wdt.h b/arch/arm/include/asm/arch-armv7/wdt.h
new file mode 100644
index 0000000..ee74c38
--- /dev/null
+++ b/arch/arm/include/asm/arch-armv7/wdt.h
@@ -0,0 +1,55 @@
+/*
+ * (C) Copyright 2010
+ * Matt Waddel, <matt.waddel@linaro.org>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#ifndef _WDT_H_
+#define _WDT_H_
+
+/* Watchdog timer (SP805) register base address */
+#define WDT_BASE 0x100E5000
+
+#define WDT_EN 0x2
+#define WDT_RESET_LOAD 0x0
+
+struct wdt {
+ u32 wdogload; /* 0x000 */
+ u32 wdogvalue;
+ u32 wdogcontrol;
+ u32 wdogintclr;
+ u32 wdogris;
+ u32 wdogmis;
+ u32 res1[0x2F9];
+ u32 wdoglock; /* 0xC00 */
+ u32 res2[0xBE];
+ u32 wdogitcr; /* 0xF00 */
+ u32 wdogitop;
+ u32 res3[0x35];
+ u32 wdogperiphid0; /* 0xFE0 */
+ u32 wdogperiphid1;
+ u32 wdogperiphid2;
+ u32 wdogperiphid3;
+ u32 wdogpcellid0;
+ u32 wdogpcellid1;
+ u32 wdogpcellid2;
+ u32 wdogpcellid3;
+};
+
+#endif /* _WDT_H_ */
diff --git a/board/armltd/vexpress/Makefile b/board/armltd/vexpress/Makefile
new file mode 100644
index 0000000..ee5c0d8
--- /dev/null
+++ b/board/armltd/vexpress/Makefile
@@ -0,0 +1,49 @@
+#
+# (C) Copyright 2000-2004
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(BOARD).a
+
+COBJS := ca9x4_ct_vxp.o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB): $(obj).depend $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/armltd/vexpress/ca9x4_ct_vxp.c b/board/armltd/vexpress/ca9x4_ct_vxp.c
new file mode 100644
index 0000000..cd334d4
--- /dev/null
+++ b/board/armltd/vexpress/ca9x4_ct_vxp.c
@@ -0,0 +1,220 @@
+/*
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH <www.elinos.com>
+ * Marius Groeger <mgroeger@sysgo.de>
+ *
+ * (C) Copyright 2002
+ * David Mueller, ELSOFT AG, <d.mueller@elsoft.ch>
+ *
+ * (C) Copyright 2003
+ * Texas Instruments, <www.ti.com>
+ * Kshitij Gupta <Kshitij@ti.com>
+ *
+ * (C) Copyright 2004
+ * ARM Ltd.
+ * Philippe Robin, <philippe.robin@arm.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include <common.h>
+#include <netdev.h>
+#include <asm/io.h>
+#include <asm/arch/systimer.h>
+#include <asm/arch/sysctrl.h>
+#include <asm/arch/wdt.h>
+
+static ulong timestamp;
+static ulong lastdec;
+
+static struct wdt *wdt_base = (struct wdt *)WDT_BASE;
+static struct systimer *systimer_base = (struct systimer *)SYSTIMER_BASE;
+static struct sysctrl *sysctrl_base = (struct sysctrl *)SCTL_BASE;
+
+static void flash__init(void);
+static void vexpress_timer_init(void);
+DECLARE_GLOBAL_DATA_PTR;
+
+#if defined(CONFIG_SHOW_BOOT_PROGRESS)
+void show_boot_progress(int progress)
+{
+ printf("Boot reached stage %d\n", progress);
+}
+#endif
+
+static inline void delay(ulong loops)
+{
+ __asm__ volatile ("1:\n"
+ "subs %0, %1, #1\n"
+ "bne 1b" : "=r" (loops) : "0" (loops));
+}
+
+int board_init(void)
+{
+ gd->bd->bi_boot_params = LINUX_BOOT_PARAM_ADDR;
+ gd->bd->bi_arch_number = MACH_TYPE_VEXPRESS;
+ gd->flags = 0;
+
+ icache_enable();
+ flash__init();
+ vexpress_timer_init();
+
+ return 0;
+}
+
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+#ifdef CONFIG_SMC911X
+ rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+#endif
+ return rc;
+}
+
+static void flash__init(void)
+{
+ /* Setup the sytem control register to allow writing to flash */
+ writel(readl(&sysctrl_base->scflashctrl) | VEXPRESS_FLASHPROG_FLVPPEN,
+ &sysctrl_base->scflashctrl);
+}
+
+int dram_init(void)
+{
+ gd->ram_size = get_ram_size(CONFIG_SYS_SDRAM_BASE, PHYS_SDRAM_1_SIZE);
+ return 0;
+}
+
+void dram_init_banksize(void)
+{
+ gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
+ gd->bd->bi_dram[0].size = get_ram_size(PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
+ gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
+ gd->bd->bi_dram[1].size = get_ram_size(PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
+}
+
+int timer_init(void)
+{
+ return 0;
+}
+
+/*
+ * Start timer:
+ * Setup a 32 bit timer, running at 1KHz
+ * Versatile Express Motherboard provides 1 MHz timer
+ */
+static void vexpress_timer_init(void)
+{
+ /*
+ * Set clock frequency in system controller:
+ * VEXPRESS_REFCLK is 32KHz
+ * VEXPRESS_TIMCLK is 1MHz
+ */
+ writel(SP810_TIMER0_ENSEL | SP810_TIMER1_ENSEL |
+ SP810_TIMER2_ENSEL | SP810_TIMER3_ENSEL |
+ readl(&sysctrl_base->scctrl), &sysctrl_base->scctrl);
+
+ /*
+ * Set Timer0 to be:
+ * Enabled, free running, no interrupt, 32-bit, wrapping
+ */
+ writel(SYSTIMER_RELOAD, &systimer_base->timer0load);
+ writel(SYSTIMER_RELOAD, &systimer_base->timer0value);
+ writel(SYSTIMER_EN | SYSTIMER_32BIT | \
+ readl(&systimer_base->timer0control), \
+ &systimer_base->timer0control);
+
+ reset_timer_masked();
+}
+
+/* Use the ARM Watchdog System to cause reset */
+void reset_cpu(ulong addr)
+{
+ writeb(WDT_EN, &wdt_base->wdogcontrol);
+ writel(WDT_RESET_LOAD, &wdt_base->wdogload);
+ while (1)
+ ;
+}
+
+/*
+ * Delay x useconds AND perserve advance timstamp value
+ * assumes timer is ticking at 1 msec
+ */
+void udelay(ulong usec)
+{
+ ulong tmo, tmp;
+
+ tmo = usec / 1000;
+ tmp = get_timer(0); /* get current timestamp */
+
+ /*
+ * If setting this forward will roll time stamp then
+ * reset "advancing" timestamp to 0 and set lastdec value
+ * otherwise set the advancing stamp to the wake up time
+ */
+ if ((tmo + tmp + 1) < tmp)
+ reset_timer_masked();
+ else
+ tmo += tmp;
+
+ while (get_timer_masked() < tmo)
+ ; /* loop till wakeup event */
+}
+
+ulong get_timer(ulong base)
+{
+ return get_timer_masked() - base;
+}
+
+void reset_timer_masked(void)
+{
+ lastdec = readl(&systimer_base->timer0value) / 1000;
+ timestamp = 0;
+}
+
+void reset_timer(void)
+{
+ reset_timer_masked();
+}
+
+ulong get_timer_masked(void)
+{
+ ulong now = readl(&systimer_base->timer0value) / 1000;
+
+ if (lastdec >= now) { /* normal mode (non roll) */
+ timestamp += lastdec - now;
+ } else { /* count down timer overflowed */
+ /*
+ * nts = ts + ld - now
+ * ts = old stamp, ld = time before passing through - 1
+ * now = amount of time after passing though - 1
+ * nts = new "advancing time stamp"
+ */
+ timestamp += lastdec + SYSTIMER_RELOAD - now;
+ }
+ lastdec = now;
+
+ return timestamp;
+}
+
+void lowlevel_init(void)
+{
+}
+
+ulong get_board_rev(void){
+ return readl((u32 *)SYS_ID);
+}
diff --git a/board/armltd/vexpress/config.mk b/board/armltd/vexpress/config.mk
new file mode 100644
index 0000000..2d797d7
--- /dev/null
+++ b/board/armltd/vexpress/config.mk
@@ -0,0 +1,23 @@
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+# Linux-Kernel is expected to be at 0x60008000
+#
+TEXT_BASE = 0x60800000
+LDSCRIPT := $(SRCTREE)/board/armltd/vexpress/u-boot.lds
diff --git a/board/armltd/vexpress/u-boot.lds b/board/armltd/vexpress/u-boot.lds
new file mode 100644
index 0000000..2ab4a21
--- /dev/null
+++ b/board/armltd/vexpress/u-boot.lds
@@ -0,0 +1,65 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, <gj@denx.de>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x00000000;
+ . = ALIGN(4);
+ .text :
+ {
+ arch/arm/cpu/armv7/start.o (.text)
+ *(.text)
+ }
+
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata))) }
+
+ . = ALIGN(4);
+ .data : { *(.data)
+ __datarel_start = .;
+ *(.data.rel)
+ __datarelrolocal_start = .;
+ *(.data.rel.ro.local)
+ __datarellocal_start = .;
+ *(.data.rel.local)
+ __datarelro_start = .;
+ *(.data.rel.ro)
+ }
+
+ __got_start = .;
+ . = ALIGN(4);
+ .got : { *(.got) }
+ __got_end = .;
+
+ . = .;
+ __u_boot_cmd_start = .;
+ .u_boot_cmd : { *(.u_boot_cmd) }
+ __u_boot_cmd_end = .;
+
+ . = ALIGN(4);
+ __bss_start = .;
+ .bss : { *(.bss) }
+ _end = .;
+}
diff --git a/boards.cfg b/boards.cfg
index 9909685..c4a410d 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -253,6 +253,7 @@ imx27lite arm arm926ejs imx27lite logicpd mx27
magnesium arm arm926ejs imx27lite logicpd mx27
omap5912osk arm arm926ejs - ti omap
edminiv2 arm arm926ejs - LaCie orion5x
+ca9x4_ct_vxp arm armv7 vexpress armltd
omap3_overo arm armv7 overo - omap3
omap3_pandora arm armv7 pandora - omap3
omap3_zoom1 arm armv7 zoom1 logicpd omap3
diff --git a/include/configs/ca9x4_ct_vxp.h b/include/configs/ca9x4_ct_vxp.h
new file mode 100644
index 0000000..5547d55
--- /dev/null
+++ b/include/configs/ca9x4_ct_vxp.h
@@ -0,0 +1,196 @@
+/*
+ * (C) Copyright 2010 Linaro
+ * Matt Waddel, <matt.waddel@linaro.org>
+ *
+ * Configuration for Versatile Express. Parts were derived from other ARM
+ * configurations.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/* Board info register */
+#define SYS_ID 0x10000000
+#define CONFIG_REVISION_TAG 1
+
+/* High Level Configuration Options */
+#define CONFIG_ARMV7 1
+
+#define CONFIG_SYS_MEMTEST_START 0x60000000
+#define CONFIG_SYS_MEMTEST_END 0x20000000
+#define CONFIG_SYS_HZ 1000
+
+#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */
+#define CONFIG_SETUP_MEMORY_TAGS 1
+#define CONFIG_L2_OFF 1
+#define CONFIG_INITRD_TAG 1
+
+/* Size of malloc() pool */
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024)
+#define CONFIG_SYS_GBL_DATA_SIZE 128
+
+#define SCTL_BASE 0x10001000
+#define VEXPRESS_FLASHPROG_FLVPPEN (1 << 0)
+
+/* SMSC9115 Ethernet from SMSC9118 family */
+#define CONFIG_NET_MULTI
+#define CONFIG_SMC911X 1
+#define CONFIG_SMC911X_32_BIT 1
+#define CONFIG_SMC911X_BASE 0x4E000000
+
+/* PL011 Serial Configuration */
+#define CONFIG_PL011_SERIAL
+#define CONFIG_PL011_CLOCK 24000000
+#define CONFIG_PL01x_PORTS {(void *)CONFIG_SYS_SERIAL0, \
+ (void *)CONFIG_SYS_SERIAL1}
+#define CONFIG_CONS_INDEX 0
+
+#define CONFIG_BAUDRATE 38400
+#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
+#define CONFIG_SYS_SERIAL0 0x10009000
+#define CONFIG_SYS_SERIAL1 0x1000A000
+
+/* Command line configuration */
+#define CONFIG_CMD_BDI
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_ELF
+#define CONFIG_CMD_ENV
+#define CONFIG_CMD_FLASH
+#define CONFIG_CMD_IMI
+#define CONFIG_CMD_MEMORY
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_SAVEENV
+#define CONFIG_NET_MULTI
+#define CONFIG_CMD_RUN
+
+#define CONFIG_CMD_FAT
+#define CONFIG_DOS_PARTITION 1
+#define CONFIG_MMC 1
+#define CONFIG_CMD_MMC
+#define CONFIG_GENERIC_MMC
+
+/* BOOTP options */
+#define CONFIG_BOOTP_BOOTFILESIZE
+#define CONFIG_BOOTP_BOOTPATH
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_HOSTNAME
+
+/* Miscellaneous configurable options */
+#undef CONFIG_SYS_CLKS_IN_HZ
+#define CONFIG_SYS_LOAD_ADDR 0x60008000 /* load address */
+#define LINUX_BOOT_PARAM_ADDR 0x60000200
+#define CONFIG_BOOTDELAY 2
+
+/* Stack sizes are set up in start.S using the settings below */
+#define CONFIG_STACKSIZE (128 * 1024) /* regular stack */
+#ifdef CONFIG_USE_IRQ
+#define CONFIG_STACKSIZE_IRQ (4 * 1024) /* IRQ stack */
+#define CONFIG_STACKSIZE_FIQ (4 * 1024) /* FIQ stack */
+#endif
+
+/* Physical Memory Map */
+#define CONFIG_NR_DRAM_BANKS 2
+#define PHYS_SDRAM_1 0x60000000 /* SDRAM Bank #1 */
+#define PHYS_SDRAM_2 0x80000000 /* SDRAM Bank #1 */
+#define PHYS_SDRAM_1_SIZE 0x20000000 /* 512 MB */
+#define PHYS_SDRAM_2_SIZE 0x20000000 /* 512 MB */
+
+/* additions for new relocation code */
+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
+#define CONFIG_SYS_INIT_RAM_END 0x1000
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_SDRAM_BASE + \
+ CONFIG_SYS_INIT_RAM_END - \
+ CONFIG_SYS_GBL_DATA_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR CONFIG_SYS_GBL_DATA_OFFSET
+
+/* Basic environment settings */
+#define CONFIG_BOOTCOMMAND "run bootflash;"
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ "loadaddr=0x80008000\0" \
+ "initrd=0x61000000\0" \
+ "kerneladdr=0x44100000\0" \
+ "initrdaddr=0x44800000\0" \
+ "maxinitrd=0x1800000\0" \
+ "console=ttyAMA0,38400n8\0" \
+ "dram=1024M\0" \
+ "root=/dev/sda1 rw\0" \
+ "mtd=armflash:1M at 0x800000(uboot),7M at 0x1000000(kernel)," \
+ "24M at 0x2000000(initrd)\0" \
+ "flashargs=setenv bootargs root=${root} console=${console} " \
+ "mem=${dram} mtdparts=${mtd} mmci.fmax=190000 " \
+ "devtmpfs.mount=0 vmalloc=256M\0" \
+ "bootflash=run flashargs; " \
+ "cp ${initrdaddr} ${initrd} ${maxinitrd}; " \
+ "bootm ${kerneladdr} ${initrd}\0"
+
+/* FLASH and environment organization */
+#define PHYS_FLASH_SIZE 0x04000000 /* 64MB */
+#define CONFIG_SYS_FLASH_CFI 1
+#define CONFIG_FLASH_CFI_DRIVER 1
+#define CONFIG_SYS_FLASH_SIZE 0x04000000
+#define CONFIG_SYS_MAX_FLASH_BANKS 2
+#define CONFIG_SYS_FLASH_BASE0 0x40000000
+#define CONFIG_SYS_FLASH_BASE1 0x44000000
+#define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE0
+
+/* Timeout values in ticks */
+#define CONFIG_SYS_FLASH_ERASE_TOUT (2 * CONFIG_SYS_HZ) /* Erase Timeout */
+#define CONFIG_SYS_FLASH_WRITE_TOUT (2 * CONFIG_SYS_HZ) /* Write Timeout */
+
+/* 255 0x40000 sectors + first or last sector may have 4 erase regions = 259 */
+#define CONFIG_SYS_MAX_FLASH_SECT 259 /* Max sectors */
+#define FLASH_MAX_SECTOR_SIZE 0x00040000 /* 256 KB sectors */
+
+/* Room required on the stack for the environment data */
+#define CONFIG_ENV_SIZE FLASH_MAX_SECTOR_SIZE
+
+/*
+ * Amount of flash used for environment:
+ * We don't know which end has the small erase blocks so we use the penultimate
+ * sector location for the environment
+ */
+#define CONFIG_ENV_SECT_SIZE FLASH_MAX_SECTOR_SIZE
+#define CONFIG_ENV_OVERWRITE 1
+
+/* Store environment@top of flash */
+#define CONFIG_ENV_IS_IN_FLASH 1
+#define CONFIG_ENV_OFFSET (PHYS_FLASH_SIZE - \
+ (2 * CONFIG_ENV_SECT_SIZE))
+#define CONFIG_ENV_ADDR (CONFIG_SYS_FLASH_BASE1 + \
+ CONFIG_ENV_OFFSET)
+#define CONFIG_SYS_FLASH_PROTECTION /* The devices have real protection */
+#define CONFIG_SYS_FLASH_EMPTY_INFO /* flinfo indicates empty blocks */
+#define CONFIG_SYS_FLASH_BANKS_LIST { CONFIG_SYS_FLASH_BASE0, \
+ CONFIG_SYS_FLASH_BASE1 }
+
+/* Monitor Command Prompt */
+#define CONFIG_SYS_CBSIZE 512 /* Console I/O Buffer Size */
+#define CONFIG_SYS_PROMPT "VExpress# "
+#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \
+ sizeof(CONFIG_SYS_PROMPT) + 16)
+#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE /* Boot args buffer */
+#define CONFIG_CMD_SOURCE
+#define CONFIG_SYS_LONGHELP
+#define CONFIG_CMDLINE_EDITING 1
+#define CONFIG_SYS_MAXARGS 16 /* max command args */
+
+#endif
--
1.7.1
^ permalink raw reply related
* [U-Boot] [PATCH V5 0/2] ARMV7: Add support for the Versatile Express Quad Cortex A9 platform
From: matt.waddel at linaro.org @ 2010-10-07 21:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1280373167-20890-2-git-send-email-matt.waddel@linaro.org>
From: Matt Waddel <matt.waddel@linaro.org>
Adds support for the ARM quad-core Cortex-A9 processor.
This system includes a motherboard(Versatile Express), daughterboard
(Coretile), and SOC(Cortex-A9 quad core). The serial port, ethernet,
and flash systems work with these additions. The naming convention
is:
SOC -> CortexA9 quad core = ca9x4
daughterboard -> Coretile = ct
motherboard -> Versatile Express = vxp
This gives ca9x4_ct_vxp.c as the board support file.
The 2nd patch fixes a bug in the "set baudrate xxx" functionality and
fixes some of the code problems like CamelCase and IO accessors.
---
Version 2 -
Removed unneeded multi-core low_level setup code.
Version 3 -
Patch 1)
1) Fixups from Wolfgang's code review:
- Remove CamelCase variable definitions, keep lists sorted, tab indents
only, remove trailing empty lines, remove unneeded configuration options,
use I/O accessors, added while(1) loop in reset command
2) Simplified board_init declarations
3) Added CONFIG_INITRD_TAG declaration
4) Removed unneeded assembly directives from Makefile
Patch 2)
1) Replaced IO_WRITE and IO_READ calls in serial_pl01x.c with calls to
readl() and writel(). Fixed commenting and CamelCase problems.
Version 4 -
1) Refactored to work with the "next" branch
2) Fixed a bug in the 2nd flash bank definition
Version 5 -
1) Refactored to apply to the tip of git tree.
2) Improved the environment settings and added the run command option
Matt Waddel (2):
ARMV7: Versatile Express Coretile CortexA9x4 support
ARMV7: Fixed baudrate setting in pl01x driver
MAINTAINERS | 4 +
MAKEALL | 1 +
arch/arm/include/asm/arch-armv7/sysctrl.h | 70 +++++++++
arch/arm/include/asm/arch-armv7/systimer.h | 50 +++++++
arch/arm/include/asm/arch-armv7/wdt.h | 55 +++++++
board/armltd/vexpress/Makefile | 49 ++++++
board/armltd/vexpress/ca9x4_ct_vxp.c | 220 ++++++++++++++++++++++++++++
board/armltd/vexpress/config.mk | 23 +++
board/armltd/vexpress/u-boot.lds | 65 ++++++++
boards.cfg | 1 +
drivers/serial/serial_pl01x.c | 93 +++++-------
include/configs/ca9x4_ct_vxp.h | 196 +++++++++++++++++++++++++
12 files changed, 772 insertions(+), 55 deletions(-)
create mode 100644 arch/arm/include/asm/arch-armv7/sysctrl.h
create mode 100644 arch/arm/include/asm/arch-armv7/systimer.h
create mode 100644 arch/arm/include/asm/arch-armv7/wdt.h
create mode 100644 board/armltd/vexpress/Makefile
create mode 100644 board/armltd/vexpress/ca9x4_ct_vxp.c
create mode 100644 board/armltd/vexpress/config.mk
create mode 100644 board/armltd/vexpress/u-boot.lds
create mode 100644 include/configs/ca9x4_ct_vxp.h
^ permalink raw reply
* Re: [PATCH 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417
From: Mauro Carvalho Chehab @ 2010-10-07 21:48 UTC (permalink / raw)
To: dheitmueller
Cc: Srinivasa.Deevi, Palash.Bandyopadhyay, Linux Media Mailing List
In-Reply-To: <20100928154653.785c1f3f@pedra>
Em 28-09-2010 15:46, Mauro Carvalho Chehab escreveu:
> drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’
> drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
OK, I just updated my tree with the patches that Mkrufky acked.
It basically contains the same patches from my previous post, plus
the patches that Palash sent, and Devin/Mkrufky patches from polaris4
tree, rebased over the top of kernel v2.6.36-rc7 (this makes easier
for me to test and to merge).
The patches are at:
http://git.linuxtv.org/mchehab/cx231xx.git
Sri already sent his ack for the first series of the patches.
The tree contains two extra patches:
1) a cx231xx large CodingStyle fix patch:
http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=eacd1a7749ae45d1f2f5782c013b863ff480746d
It basically solves the issues that checkpatch.pl complained on this series of patches;
2) a cx231xx-417 gcc warning fix:
http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=ca3a6a8c2a4819702e93b9612c4a6d90474ea9b5
Devin,
Would it be ok for you if I merge them on my main tree? They're needed for one
board I'm working with (a Pixelview SBTVD Hybrid - that supports both analog
and full-seg ISDB-T).
Thanks,
Mauro.
^ permalink raw reply
* ext4 support on pvgrub
From: M A Young @ 2010-10-07 21:48 UTC (permalink / raw)
To: xen-devel
I have this working on Fedora. It turned out to be very easy to add this
as I simply took the grub-ext4-support.patch from the Fedora grub package
and put it in xen-4.0.1/stubdom/grub.patches/ . Using pvgrub (without a
vif on the virtual machine as I was having problems if I did give it a
network interface) I could read and boot from ext4 partition with this
patch but not without it.
Is this a good way to add this feature to xen more generally?
Michael Young
^ permalink raw reply
* kgdb errors with serial console
From: Elvis Dowson @ 2010-10-07 21:47 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux OMAP Mailing List; +Cc: Jason Wessel
Hi,
I'm getting the following errors when attempting to use kgdb with the serial console. Any idea how I can resolve this issue?
The correct serial parameters when I use kermit with the target board is
set flow-control off
set carrier-watch none
set speed 115200
and it connects correctly.
I'm not sure if the gdb configuration commands for the serial port are sufficient, and if there is a parameter that I am missing here. The host is connected to the target using an FTDI USB to serial converter, so it appears as /dev/ttyUSB0 on the host and as ttyS2 on the target.
# su
# cd /tool/patches/android-rowboat-froyo-2.2-patchwork/kernel
# arm-angstrom-linux-gnueabi-gdb
(gdb) file vmlinux
Reading symbols from /tool/patches/android-rowboat-froyo-2.2-patchwork/kernel/vmlinux...done.
(gdb) set remotebaud 115200
(gdb) set remoteflow 0
(gdb) set debug remote 1
(gdb) set debug serial 1
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
Sending packet: $qSupported#37...[
r +]Ack
[$][q][S][u][p][p][o][r][t][e][d][#][3][7]Packet received: qSupported
Packet qSupported (supported-packets) is supported
warning: unrecognized item "qSupported" in "qSupported" response
Sending packet: $Hg0#df...[+]Ack
[$][H][g][0][#][d][f]Packet received: Hg0
Sending packet: $?#3f...[+]Ack
[$][?][#][3][f]Packet received: ?
Sending packet: $Hc-1#09...[+]Ack
[$][H][c][-][1][#][0][9]Packet received: Hc-1
Sending packet: $qC#b4...[+]Ack
[$][q][C][#][b][4]Packet received: qC
Sending packet: $qAttached#8f...[+]Ack
[$][q][A][t][t][a][c][h][e][d][#][8][f]Packet received: qAttached
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...[+]Ack
[$][q][O][f][f][s][\r][\r][\n][e][t][s][#][4][b]Bad checksum, sentsum=0x4b, csum=0x6f, buf=qOffs\r\r\nets
[-][<Timeout: 2 seconds>]Timed out.
[-][<Timeout: 2 seconds>]Timed out.
Ignoring packet error, continuing...
Malformed response to offset query, qOffs
ets
(gdb)
Best regards,
Elvis Dowson
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 21:47 UTC (permalink / raw)
To: Greg KH
Cc: Alan Cox, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Ben Dooks, Alan Cox, Kukjin Kim, Mike Frysinger,
Feng Tang, Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <20101007211513.GB26660@suse.de>
On Thu, 2010-10-07 at 14:15 -0700, Greg KH wrote:
> On Thu, Oct 07, 2010 at 01:51:18PM -0700, Daniel Walker wrote:
> > Your making too many assumptions .. You might be able to modify the
> > kernel, and not the userspace. So you couldn't tweak the device
> > creation .. It's much easier in the server world ..
>
> You're saying it's easier to replace an embedded kernel than a userspace
> file on an embedded system? Heh, that's funny.
I'm saying it _can_ happen that it's easier to replace the kernel.. I'm
not saying it's always the case. We're talking about debugging
situations in an embedded environment which don't always follow a normal
path.
> > > We've said no over a period of about ten years to a lot of attempts to
> > > just borrow the ttyS0 range. If we'd said yes it would have been a
> > > complete mess by now.
> > >
> > > So the answer is no.
> >
> > Nothing can be unilateral, there's always room for exceptions. You
> > should say something more like "it's possible, but unlikely".
>
> Hm, how about this, as the TTY and serial driver[1] maintainer, I will
> not accept this kind of patch at all.
>
> Is that final enough for you?
So you don't like it, that's fair enough .. <thinks>I wonder what other
maintainers I can send this too</thinks> ;)
Can you be more specific about your objections .. The discussion over
the ttyS* thing is still happening. I'm waiting for Hyok to give a good
reason for why he wrote that part of it. I can imagine good reasons for
why that part would exist, which is what I'm discussing with Alan and
Mike.
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [Bug 30188] X server crashes with a SIGBUS on Evergreen
From: bugzilla-daemon @ 2010-10-07 21:47 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-30188-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=30188
--- Comment #23 from Maggioni Marcello <hayarms@gmail.com> 2010-10-07 14:47:22 PDT ---
Hei, I tried the drm-radeon-testing kernel and now Okular works, but X still
crashes with a segfault when going fullscreen with virtualbox.
Someone is having this problem? Do you think is related to this bug?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Dmitry Torokhov @ 2010-10-07 21:46 UTC (permalink / raw)
To: Matthew Garrett
Cc: Mario Limonciello, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <20101007213754.GA1896@srcf.ucam.org>
On Thu, Oct 07, 2010 at 10:37:54PM +0100, Matthew Garrett wrote:
> On Thu, Oct 07, 2010 at 02:30:28PM -0700, Dmitry Torokhov wrote:
>
> > We have this strategy for bunch of input stuff (force release, keymap)
> > and I think it works better than dding more and more DMI quirks into
> > kernel itself.
>
> It's limited to Dell hardware, so I think keeping a static list in the
> Dell laptop driver is reasonable. All we need is a list of hardware, and
> I'd really hope that Dell know which BIOS versions contain this code!
>
Unfortunately this kind of crap tends to flow from one BIOS version to
another.. How many DMI entries do we know about so far? Did Dell issue
firmware updates correcting the issue so new boxes will not exhibit the
problem?
--
Dmitry
^ permalink raw reply
* [PATCH 1/2] ASoC: Add CS4271 codec support
From: Timur Tabi @ 2010-10-07 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4CAD16A5.1090501@bluewatersys.com>
Ryan Mallon wrote:
> + * For setups with variable MCLKs, pass 0 as 'freq' argument. This will cause
> + * theoretically possible sample rates to be enabled. Call it again with a
> + * proper value set one the external clock is set (most probably you would do
> + * that from a machine's driver 'hw_param' hook.
If you're going to copy/paste parts of my driver verbatim into yours, you should
put something like this in the comments:
Based on the CS4270 driver by Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: Add CS4271 codec support
From: Timur Tabi @ 2010-10-07 21:46 UTC (permalink / raw)
To: Ryan Mallon
Cc: alsa-devel@alsa-project.org, Mark Brown, linux-arm-kernel,
Liam Girdwood
In-Reply-To: <4CAD16A5.1090501@bluewatersys.com>
Ryan Mallon wrote:
> + * For setups with variable MCLKs, pass 0 as 'freq' argument. This will cause
> + * theoretically possible sample rates to be enabled. Call it again with a
> + * proper value set one the external clock is set (most probably you would do
> + * that from a machine's driver 'hw_param' hook.
If you're going to copy/paste parts of my driver verbatim into yours, you should
put something like this in the comments:
Based on the CS4270 driver by Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.