On Sun, 17 Oct 2010 09:26:57 -0700
Arjan van de Ven wrote:
> So I've been sent several patches now that add TTY ndisc numbers
>
> those numbers are a kernel ABI, and because of that, they need to be
> at minimum reserved in Linus' kernel SOON.
Won't happen. Ldisc numbers are not reserved
> Ahhh, I would love to do that, but doing that thru alsa isn't possible
> Alsa mixer controls doesn't allow app to send the algorithm
> coefficients Normally this is done in MMF like pulseaudio and we are
> trying to offload this
That sounds like the right discussion is how to fix ALSA mixer APIs
This looks basically sound but I would fix one thing
> +static int set_reg(struct i2c_client *client, u8 reg, u8 mask, u8
> value,
> + u8 offset)
> +{
> + u8 tmp;
> +
> + mutex_lock(&i2c_mutex);
> +
> + tmp = i2c_smbus_read_byte_data(client, reg);
i2c_smbus_rea
> > There is a proc file with a list of ldiscs, experimental code is
> > expected to either use that or be as it says - experimental.
>
> What file is this? It's not /proc/tty/ldiscs, right?
Thats the one - you can open it - find your ldisc by name and pull the
ldisc number off it. For experimen
On Mon, 18 Oct 2010 18:32:56 +0300
Ameya Palande wrote:
> Hi Alan,
>
> What is the plan for rebasing your mid-ref tree on top of 2.6.36-rc8?
I don't have one.
We are very very close to the final 2.6.36, and the update will be a
bit messy because there are several drivers where the intel one ha
On Tue, 19 Oct 2010 09:09:22 +0800
Feng Tang wrote:
> SFI v0.8 has better abstract of listing non-detectable peripherals,
> and most of Intel MID systems have adopted SFI 0.8, so remove the
> old code.
Applied for pushing upstream. I swapped 1/2 and 2/2 over so that it
builds with only one appli
On Tue, 19 Oct 2010 17:38:03 +0800
Feng Tang wrote:
> x86, mrst: simplify the power button parsing code
Applied
___
Meego-kernel mailing list
Meego-kernel@lists.meego.com
http://lists.meego.com/listinfo/meego-kernel
> * n_tracerouter_open() - Called when a tty is opened by a SW entity.
> * @tty: terminal device to the ldisc.
> *
> * Return:
> - * 0 for success.
> + * 0 for success.
> + *
> + * Caveats: This should only be opened one time per SW entity.
> */
> -
> static int n_tracerouter_ope
On Mon, 18 Oct 2010 18:55:51 -0700
"Mills, Ken K" wrote:
> From 17bf0a5815a076b4778f2211cdb34cac0e4a66e0 Mon Sep 17 00:00:00 2001
> From: Ken Mills
> Date: Mon, 18 Oct 2010 18:21:34 -0700
> Subject: [PATCH 1/4] Add console device to capture kernel printk()
> messages.
Looks sane to me - far too
On Mon, 18 Oct 2010 18:57:44 -0700
"Mills, Ken K" wrote:
> From 714323e8eb464d3ef613b695dbcdc5f24f88c60b Mon Sep 17 00:00:00 2001
> From: Ken Mills
> Date: Mon, 18 Oct 2010 18:33:01 -0700
> Subject: [PATCH 3/4] Modified function pti_write_to_aperture() to be
> endian independent. Put lock around
> + if (!in_interrupt())
> + get_task_comm(comm, current);
> + else
> + strcpy(comm, "Interrupt");
> +
> + mccontrol.channel = pti_control_channel;
> + pti_control_channel = (pti_control_channel + 1) & 0x7f;
> +
> + snprintf(control_frame, CONTROL_FRAME_
> + if (copy_from_user(kbuf, tmp, size)) {
> + kfree(kbuf);
> + return -EFAULT;
> + }
> + pr_debu
Technically if you've used part of the input then get a fault you
should return the bytes correctly processed. In the tree I
> I suggest disabling things which break with this move, and fix them
> when kernel-dev moves to 2.6.36 release.
It isn't that simple. The rebase will be a big piece of work because of
all the submissions and the stuff that needs dropping out (some of which
in turn of course has dependencies to fi
> I did this to address the comment that n_tracerouter should only be
> allowed to sit on one tty port per SW entity and to prevent a
> multiple tty port opening. If it's okay to loose this check, does
> this 2nd revision address the concern of having only one tty port
> opening that this ldisc si
On Tue, 19 Oct 2010 16:00:59 -0700
Ken Lierman wrote:
> Add initial ak8975 eCompass driver.
>
> We are aware of the conflicting upstream driver, and need a get well
> plan to align/merge with it, but this version is currently required.
Assuming the upstream one in staging and IIO ever gets i
Would you please post an inline copy of the patch as well so it can be
commented in.
There are several obvious funnies in that code - my favourite being
+ msleep(0);
but if you posted an inline copy I could actually give you a set of
useful comments.
Alan
_
> not a very good driver to be honest.. I wonder if the one in the
> upstream kernel is any better...
> would make a better base to start from.
The upstream one imports all of the staging IIO and ABIs which I
suspect are going to get a serious haircut when they meet Linus.
This one looks fairly
> +void intel_alsa_reset_ssp_status(void)
> +{
> + s_stream_status.ssp_handle = NULL;
> + s_stream_status.stream_info = 0;
> + spin_lock_init(&s_stream_status.lock);
> +}
It looks like a lot of these can be static ?
> + spin_lock_bh(&s_stream_status.lock);
Take the lock
> [Selma] Each user has to perform an Open and Close of the used
> stream. The Open function performs the SSP open only if no streams
> are already open (s_stream_status.stream_info = 0) and sets the
> corresponding stream index The Close function performs the SSP close
> only if no streams are sti
> + * mid_thermal_remove - mfld thermal finalize
> + * @dev: platform device structure
> + * Context: can sleep
> + *
> + * MLFD thermal remove unregisters all the sensors from the generic
> + * thermal framework.
> + */
> +static int mid_thermal_remove(struct platform_device *pdev)
> +{
> +
> + pinfo->tzd[i] = thermal_zone_device_register(name[i],
> + TRIP_POINTS,
> initialize_sensor(i),
> + &tzd_ops, TEMP_CONST1,
> TEMP_CONST2,
> + PASSIVE_FREQ, POLLING_FRE
On Thu, 21 Oct 2010 18:38:29 +0530
"R, Durgadoss" wrote:
> Hi Alan,
> Thanks for the comments.
>
> >This doesn't seem to have any process which gives back the ADC
> >channels on the SCU ?
>
> Ideally, at this place we can turn off the ADC.
>
> But, there are other drivers that might be u
On Thu, 21 Oct 2010 19:01:59 +0530
"R, Durgadoss" wrote:
> Hi Alan,
>
> >If the sensor has a true thermal event interrupt why are you polling
> >it ? This all costs battery and wakeups on a phone.
>
> These are skin sensors on the platform and do not generate an
> interrupt. So, the thermal mon
> How do you suggest solving this issue (since you will see it appear
> again in a review)?
For the upstream direction tree I simply made it bool for now - as you
say it needs resolving upstream and will probably get sorted there by
the time the pti code is going that way
> > > 8Kb allocation? R
On Thu, 21 Oct 2010 15:37:40 -0700
Ken Lierman wrote:
> Add 3rd party device driver and associated platform support
> for NFC (NXP PN544 controller chip)
>
> Please enabled in the default config for mid as well, ie:
> CONFIG_PN544_NFC=y
>
> Change-Id: Idf6a2b4a0283d6ae1dd7fdf0455b9d6529cd1670
>
On Thu, 21 Oct 2010 15:37:21 -0700
Ken Lierman wrote:
> From: Ken Lierman
>
> Add 3rd party device driver and associated platform support for
> Broadcom BCM4751 GPS chip on customer hardware.
>
> Please enabled in the default config for mid as well, ie:
> CONFIG_BCM4751_GPS=y
Again needs the
On Thu, 21 Oct 2010 18:04:00 +0100
"Bensaid, Selma" wrote:
> Hi,
>
> Please find attached the ALSA SSP driver for Intel MID Platform.
>
> This ALSA sound card driver handles 2 PCM devices:
>
> - BT PCM device which support 1 capture substream and 1 playback
> substream (8KHz, mono, 16 bits/sam
O
> +/*
> + * This array represents the Battery Pack thermistor
> + * temarature and corresponding ADC value limits
> + */
> +static int
const
(as I pointed out in the very very first submission response)
> +
> +/* SFI table entries */
> +struct msic_batt_sfi_prop {
> +unsigned char sign[5]
On Fri, 22 Oct 2010 17:27:58 +0530
"R, Durgadoss" wrote:
> Hi Arjan,
>
> I have reworked the medfield thermal driver patch.
>
> As per comments, removed the polling mechanism from the driver.
> This driver now registers with the thermal framework,
> which already exists in the kernel.
> It read
On Tue, 26 Oct 2010 17:40:59 +0800
"Li, Jiebing" wrote:
> From c03bfb5dc571ee2cfe99c75edcda889160f255a1 Mon Sep 17 00:00:00 2001
> From: Jiebing Li
> Date: Fri, 22 Oct 2010 15:54:50 +0800
> Subject: [PATCH] usb gadget: add support for medfield in composite
> gadget.
>
> This patch for composite
On Tue, 26 Oct 2010 16:49:28 +0530
"Pallala, Ramakrishna" wrote:
> Hi Alan,
>
> > I am resubmitting the MSIC battery patch.
> >
> > I have fixed your comments and added comments in the code wherever
> > necessary.
> > http://lists.meego.com/pipermail/meego-kernel/2010-October/000786.html
>
> I
On Wed, 27 Oct 2010 17:48:31 +0800
"Li, Jiebing" wrote:
> From 7f7df6e39160e0c5ff7e186b74df108b4db67569 Mon Sep 17 00:00:00 2001
> From: JiebingLi
> Date: Wed, 27 Oct 2010 17:42:43 +0800
> Subject: [PATCH] usb gadget: add support for medfield composite gadget
>
> For Medfield platform, number o
On Thu, 28 Oct 2010 18:30:09 -0700
"Mills, Ken K" wrote:
>
> These fixes have been verified with the IFX6160 modem.
Most of this looks either right, or in some cases its clearly sorting
something but I am not sure it is doing it the right way, so some
explanation is definitely called for
> +#d
> #define TESTMODE_ENABLE_POLL 0x02
> #define TESTMODE_ENABLE_LOOPBACK 0x04
> #define TESTMODE_ENABLE_INTR 0x08
> +#define TESTMODE_PRIV_MASK 0xff00
> #define TESTMODE_IGNORE_SRDY 0x100
> #define TESTMODE_IGNORE_SPITO0x200
> #define TESTMODE(x) (testmode & x)
Ok none of th
Already have all this done in the driver for upstream except for the
automatic use of name to modem type - which seems dubious. Surely
better to pass a "use dma" field in the private data from the firmware ?
___
MeeGo-kernel mailing list
MeeGo-kernel@list
On Tue, 2 Nov 2010 10:49:41 -0700
Russ Gorby wrote:
>
> Signed-off-by: Russ Gorby
> ---
> RRG: FIXME fix for inline function parameters
Already have this sorted for the upstream driver
___
MeeGo-kernel mailing list
MeeGo-kernel@lists.meego.com
http:
On Tue, 2 Nov 2010 10:49:38 -0700
Russ Gorby wrote:
> w/o this fix the controller driver may erroneously believe that
> I/O is pending and debug code during module unload may call
> the interrupt handler and follow interrupt-driven I/O code path
> to its detrement
Applied to ref t
On Tue, 2 Nov 2010 10:49:40 -0700
Russ Gorby wrote:
>
> Signed-off-by: Russ Gorby
> ---
> RRG: providing an ioctl to perform modem reset under application
> control where the TTY is not hung up. The application then "knows"
> that it may need to reconfigure MUX mode for the modem and reconnect
> scrutinizing the use-case closely enough. Would you agree that an
> ioctl that initiates a reset but follows the same code path from
> there is reasonable?
If you ensure a reset occurs on a hangup then you can just kick off a
reset in the hangup callback from the driver and use vhangup().
__
> The problem here is that the same protocol driver on different
> platforms uses a different controller driver that has different
> requirements. We're using the modem type to differentiate platforms.
Well how about using the platform type to differentiate platforms ?
Even if the SFI layer glue
> > Why isn't this driver upstream?
>
> We tried. No success.
>
> http://lkml.org/lkml/2010/8/23/191
You didn't try very hard it seems ?
And is the spec in question still closed, is the hardware in fact
tightly tied to a non-free userspace ?
With my upstream hat on we have to be very careful a
On Thu, 4 Nov 2010 22:33:09 +
"Busson, SebastienX" wrote:
> From 4055d12d73d305c9fa68ab09019f2dacb240f6e9 Mon Sep 17 00:00:00 2001
> From: Jonathan DE CESCO
> Date: Thu, 4 Nov 2010 17:12:44 +0100
> Subject: [PATCH] Enable TI Wl12xx BT Initialization in Medfield init
> file
>
> ---
> arch/x
On Fri, 05 Nov 2010 12:58:33 +0200
"Matti J. Aaltonen" wrote:
> On Thu, 2010-11-04 at 14:26 +0000, ext Alan Cox wrote:
> > > > Why isn't this driver upstream?
> > >
> > > We tried. No success.
> > >
> > > http://lkml.org/lkml
> SFI_DEV_TYPE_SD is added to SFI device type. On SFI table parsing,
> add SD device data processing: data are stored in sd_board_info
> structure and SD platform data function is call.
Which spec version is this ?
> + case SFI_DEV_TYPE_SD:
You want a break on the en
On Thu, 4 Nov 2010 14:12:41 -0700
james_p_freyen...@linux.intel.com wrote:
> From: J Freyensee
>
> This patch renames ptirouter_ldisc to n_tracerouter to a more
> linux kernel naming convention. NO added functionality or
> bug fixes are in this patch; it's just a rename.
Done in my tree - but
gpio_request can fail so that ought to be checked. Also we have name
tables in the firmware for gpio lines to avoid hardcoding random magic
numbers per board so they want using.
Can we get something like mmc_reset_0, mmc_reset_1, mmc_reset_2 in the
SFI names so that for any future product we won'
On Tue, 9 Nov 2010 19:14:14 +0800
"Dong, Chuanxiao" wrote:
> Alan, thanks for your comment. I will try to add this.
> Patch001 and patch002 were not platform relative, have any comment
> about them?
The basic idea looks fine to me - I'm not an expert on MMC 4 protocol
details so I couldn't comme
On Mon, 8 Nov 2010 11:49:26 -0800
"Dunatov, Mark" wrote:
> Greetings,
>
> Here is the full driver patch w/out the 3 compiler warnings, as
> requested.
We've already got one in staging - written by Nvidia. Is there a reason
we can't use that ?
Alan
__
> > Can we get something like mmc_reset_0, mmc_reset_1, mmc_reset_2 in
> > the SFI names so that for any future product we won't need code
> > changes.
>
> Alan, I have a question about the SFI table.
> I have checked some drivers which also need request GPIO lines. Found
> that those drivers can
> Wondering about our status for kernel-dev -> we'd like to provide
> OMAP4 PandaBoard support on 2.6.37-rc1 and wondering if our migration
> could take place so that we can send out the deltas needed.
I'm waiting for 37rc2 - rc1 seems a bit wobbly but a fair number of
bits have been sorted for up
> I have a alternative proposal - can we start a kernel-dev-next with
> the bleeding edge kernel? kernel-dev does'nt seem to move fast enough
> despite our best intentions? kernel-dev-next could be proposed to be
> broken at times, but guarentees to be in sync with kernel.org perhaps?
Switching
On Thu, 11 Nov 2010 17:01:05 +0800
Feng Tang wrote:
> When setting up the mpc_intsrc structure for vRTC's IRQ,
> we need to set its irqflag to level trigger, otherwise
> it will taken as edge triggered and cause the issue
> that vRTC can only fire IRQ once, as there is never a
> EOI issued from I
On Mon, 15 Nov 2010 08:54:01 -0800 (PST)
"Mark A. Allyn" wrote:
> that the callback function is defined and not used. It is indeed
> used at line 3826. This may be due to a bug in the compiler.
Actually gcc is right. If you build without RAR support then the inline
"no-operation" RAR handlers do
On Tue, 16 Nov 2010 17:32:39 +0800
"Chuanxiao.Dong" wrote:
> From e981cd75059c7059ea553dba97e6a39d56aac58f Mon Sep 17 00:00:00 2001
> +extern int emmc_rst_gpio_setup(int);
> +extern void emmc_rst_gpio_release(int);
This hardcodes assumptions about gpio pins being used. I'd also change
the naming
Will send up to Ingo
___
MeeGo-kernel mailing list
MeeGo-kernel@lists.meego.com
http://lists.meego.com/listinfo/meego-kernel
> If you somehow feel the upstream developers are not moving fast
> enough, then you should have sent the patches weeks ago :)
Chuanxiao did
Possibly once they've been through another iteration they want
resending to wake people up
___
MeeGo-kernel mai
On Tue, 16 Nov 2010 12:42:26 -0800
Russ Gorby wrote:
> Signed-off-by: Russ Gorby
>
> Under some debug config parameters, the exit routine can cause the
> interrupt handler from being called which pointed out a logic problem
> where the driver though I/O was in-progress since cur_msg was not
> c
On Tue, 16 Nov 2010 12:42:27 -0800
Russ Gorby wrote:
> Signed-off-by: Russ Gorby
>
> Replaced the multiple driver registration with id_table method to
> register for multiple devices
Already done this way in the driver pushed for upstream, but passing
the modem type. Wants tidying really as we
On Tue, 16 Nov 2010 12:42:28 -0800
Russ Gorby wrote:
> Signed-off-by: Russ Gorby
You are failing to provide descriptions still, you've been asked this
repeatedly so as asking hasn't worked I'm simply going to drop patches
from you without a description.
_
> >So what stops the suspend occurring between here after your test and
> >the mrdy change - seems you are only narrowing the window ?
>
> [Gorby, Russ] the issue here is the relative timing of D3 suspend
> between the SPI protocol and controller driver. You may be right that
> it doesn't complete
On Wed, 17 Nov 2010 14:52:21 +0800
Yong Wang wrote:
> This patch is submitted again for inclusion into MeeGo 1.2 kernel.
Thanks for posting the upstream fixes to get spectra building plus this
- I've merged those into the the mid-ref git tree which is now rebased
on 2.6.37-rc2 and hopefully I'll
> instrumented and exercised. So if this seems like a wart I'll remove
> it.
Not it seems like a nasty and subtle problem, but the code you have now
won't fix it merely limit it.
If your suspend code and your mrdy code both did
mutex_lock(&some_mutex);
if (!suspended) {
> This regulator is only available after scu is initialized.
> So we need to declare it in the scu initialized callback.
Why not just delay the wl12xx creation the same way as I²C and SPI
devices can already be delayed ? No need for hacks nailed onto the end
of the creation code that will end up w
This seems to match a newer version of the drivers than I have ? Which
I suspect means I'm short a patch somewhere.
Alan
___
MeeGo-kernel mailing list
MeeGo-kernel@lists.meego.com
http://lists.meego.com/listinfo/meego-kernel
On Fri, 5 Nov 2010 14:54:37 -0700
Russ Gorby wrote:
>
> Signed-off-by: Russ Gorby
Working back through the backlog..
> @@ -623,6 +627,14 @@ static int ifx_spi_write(struct tty_struct *tty,
> const unsigned char *buf, int srdy_value;
>
> dev_dbg(&ifx_dev->spi_dev->dev, "%s called", _
> Because the wl12xx is not i2c nor spi driver, and has a number of
> specific init that must be done after scu is up.
So do the others.
I like your proposed patch, it gives you what you need, fits the
existing stuff nicely and works for future requirements.
Alan
On Thu, 11 Nov 2010 15:07:57 +0800
Hong Liu wrote:
> Based on comments from Alan Stern, correct the setting of runtime PM
> state in probe() and remove().
All applied (thanks for the other bits Leonard)
We shpuld probably delete the copy in staging now
__
On Fri, 19 Nov 2010 16:02:29 +
"Seibel, Eric" wrote:
> Re-sending after more internal review:
>
> From 61bdfd18e5b1527d9c175e9c532c6c22b7ee713a Mon Sep 17 00:00:00 2001
> From: Pierre Tardy
> Date: Thu, 18 Nov 2010 20:11:37 +0100
> Subject: [PATCH 3/6] mrst.c: make the delayed device mechan
> > + WARN_ON(s_attr->nr != 0&& s_attr->nr != 1);
>
> hmm WARN_ON() on user input ? that's not generally nice..
It's not user input
> > +static int enable_interrupt(struct cmd_info *cinfo)
> > +{
> > + int ret;
> > +
> > + /* Workaround till an sfi table entry comes */
> > +
> +static int mrst_i2c_runtime_idle(struct device *dev)
> +{
> + int err = 0;
> +
> + err = pm_schedule_suspend(dev, 500);
Please don't stick in un-needed initialisers (err = 0). These will hide
any real errors later on, and gcc is usually very good at finding them
if this is not done.
>
On Mon, 22 Nov 2010 09:46:01 +0800
Feng Tang wrote:
> Hi all,
>
> Pls review this patch.
>
> It has also been submitted to Linux serial list and Greg KH, post it
> here for Meego kernel and AC tree's adoption.
Added to -ac tree.
Alan
___
MeeGo-ker
> + len = kfifo_in_locked(dlci->fifo, skb->data, skb->len,
> &dlci->lock);
> + len = skb->len - len;
> + dev_kfree_skb(skb);
> + netif_start_queue(net);
> + gsm_dlci_data_kick(dlci);
Ok this fails in some cases. You need to ensure the ip packet goes out
as a single mux frame. J
On Wed, 24 Nov 2010 16:46:10 +0800
"Wu, Hao" wrote:
> Hi
>
> Thanks for let us know this issue.
> some OTG patches are accepted in 37 kernel, but langwell_udc driver
> otg related patches are missed. So compilation errors found here.
>
> This issue can be reproduced with 37-rc3 mainline kernel
On Thu, 25 Nov 2010 12:52:19 +0800
"Yang, Bin" wrote:
> Hi Arjan,
> I check all patches on
> git://gitorious.org/meego-os-base/kernel-source.git, but I don't find
> pm_runtime_set_autosuspend_delay definition in these patches
I'm not sure 2.6.35 had that function - but 2.6.37 will so I'll
One of the pending patches is to clean up the platform start up code to
include generic callbacks when the SCU IPC mechanism is discovered.
What logically follows on from that is to add a notifier so that
drivers can ask to be called back when the SCU appears or disappears.
Sorting this out is on
On Fri, 26 Nov 2010 14:54:15 +0800
wrote:
> The FIFO buffer size is different with different CPU stepping.
> Define it as 32-byte; it is safe for all CPU stepping.
>
> There is a problem when xfer size is greater then FIFO buffer size.
> Implement software fragmentation in host bus driver.
> So
On Mon, 29 Nov 2010 14:11:52 +0800
Feng Tang wrote:
> Cc: Jacob Pan
> Signed-off-by: Feng Tang
All added
___
MeeGo-kernel mailing list
MeeGo-kernel@lists.meego.com
http://lists.meego.com/listinfo/meego-kernel
> + /* check the available fifo space for the packet*/
> + len = kfifo_size(dlci->fifo) - kfifo_len(dlci->fifo);
> + if (len < skb->len)
> + return NETDEV_TX_BUSY;
> +
> + len = kfifo_in_locked(dlci->fifo, skb->data, skb->len,
> &dlci->lock);
> + len = skb->len - len
> Use dlci->skb and modify gsm_dlci_data_output to grab packets from
> dlci->skb if the fifo is empty?
>
> Cheers,
> Waldo
>
See gsm_dlci_data_output_framed - its not tested but it is there to
handle exactly this task.
___
MeeGo-kernel mailing list
Me
On Tue, 30 Nov 2010 16:53:07 +
"Popescu, CatalinX" wrote:
> I have a question regarding the synchronization mechanism
> wait_for_completion_interruptible_timeout. Sometimes, it just returns
> an ERESTARTSYS error because the scheduler detects a pending signal :
> TIF_SIGPENDING is set into th
On Thu, 2 Dec 2010 17:12:38 +0800
Hong Liu wrote:
> Use IPC driver to do the real work. For power_off, we need to detect
> the charger connection status. If it is connected, we need to boot
> into a special mode (active dead) to do the battery charging.
I've merged this and Alek's patch for ups
On Thu, 2 Dec 2010 22:31:46 +0530
Madhav Chauhan wrote:
> Hi ,
> Then wats the process of capturing frame buffer??
> For capturing framebuffer in kernel we need that address.
> Are you aware any utility so that we can capture framebuffer and dump
> it as image like printscreen??
> We are using me
On Mon, 6 Dec 2010 20:57:51 +0800
"Wu, Hao" wrote:
> From 4599750d1c6fd11672d7f8182bd9443795911e22 Mon Sep 17 00:00:00 2001
> From: Hao Wu
> Date: Sun, 28 Nov 2010 15:05:03 +0800
> Subject: [PATCH] usb: add support for MHL-USB coexistence
>
> MHL (Mobile High-Definition Link) shares the same po
On Mon, 6 Dec 2010 22:27:31 +0800
"Wu, Hao" wrote:
> >On Mon, 6 Dec 2010 20:57:51 +0800
> >"Wu, Hao" wrote:
> >
> >> From 4599750d1c6fd11672d7f8182bd9443795911e22 Mon Sep 17 00:00:00
> >> 2001 From: Hao Wu
> >> Date: Sun, 28 Nov 2010 15:05:03 +0800
> >> Subject: [PATCH] usb: add support for MHL
> +#define BATT_INTR_SRAM_ADDR 0x7FC3
> +#define BATT_OCV_SRAM_ADDR 0x3008
These should be coming from the firmware not hardcoded.
> - install_irq_resource(pdev, pentry->irq);
> +
> + if (!strcmp(pentry->name, "msic_battery"))
> +
> I don't know of any PVR dependency or any non-free user space
> dependencies. The MHL function provides a different physical
> connector for HDMI output, but outside of the kernel it looks just
> like HDMI.
Just for the general Meego record - sorted off-list - Bonnie Packert is
right - there isn
We scrubbed all the other stuff out of the driver as it was not being
used and not needed (as well as in places wrong for upstream standards).
It might make sense to put the interrupt back *if* it is being used and
needed, otherwise I would just submit any needed changes to the
existing slimmed do
On Fri, 10 Dec 2010 10:38:13 +0800
wrote:
> There is a possible that lost the last word of a transaction if data
> is not ready.
> Read again in poll_transfer() to solve this issue when poll_mode is
> enabled.
>
> Patch is against mainline (2.6.37-rc5).
Applied to mid-ref tree
Alan
___
On Fri, 10 Dec 2010 14:10:15 +0800
wrote:
> From 477d1826271fae5e41ea6c9a2bc2a3b5185d049a Mon Sep 17 00:00:00 2001
> From: Jekyll Lai
> Date: Fri, 10 Dec 2010 13:23:47 +0800
> Subject: [PATCH] emc1403: added emc1423 support
> emc1423 uses the similar register and adds a hardware shutdown pin to
On Fri, 10 Dec 2010 17:32:31 -0800
"Mills, Ken K" wrote:
> Fix message length handling when building header
All three queued
___
MeeGo-kernel mailing list
MeeGo-kernel@lists.meego.com
http://lists.meego.com/listinfo/meego-kernel
On Tue, 14 Dec 2010 21:31:25 +0530
"Babu, Ramesh" wrote:
> From: Vinod Koul
>
> This patch adds new IOCTL for application interface.
>
> Using parameter tuning IOCTL, application can fine
> tune the audio firmware for it's requirement.
>
> Signed-off-by: Vinod Koul
> Signed-off-by: Ramesh Ba
On Mon, 20 Dec 2010 14:52:14 +0800
wrote:
> It's a general case that one platform uses different keypad matrix to
> support different projects. In the case of mid_keypad driver, we would
> like to add subvendor id to distinguish which keypad will be used.
> Keypad driver get pci_device_id infomat
> Instead, all our devices should be coming from the SFI table, which
> tells you exactly where the device
> is on the bus, so no need for detection at all!
The decision about whether to do runtime detection is controlled by the
bus driver. The device driver having that support will not slow down
On Mon, 20 Dec 2010 15:43:06 +0530
"Babu, Ramesh" wrote:
> From: Vinod Koul
>
> This patch adds new IOCTL for application interface.
>
> Using parameter tuning IOCTL, application can fine
> tune the audio firmware for it's requirement.
>
> Signed-off-by: Vinod Koul
> Signed-off-by: Ramesh Ba
On Fri, 17 Dec 2010 17:25:24 +0530
"Pallala, Ramakrishna" wrote:
> Hi,
>
> I am sending bug fix patch for Intel MSIC battery driver.
Please try and keep separate bug fixes apart. I've applied the first
two blocks of patches but not the SFI ones - pending the hardcoded
addresses getting sorted (
> Would anyone kindly give me some comments about this driver?
> I will very appreciate that.
Definitely needs work but the core of it looks like it can be tidied up
into a nice kernel driver for upstream. Only had a quick pass over it
at this point and a brief scan of the documents so more explor
linux-2.6-mid-ref
- Now rebased on 2.6.37rc8
- Merged most of backlog
As far as I am aware the outstanding bits for merge review are the
updated B0 firmware flashing code and the n_gsm network interface
resubmission. 2.6.37 should be very very soon now, and the tree will
rebase to
> create the network interface. The IOCTL will return the index of the
> interface created.
>
> The two IOCTL commands are:
>
> ioctl( fd, GSMIOC_ENABLE_NET );
>
> ioctl( fd, GSMIOC_DISABLE_NET );
This looks basically sound - I'm not sure the kref stuff is 100% race
free but tha
On Thu, 16 Dec 2010 13:22:07 -0800
"Krishnakumar, Sudha" wrote:
> Sending patch for B0 medfield firmware update, also incorported
> review comments from Alan Cox.
This doesn't seem to match any tree I have.
Alan
___
MeeGo-kern
> Chip vendor provides a MPL (motion processing library) to control the
> micro-processor on chip via ioctl. (MPL includes some patent motions,
> dynamic firmware and algorithms for gyroscope, accelerometer and
> e-compass.) On the other hand, sensor framework in meego will
> communicate with devic
1 - 100 of 205 matches
Mail list logo
