Re: [PATCH v3] clk: add si5351 i2c common clock driver
On 18.03.2013 11:43, Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver supports
> DT kernels only and VXCO feature of si5351b is not implemented. DT
> bindings selectively allow to overwrite stored Si5351 configuration
> which is very helpful for clock generators with empty eeprom
> configuration. Corresponding device tree binding documentation is
> also added.
>
> Signed-off-by: Sebastian Hesselbarth
Tested-by: Daniel Mack
Thanks!
Daniel
> ---
> Changes from v2:
> - add curly brackets to if-else-statements (Reported by Daniel Mack)
> - fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
> - fix parameter address calculation for clk6/clk7
>
> Changes from v1:
> - remove .is_enabled functions as they read from i2c
> (Reported by Daniel Mack)
> - add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
> its own multisync
>
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Rob Landley
> Cc: Mike Turquette
> Cc: Stephen Warren
> Cc: Thierry Reding
> Cc: Dom Cobley
> Cc: Linus Walleij
> Cc: Arnd Bergmann
> Cc: Andrew Morton
> Cc: Russell King - ARM Linux
> Cc: Rabeeh Khoury
> Cc: Daniel Mack
> Cc: Jean-Francois Moine
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> .../devicetree/bindings/clock/silabs,si5351.txt| 114 ++
> .../devicetree/bindings/vendor-prefixes.txt|1 +
> drivers/clk/Kconfig|9 +
> drivers/clk/Makefile |1 +
> drivers/clk/clk-si5351.c | 1429
>
> drivers/clk/clk-si5351.h | 155 +++
> 6 files changed, 1709 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
> create mode 100644 drivers/clk/clk-si5351.c
> create mode 100644 drivers/clk/clk-si5351.h
>
> diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> new file mode 100644
> index 000..f73d2d2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
> @@ -0,0 +1,114 @@
> +Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
> +
> +Reference
> +[1] Si5351A/B/C Data Sheet
> +http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
> +
> +The Si5351a/b/c are programmable i2c clock generators with upto 8 output
> +clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
> +3 output clocks are accessible. The internal structure of the clock
> +generators can be found in [1].
> +
> +==I2C device node==
> +
> +Required properties:
> +- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
> +- reg: i2c device address, shall be 0x60 or 0x61.
> +- #clock-cells: from common clock binding; shall be set to 1.
> +- clocks: from common clock binding; list of parent clock
> + handles, shall be xtal reference clock or xtal and clkin for
> + si5351c only.
> +- #address-cells: shall be set to 1.
> +- #size-cells: shall be set to 0.
> +
> +Optional properties:
> +- pll-source: pair of (number, source) for each pll. Allows
> + to overwrite clock source of pll A (number=0) or B (number=1).
> +
> +==Child nodes==
> +
> +Each of the clock outputs can be overwritten individually by
> +using a child node to the I2C device node. If a child node for a clock
> +output is not set, the eeprom configuration is not overwritten.
> +
> +Required child node properties:
> +- reg: number of clock output.
> +
> +Optional child node properties:
> +- clock-source: source clock of the output divider stage N, shall be
> + 0 = multisynth N
> + 1 = multisynth 0 for output clocks 0-3, else multisynth4
> + 2 = xtal
> + 3 = clkin (si5351c only)
> +- drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
> +- multisynth-source: source pll A(0) or B(1) of corresponding multisynth
> + divider.
> +- pll-master: boolean, multisynth can change pll frequency.
> +
> +==Example==
> +
> +/* 25MHz reference crystal */
> +ref25: ref25M {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2500>;
> +};
> +
> +i2c-master-node {
> +
> + /* Si5351a msop10 i2c clock generator */
> + si5351a: clock-generator@60 {
> + compatible = "silabs,si5351a-msop";
> + reg = <0x60>;
> + #add
Re: [PATCH 2/2] of: remove /proc/device-tree
On Wed, Mar 20, 2013 at 4:19 PM, Rob Herring wrote: > On 03/20/2013 09:51 AM, Grant Likely wrote: >> The same data is now available in sysfs, so we can remove the code >> that exports it in /proc and replace it with a symlink to the sysfs >> version. >> >> Tested on versatile qemu model and mpc5200 eval board. More testing >> would be appreciated. > > I would suggest testing with lshw in particular. That's the only > /proc/device-tree user I've come across. kexec is another one. Not to mention various vendor scripts that aren't necessarily public. Don't such things also fall under the "we do not break userspace compatibility - ever" rule? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] clk: add si5351 i2c common clock driver
Hi Michal, On 20.03.2013 14:55, michal.bachr...@gmail.com wrote: > Thanks for writing this driver! I have tested your si5351 clock > driver and his tuning capabilities. It works well, it generates > proper clock frequency, but when new frequency is generated, little > clock gap (1ms) is generated. Si5351 datasheet and WP claims, clock > tuning can be without gaps - > http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5350-51-Frequency-Shifting-WP.pdf > > I made some tests with Si5351A chip and I found that when tuning touch > only Multisynth registers, it can tune without gaps. There is no need > for soft PLL reset. I found also, accessing Multisynth registers is not > atomic, so there can be another frequency at output, while not all > registers are written. Writing only to one register seems to be atomic. Yeah, but limiting possible changes to the PLLs to one single register also means that you cannot offer to generate all the frequencies any more. What could probably be done is refine the algorithm so that it stays 'as close as possible' to the former values, but I'm not sure how much work that implies. Can you provide a patch against Sebastian's v3 to do that? Then it can be cleanly applied on top of the driver later. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING from tty driver in 3.9-rc0
On Tue, Feb 26, 2013 at 10:25 PM, Larry Finger wrote: > Hi, > > With v3.8-8693-gbf722a0 from the mainline repo, I get the following warning > because the pointer for tty is NULL: > > [ 34.956862] WARNING: at drivers/tty/tty_buffer.c:428 > flush_to_ldisc+0x1bb/0x1c0() > [ 34.956865] Hardware name: HP Pavilion dv2700 Notebook PC > [ 34.956867] tty is NULL > [ 34.956869] Modules linked in: arc4 b43 mac80211 cfg80211 > snd_hda_codec_conexant snd_hda_intel rfkill snd_hda_codec ipv6 snd_pcm > kvm_amd snd_seq kvm bcma rng_core snd_timer snd_seq_device ssb mmc_core snd > pcmcia sr_mod cdrom sg soundcore forcedeth pcmcia_core snd_page_alloc > i2c_nforce2 i2c_core k8temp hwmon ehci_pci battery ac serio_raw joydev video > wmi button autofs4 ext4 mbcache jbd2 crc16 ohci_hcd ehci_hcd usbcore > usb_common thermal processor scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac > scsi_dh_emc scsi_dh ata_generic pata_acpi pata_amd > [ 34.956936] Pid: 270, comm: kworker/1:1 Not tainted 3.8.0+ #92 > [ 34.956939] Call Trace: > [ 34.956944] [] ? flush_to_ldisc+0x120/0x1c0 > [ 34.956951] [] warn_slowpath_common+0x7a/0xc0 > [ 34.956955] [] warn_slowpath_fmt+0x41/0x50 > [ 34.956959] [] flush_to_ldisc+0x1bb/0x1c0 > [ 34.956964] [] process_one_work+0x1f1/0x660 > [ 34.956968] [] ? process_one_work+0x185/0x660 > [ 34.956972] [] worker_thread+0x110/0x380 > [ 34.956978] [] ? trace_hardirqs_on+0xd/0x10 > [ 34.956982] [] ? rescuer_thread+0x250/0x250 > [ 34.956987] [] kthread+0xd6/0xe0 > [ 34.956992] [] ? _raw_spin_unlock_irq+0x2b/0x50 > [ 34.956997] [] ? __init_kthread_worker+0x70/0x70 > [ 34.957002] [] ret_from_fork+0x7c/0xb0 > [ 34.957006] [] ? __init_kthread_worker+0x70/0x70 > [ 34.957009] ---[ end trace f467d4f2302660c1 ]--- > [ 35.585060] forcedeth :00:0a.0: irq 42 for MSI/MSI-X > [ 35.585182] forcedeth :00:0a.0 eth0: MSI enabled > [ 36.140711] [ cut here ] > > > I have not yet bisected this problem yet; however, I can if requested. Being > lazy, I hope that someone already has a patch, or can see the problem by > inspection. :) FWIW, I see the same on an ARM embedded board ... Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question about fixed-clock
Hi,
This might be a stupid question, but I'm somehow stuck here. I'm using a
driver with the following DTS sub-node:
ref25: ref25M {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <2500>;
};
clock-generator@0 {
/* ... */
#clock-cells = <1>;
clocks = <&ref25>;
}
The device driver for clock-generator uses something like the following
call to get its clock:
clk = of_clk_get(np, 0);
but the return value is ERR_PTR(-ENOENT) and I also can't find this
clock in the clk debugfs tree.
This is on a OMAP/AM33xx device with kernel 3.8-rc7 plus the -next tips
of arm-soc and omap, but with no other special clock options selected in
the config. Is there anything I'm missing to correctly instantiate the
dummy clock?
Thanks for a pointer,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fixed-clock
On Tue, Feb 19, 2013 at 12:55 AM, Daniel Mack wrote:
> Hi,
>
> This might be a stupid question, but I'm somehow stuck here. I'm using a
> driver with the following DTS sub-node:
>
> ref25: ref25M {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <2500>;
> };
>
> clock-generator@0 {
> /* ... */
> #clock-cells = <1>;
Sorry - this is actually <0>.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fixed-clock
Hi Fabio,
Hi Afzal,
On 19.02.2013 02:33, Fabio Estevam wrote:
> On Mon, Feb 18, 2013 at 8:55 PM, Daniel Mack wrote:
>> Hi,
>>
>> This might be a stupid question, but I'm somehow stuck here. I'm using a
>> driver with the following DTS sub-node:
>>
>> ref25: ref25M {
>> compatible = "fixed-clock";
>> #clock-cells = <0>;
>> clock-frequency = <2500>;
>> };
>>
>> clock-generator@0 {
>> /* ... */
>> #clock-cells = <1>;
>> clocks = <&ref25>;
>> }
>>
>> The device driver for clock-generator uses something like the following
>> call to get its clock:
>>
>> clk = of_clk_get(np, 0);
>>
>> but the return value is ERR_PTR(-ENOENT) and I also can't find this
>> clock in the clk debugfs tree.
>>
>> This is on a OMAP/AM33xx device with kernel 3.8-rc7 plus the -next tips
>> of arm-soc and omap, but with no other special clock options selected in
>> the config. Is there anything I'm missing to correctly instantiate the
>> dummy clock?
>
> Have you registered it with clk_register_fixed_rate() ?
>
> In imx we use imx_clk_fixed, which in turns call clk_register_fixed_rate().
>
> Take a look at arch/arm/mach-imx/clk-imx51-imx53.c for a reference.
Hmm no, I didn't do anything else than adding it to the DT in the first
place, hoping that a driver will pick it up and add the clock for me.
But it turns out that of_clk_init() is not called at all on my platform.
I'm doing this now from omap_generic_init() and it works. If that's an
appropriate place to call it, I can provide a patch.
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fixed-clock
On 19.02.2013 18:22, Mike Turquette wrote:
> Quoting Daniel Mack (2013-02-19 01:53:18)
>> Hi Fabio,
>> Hi Afzal,
>>
>> On 19.02.2013 02:33, Fabio Estevam wrote:
>>> On Mon, Feb 18, 2013 at 8:55 PM, Daniel Mack wrote:
>>>> Hi,
>>>>
>>>> This might be a stupid question, but I'm somehow stuck here. I'm using a
>>>> driver with the following DTS sub-node:
>>>>
>>>> ref25: ref25M {
>>>> compatible = "fixed-clock";
>>>> #clock-cells = <0>;
>>>> clock-frequency = <2500>;
>>>> };
>>>>
>>>> clock-generator@0 {
>>>> /* ... */
>>>> #clock-cells = <1>;
>>>> clocks = <&ref25>;
>>>> }
>>>>
>>>> The device driver for clock-generator uses something like the following
>>>> call to get its clock:
>>>>
>>>> clk = of_clk_get(np, 0);
>>>>
>>>> but the return value is ERR_PTR(-ENOENT) and I also can't find this
>>>> clock in the clk debugfs tree.
>>>>
>>>> This is on a OMAP/AM33xx device with kernel 3.8-rc7 plus the -next tips
>>>> of arm-soc and omap, but with no other special clock options selected in
>>>> the config. Is there anything I'm missing to correctly instantiate the
>>>> dummy clock?
>>>
>>> Have you registered it with clk_register_fixed_rate() ?
>>>
>>> In imx we use imx_clk_fixed, which in turns call clk_register_fixed_rate().
>>>
>>> Take a look at arch/arm/mach-imx/clk-imx51-imx53.c for a reference.
>>
>> Hmm no, I didn't do anything else than adding it to the DT in the first
>> place, hoping that a driver will pick it up and add the clock for me.
>> But it turns out that of_clk_init() is not called at all on my platform.
>>
>> I'm doing this now from omap_generic_init() and it works. If that's an
>> appropriate place to call it, I can provide a patch.
>>
>
> You can provide a patch, but your example above is for a dummy clock,
> correct?
No, it's a real clock with a fixed frequency on the board, which feeds
another clock chip. I thought this is what fixed-clock is for, just like
what a fixed-regulator does? Or how would you describe such a thing in
DT, in order to use it as input to another device?
> It would be best to post your patch along with a real-world
> use for calling of_clk_init().
Not sure what you mean exactly, but the patch is attached. However, I
still think I lack some understanding here - the fact that compatible
strings have to be passed explicitly from generic code feels wrong.
Thanks,
Daniel
>From 850120371830ffb5e2146aeb2d21c724d6ded09e Mon Sep 17 00:00:00 2001
From: Daniel Mack
Date: Tue, 19 Feb 2013 12:05:25 +0100
Subject: [PATCH] ARM: OMAP: generic: add call to of_clk_init()
This is needed to instanciate fixed clocks in the DT.
Signed-off-by: Daniel Mack
---
arch/arm/mach-omap2/board-generic.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..3580f16 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
@@ -35,6 +36,11 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
{ }
};
+static const __initconst struct of_device_id clk_match[] = {
+ { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
+ {}
+};
+
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
@@ -49,6 +55,7 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible("ti,omap4-sdp"))
omap_4430sdp_display_init_of();
+ of_clk_init(clk_match);
}
#ifdef CONFIG_SOC_OMAP2420
--
1.8.1.2
Re: [PATCH] clk: add si5351 i2c common clock driver
Hi Sebastian,
I did some more tests today and it took me a while to dig for the root
cause why things were not working for me in the first place - see below.
On 09.02.2013 13:59, Sebastian Hesselbarth wrote:
> +==Example==
> +
> +/* 25MHz reference crystal */
> +ref25: ref25M {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2500>;
> +};
> +
> +i2c-master-node {
> +
> + /* Si5351a msop10 i2c clock generator */
> + si5351a: clock-generator@60 {
> + compatible = "silabs,si5351a-msop";
> + reg = <0x60>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #clock-cells = <1>;
> +
> + /* connect xtal input to 25MHz reference */
> + clocks = <&ref25>;
As referred to in another thread, registering the ref25M clock that way
didn't suffice for me on my platform - but that's a different story.
> +static void si5351_read_parameters(struct si5351_driver_data *drvdata,
> + unsigned char reg, struct si5351_parameters *params)
> +{
> + unsigned char buf[SI5351_PARAMETERS_LENGTH];
On a general note, I think you can use u8 instead of unsigned char all
over the place here, which will save you some indentation trouble.
> +static inline int _si5351_clkout_reparent(struct si5351_driver_data *drvdata,
> + unsigned char num, unsigned char parent)
> +{
> + struct clk *pclk;
> +
> + if (num > 8 ||
> + (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
> + return -EINVAL;
> +
> + switch (parent) {
> + case 0:
> + pclk = drvdata->msynth[num].hw.clk;
> + break;
> + case 1:
> + pclk = drvdata->msynth[0].hw.clk;
> + if (num >= 4)
> + pclk = drvdata->msynth[4].hw.clk;
> + break;
> + case 2:
> + pclk = drvdata->xtal.clk;
> + break;
> + case 3:
> + if (drvdata->variant != SI5351_VARIANT_C)
> + return -EINVAL;
> + pclk = drvdata->clkin.clk;
> + break;
> + default:
> + return -EINVAL;
> + }
> + return clk_set_parent(drvdata->clkout[num].hw.clk, pclk);
> +}
[...]
> +static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct si5351_hw_data *hwdata =
> + container_of(hw, struct si5351_hw_data, hw);
> + unsigned val;
> +
> + val = 0;
> + hw->clk->flags &= ~CLK_SET_RATE_PARENT;
> + switch (index) {
> + case 0:
> + hw->clk->flags |= CLK_SET_RATE_PARENT;
> + val = SI5351_CLK_INPUT_MULTISYNTH_N;
> + break;
I fugured that _si5351_clkout_reparent() wouldn't actually call
->set_parent() on the clock, which leads to the fact that
CLK_SET_RATE_PARENT is not set in the flags. That way, only the clkout
end leaf is actually supplied with a new rate, which leads to incorrect
effective clocks, depending on the current multisynth/pll configuration.
The reason for this is in clk_set_parent() itself, which bails if the
parent is already set to the passed value:
if (clk->parent == parent)
goto out;
I fixed that for now by explicitly setting the clock's parent to NULL
before calling clk_set_parent() in _si5351_clkout_reparent(), so the
calbacks are triggered. But there might be a nicer way, for example to
factor out the CLK_SET_RATE_PARENT handling to some function called from
_si5351_clkout_reparent() or so.
Anyway, with this hack in place along with the other details I mentioned
in my first mail, the driver seems to work for me now, which is great. I
will do more extensive tests later that week when I have access to
better scopes ...
Many thanks again,
Daniel
> + case 1:
> + /* clk0/clk4 can only connect to its own multisync */
> + if (hwdata->num == 0 || hwdata->num == 4)
> + val = SI5351_CLK_INPUT_MULTISYNTH_N;
> + else
> + val = SI5351_CLK_INPUT_MULTISYNTH_0_4;
> + break;
> + case 2:
> + val = SI5351_CLK_INPUT_XTAL;
> + break;
> + case 3:
> + val = SI5351_CLK_INPUT_CLKIN;
> + break;
> + }
> + si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
> + SI5351_CLK_INPUT_MASK, val);
> +
> + return 0;
> +}
> +
> +static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct si5351_hw_data *hwdata =
> + container_of(hw, struct si5351_hw_data, hw);
> + unsigned char reg = SI5351_CLK0_PARAMETERS +
> + (SI5351_PARAMETERS_LENGTH * hwdata->num);
> + unsigned char rdiv;
> +
> + rdiv = (si5351_reg_read(hwdata->drvdata, reg + 2) &
> + SI5351_OUTPUT_CLK_DIV_MASK) >> SI5351_OUTPUT_CLK_DIV_SHIFT;
> +
> +
Re: [PATCH] ALSA: usb: Fix Processing Unit Descriptor parsers
On 21.02.2013 10:03, Takashi Iwai wrote:
> At Thu, 21 Feb 2013 01:55:50 +,
> Pawel Moll wrote:
>>
>> Commit 99fc86450c439039d2ef88d06b222fd51a779176 "ALSA: usb-mixer:
>> parse descriptors with structs" introduced a set of useful parsers
>> for descriptors. Unfortunately the parses for the Processing Unit
>> Descriptor came with a very subtle bug...
>>
>> Functions uac_processing_unit_iProcessing() and
>> uac_processing_unit_specific() were indexing the baSourceID array
>> forgetting the fields before the iProcessing and process-specific
>> descriptors.
>>
>> The problem was observed with Sound Blaster Extigy mixer,
>> where nNrModes in Up/Down-mix Processing Unit Descriptor
>> was accessed at offset 10 of the descriptor (value 0)
>> instead of offset 15 (value 7). In result the resulting
>> control had interesting limit values:
>>
>> Simple mixer control 'Channel Routing Mode Select',0
>> Capabilities: volume volume-joined penum
>> Playback channels: Mono
>> Capture channels: Mono
>> Limits: 0 - -1
>> Mono: -1 [100%]
>>
>> Fixed by starting from the bmControls, which was calculated
>> correctly, instead of baSourceID.
>>
>> Now the mentioned control is fine:
>>
>> Simple mixer control 'Channel Routing Mode Select',0
>> Capabilities: volume volume-joined penum
>> Playback channels: Mono
>> Capture channels: Mono
>> Limits: 0 - 6
>> Mono: 0 [0%]
>>
>> Signed-off-by: Pawel Moll
>> ---
>> include/uapi/linux/usb/audio.h |6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/uapi/linux/usb/audio.h b/include/uapi/linux/usb/audio.h
>> index ac90037..d2314be 100644
>> --- a/include/uapi/linux/usb/audio.h
>> +++ b/include/uapi/linux/usb/audio.h
>> @@ -384,14 +384,16 @@ static inline __u8
>> uac_processing_unit_iProcessing(struct uac_processing_unit_de
>> int protocol)
>> {
>> __u8 control_size = uac_processing_unit_bControlSize(desc, protocol);
>> -return desc->baSourceID[desc->bNrInPins + control_size];
>> +return *(uac_processing_unit_bmControls(desc, protocol)
>> ++ control_size);
>> }
>>
>> static inline __u8 *uac_processing_unit_specific(struct
>> uac_processing_unit_descriptor *desc,
>> int protocol)
>> {
>> __u8 control_size = uac_processing_unit_bControlSize(desc, protocol);
>> -return &desc->baSourceID[desc->bNrInPins + control_size + 1];
>> +return uac_processing_unit_bmControls(desc, protocol)
>> ++ control_size + 1;
>> }
>
> Looks good to me.
>
> An alternative would be to change uac_processing_unit_bControlSize()
> to correct the header size, but I don't think it's good, as
> bControlSize fields in other units show the value including the header
> size.
>
> Daniel, what do you think?
Looks good to me too. and this should be marked for stable of course.
Thanks for fixing this, Pawell!
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] ASoC: tas5086: use module_i2c_driver to simplify the code
On 12.03.2013 14:36, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Use the module_i2c_driver() macro to make the code smaller
> and a bit simpler.
Thanks for catching this!
> Signed-off-by: Wei Yongjun
Acked-by: Daniel Mack
> ---
> sound/soc/codecs/tas5086.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c
> index 008bea4..40cee84 100644
> --- a/sound/soc/codecs/tas5086.c
> +++ b/sound/soc/codecs/tas5086.c
> @@ -584,17 +584,7 @@ static struct i2c_driver tas5086_i2c_driver = {
> .remove = tas5086_i2c_remove,
> };
>
> -static int __init tas5086_modinit(void)
> -{
> - return i2c_add_driver(&tas5086_i2c_driver);
> -}
> -module_init(tas5086_modinit);
> -
> -static void __exit tas5086_modexit(void)
> -{
> - i2c_del_driver(&tas5086_i2c_driver);
> -}
> -module_exit(tas5086_modexit);
> +module_i2c_driver(tas5086_i2c_driver);
>
> MODULE_AUTHOR("Daniel Mack ");
> MODULE_DESCRIPTION("Texas Instruments TAS5086 ALSA SoC Codec Driver");
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Excessive ethernet interrupts on AM335x board
On Tue, Mar 12, 2013 at 4:35 PM, Mark Jackson wrote: > I'm just fighting an issue with ethernet on our custom AM335x board:- > > # uname -a > Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 > armv7l GNU/Linux > > Every now and then, the whole unit slows to a crawl. The only indication of > any problem is:- > > (a) the serial tty port becomes much less responsive > (b) normal ping times jump from 1ms to >10sec (sometimes >20sec !!) > (c) the ethernet interrupt count rockets (see below) > > I've tried to force the problem by flood pinging from my PC. > > # while true >> do grep "58:" /proc/interrupts; sleep 10 >> done > 58: 1291 INTC 4a10.ethernet <<< normal pinging (about 100 > irqs per 10sec) > 58: 1333 INTC 4a10.ethernet > 58: 1372 INTC 4a10.ethernet > 58: 3979 INTC 4a10.ethernet <<< start flood ping (about 4k > irqs per 10sec) > 58: 6540 INTC 4a10.ethernet > 58: 17519 INTC 4a10.ethernet <<< big jump >>> > 58: 20169 INTC 4a10.ethernet > 58: 22775 INTC 4a10.ethernet > 58: 25368 INTC 4a10.ethernet > 58: 34598 INTC 4a10.ethernet <<< big jump >>> > 58: 37182 INTC 4a10.ethernet > 58: 39730 INTC 4a10.ethernet > 58: 141220 INTC 4a10.ethernet <<< whoa !!! >>> > 58: 146080 INTC 4a10.ethernet > 58: 149351 INTC 4a10.ethernet > 58: 152922 INTC 4a10.ethernet > 58: 156420 INTC 4a10.ethernet > 58: 159538 INTC 4a10.ethernet > 58: 162711 INTC 4a10.ethernet > 58: 165746 INTC 4a10.ethernet > 58: 168973 INTC 4a10.ethernet > 58: 172128 INTC 4a10.ethernet > 58: 175030 INTC 4a10.ethernet > 58: 177957 INTC 4a10.ethernet > 58: 180782 INTC 4a10.ethernet > 58: 183618 INTC 4a10.ethernet > 58: 186450 INTC 4a10.ethernet > 58: 189242 INTC 4a10.ethernet > 58: 191909 INTC 4a10.ethernet > 58: 194565 INTC 4a10.ethernet > 58: 197153 INTC 4a10.ethernet > 58: 199730 INTC 4a10.ethernet <<< another big jump >>> > 58: 252629 INTC 4a10.ethernet > 58: 262955 INTC 4a10.ethernet > 58: 265557 INTC 4a10.ethernet > 58: 268131 INTC 4a10.ethernet > 58: 272586 INTC 4a10.ethernet > 58: 275623 INTC 4a10.ethernet <<< here I stop flood pings >>> > [ 631.727758] nfs: server 10.0.0.100 not responding, still trying > [ 638.738864] nfs: server 10.0.0.100 OK > 58: 277694 INTC 4a10.ethernet > 58: 277703 INTC 4a10.ethernet > 58: 277709 INTC 4a10.ethernet > 58: 277719 INTC 4a10.ethernet > 58: 277725 INTC 4a10.ethernet > 58: 277734 INTC 4a10.ethernet > 58: 277745 INTC 4a10.ethernet > > As you can see, when I stop the flood pings, the nfs link is now reported > as being lost. I had the same problem. Please check this patch, I'm sure it will fix you issue: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d35162f89b8f00537d7b240b76d2d0e8b8d29aa0 Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mach-moxart: platform port for MOXA ART SoC
Hi Jonas, On 13.03.2013 16:37, Jonas Jensen wrote: > I ask for feedback and to submit (if possible) a new ARM SoC platform > port. This is now near complete (I think) (tested on UC-7112-LX Plus) > and applies to 2.6.34.14. First of all - thanks for submitting to the upstream kernel! However, your patch has many severe problems which you need to address. * please rebase your work. 2.6.34 is almost three years old now. 3.9 is in it's stabilisation phase, and all new support has to be done for 3.10. * all new platforms must be written with device-tree support * all drivers must have device-tree support as well > The patch contains the following drivers and platform specific implementations: > > * ARCH_MOXART (FA526 processor) > * 100Hz interrupt timer > * UART > * MTD map driver > * Ethernet driver (RTL8201CP) > * MMC driver > * MOXA Smartio/Industio family multiport serial driver > * RTC driver > * Watchdog driver > * GPIO driver Never send one big patch but series of smaller ones, so the individual subsystem maintainers can review and approve their bits. Please also read Documentation/SubmittingPatches for a lot more information about this subject. Best regards, Daniel > Predicted patch rejects below (in need of a solution, feedback is much > appreciated) because they are critical in areas of boot, MMC and TTY. > > arch/arm/boot/compressed/head.S: > A valid (and unique) architecture ID is not loaded to r1. Looks like > the bootloader is broken, it should be doing this! > http://gicl.cs.drexel.edu/people/sevy/linux/ARM_Linux_boot_sequence.html > > arch/arm/tools/mach-types: > Omitted (do not edit manually / add a new machine using > http://www.arm.linux.org.uk/developer/machines/?action=new). A fix to > this and above is not feasible as long as MOXA withholds bootloader > sources (requested without success). > > drivers/char/mxser.c drivers/char/mxser.h: MOXA > SMARTIO/INDUSTIO/INTELLIO SERIAL CARD (Jiří Slabý): > Force board setup for CONFIG_ARCH_MOXART. > ASYNCB_CLOSING is avoided because of a lockup (infinite wait after > tty_wait_until_sent). Why this happens is unknown (to me) I'm hoping > someone (Jiří?) can shed light. SysRq trace @ http://ideone.com/e845mr > What significance does ASYNCB_CLOSING have? > Obviously, automatic detection is better but "mxser_read_register" is > pointless on this hardware. What to do instead? Is it better to make a > copy and submit a new driver? > > drivers/mmc/core/sd.c: > The MMC controller is "special"? "UNSTUFF_BITS" is redefined here > http://repo.or.cz/w/linux-2.6.19-moxart.git/blob/50cdf2c57662f9f69c5615976412f76bfd73311a:/drivers/mmc/mmc.c > . Without the new macro it'll report the wrong geometry and prod_name. > I'm thinking a driver should never have to redefine UNSTUFF_BITS. > Possible workaround: modify bits (in driver) to line up as expected > before returning the response (mmc_request_done). > > > For reference, this is my previous post from a few months back: > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137130.html > > Gitweb: > http://repo.or.cz/w/linux-2.6.34.14-moxart.git/commitdiff/?h=3bc2e98ebb92961e1c5992736186920cd070f4ee&hp=b7f1d43323eceb02fd663a71eb2f8be9c17e6740 > > Download link (size: 193K): > https://linux-2-6-34-14-moxart.googlecode.com/files/linux-2.6.34.14-moxart.patch > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] clk: add si5351 i2c common clock driver
Hi Sebastian,
On 16.03.2013 14:10, Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver supports
> DT kernels only and VXCO feature of si5351b is not implemented. DT
> bindings selectively allow to overwrite stored Si5351 configuration
> which is very helpful for clock generators with empty eeprom
> configuration. Corresponding device tree binding documentation is
> also added.
>
> Signed-off-by: Sebastian Hesselbarth
> ---
> Changes from v1:
> - remove .is_enabled functions as they read from i2c
> (Reported by Daniel Mack)
> - add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
> its own multisync
>
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Rob Landley
> Cc: Mike Turquette
> Cc: Stephen Warren
> Cc: Thierry Reding
> Cc: Dom Cobley
> Cc: Linus Walleij
> Cc: Arnd Bergmann
> Cc: Andrew Morton
> Cc: Russell King - ARM Linux
> Cc: Rabeeh Khoury
> Cc: Daniel Mack
> Cc: Jean-Francois Moine
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> .../devicetree/bindings/clock/silabs,si5351.txt| 114 ++
> .../devicetree/bindings/vendor-prefixes.txt|1 +
> drivers/clk/Kconfig|9 +
> drivers/clk/Makefile |1 +
> drivers/clk/clk-si5351.c | 1413
>
> drivers/clk/clk-si5351.h | 155 +++
> 6 files changed, 1693 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
> create mode 100644 drivers/clk/clk-si5351.c
> create mode 100644 drivers/clk/clk-si5351.h
[...]
> +static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct si5351_hw_data *hwdata =
> + container_of(hw, struct si5351_hw_data, hw);
> + unsigned char reg = SI5351_CLK0_PARAMETERS +
> + (SI5351_PARAMETERS_LENGTH * hwdata->num);
> + unsigned long long rate;
> + unsigned long m;
> +
> + if (!hwdata->params.valid)
> + si5351_read_parameters(hwdata->drvdata, reg, &hwdata->params);
> +
> + if (hwdata->params.p3 == 0)
> + return parent_rate;
> +
> + /*
> + * multisync0-5: fOUT = (128 * P3 * fIN) / (P1*P3 + P2 + 512*P3)
> + * multisync6-7: fOUT = fIN / P1
> + */
> + rate = parent_rate;
> + if (hwdata->num > 5)
> + m = hwdata->params.p1;
> + else if ((si5351_reg_read(hwdata->drvdata, reg + 2) &
> + SI5351_OUTPUT_CLK_DIVBY4) == SI5351_OUTPUT_CLK_DIVBY4)
> + m = 4;
> + else {
> + rate *= 128 * hwdata->params.p3;
> + m = hwdata->params.p1 * hwdata->params.p3;
> + m += hwdata->params.p2;
> + m += 512 * hwdata->params.p3;
> + }
A nit only, but according to Documentation/CodingStyle, all if/else
blocks need curly brackets if any of them needs them. Maybe there are
more places which are affected.
> + do_div(rate, m);
I still have the problem that m == 0 in my case as I only set up two
clocks from my DT - which leads to a DIV0. The easiest fix is certainly
to bail here in that case.
Another option would be to only register the clocks to the framework
that are actually set up from DT, but that would require more rework at
the driver's probe level.
Other than that, this driver works perfectly for me - thanks again for
your work!
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fuse: mark variables uninitialized
gcc 4.6.3 complains about uninitialized variables in fs/fuse/control.c:
CC fs/fuse/control.o
fs/fuse/control.c: In function ‘fuse_conn_congestion_threshold_write’:
fs/fuse/control.c:165:29: warning: ‘val’ may be used uninitialized in this
function [-Wuninitialized]
fs/fuse/control.c: In function ‘fuse_conn_max_background_write’:
fs/fuse/control.c:128:23: warning: ‘val’ may be used uninitialized in this
function [-Wuninitialized]
fuse_conn_limit_write() will always return non-zero unless the &val
is modified, so the warning is misleading. Let the compiler know
about it by marking 'val' with 'uninitialized_var'.
Signed-off-by: Daniel Mack
Cc: Brian Foster
Cc: Miklos Szeredi
---
fs/fuse/control.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/fuse/control.c b/fs/fuse/control.c
index 03ff5b1..75a20c0 100644
--- a/fs/fuse/control.c
+++ b/fs/fuse/control.c
@@ -117,7 +117,7 @@ static ssize_t fuse_conn_max_background_write(struct file
*file,
const char __user *buf,
size_t count, loff_t *ppos)
{
- unsigned val;
+ unsigned uninitialized_var(val);
ssize_t ret;
ret = fuse_conn_limit_write(file, buf, count, ppos, &val,
@@ -154,7 +154,7 @@ static ssize_t fuse_conn_congestion_threshold_write(struct
file *file,
const char __user *buf,
size_t count, loff_t *ppos)
{
- unsigned val;
+ unsigned uninitialized_var(val);
ssize_t ret;
ret = fuse_conn_limit_write(file, buf, count, ppos, &val,
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech USB headset not working in 3.6-rc3
On 25.08.2012 14:17, Josh Boyer wrote:
> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
>> On 25.08.2012 14:07, Bruno Wolff III wrote:
>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
>>>Daniel Mack wrote:
>>>>
>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
>>>
>>> I can try that, but it takes a long time to build a new kernel on my
>>> old hardware.
>>>
>>>> helps? If not, can you summarize again which kernels still work for you
>>>> and which don't?
>>>
>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
>>>
>>
>> The report you sent doesn't look like it could be caused by e9ba389c5.
>> It fixes a kernel Ooops. But as it is the only relevant patch in that
>> area, it would be interesting if reverting it fixes anything.
>
> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
> git bisect, Bruno.
>
>> Btw - thanks a lot for testing -rc kernels, much appreciated!
>
> Indeed!
Could you please try this patch on top of Takashi's? Thanks again!
Daniel
>From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
From: Daniel Mack
Date: Wed, 29 Aug 2012 13:17:05 +0200
Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
PCM capture stream") fixed a scheduling-while-atomic bug that happened
when snd_usb_endpoint_start was called from the trigger callback, which
is an atmic context. However, the patch breaks the idea of the endpoints
reference counting, which is the reason why the driver has been
refactored lately.
Revert that commit and let snd_usb_endpoint_start() take care of the URB
cancellation again. As this function is called from both atomic and
non-atomic context, add a flag to denote whether the function may sleep.
Signed-off-by: Daniel Mack
Cc: sta...@kernel.org [3.5+]
---
sound/usb/endpoint.c | 10 --
sound/usb/endpoint.h | 2 +-
sound/usb/pcm.c | 13 +
3 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index c411812..678456c 100644
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
/**
* snd_usb_endpoint_start: start an snd_usb_endpoint
*
- * @ep: the endpoint to start
+ * @ep: the endpoint to start
+ * @can_sleep: flag indicating whether the operation is executed in
+ * non-atomic context
*
* A call to this function will increment the use count of the endpoint.
* In case it is not already running, the URBs for this endpoint will be
@@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
*
* Returns an error if the URB submission failed, 0 in all other cases.
*/
-int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
+int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
{
int err;
unsigned int i;
@@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
if (++ep->use_count != 1)
return 0;
+ /* just to be sure */
+ deactivate_urbs(ep, 0, can_sleep);
+ wait_clear_urbs(ep);
+
ep->active_mask = 0;
ep->unlink_mask = 0;
ep->phase = 0;
diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
index ee2723f..a8e60c1 100644
--- a/sound/usb/endpoint.h
+++ b/sound/usb/endpoint.h
@@ -13,7 +13,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
struct audioformat *fmt,
struct snd_usb_endpoint *sync_ep);
-int snd_usb_endpoint_start(struct snd_usb_endpoint *ep);
+int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
int force, int can_sleep, int wait);
int snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index 62ec808..1546577 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -212,7 +212,7 @@ int snd_usb_init_pitch(struct snd_usb_audio *chip, int iface,
}
}
-static int start_endpoints(struct snd_usb_substream *subs)
+static int start_endpoints(struct snd_usb_substream *subs, int can_sleep)
{
int err;
@@ -225,7 +225,7 @@ static int start_endpoints(struct snd_usb_substream *subs)
snd_printdd(KERN_DEBUG "Starting data EP @%p\n", ep);
ep->data_subs = subs;
- err = snd_usb_endpoint_start(ep);
+ err = snd_usb_endpoint_start(ep, can_sleep);
if (err < 0) {
clear_bit(SUBSTREAM_FLAG_DATA_EP_STARTED, &subs->flags);
return err;
@@ -239,7 +239,7 @@ static int start_endpoint
Re: Logitech USB headset not working in 3.6-rc3
On 29.08.2012 15:29, Takashi Iwai wrote:
> At Wed, 29 Aug 2012 13:26:25 +0200,
> Daniel Mack wrote:
>>
>> [1 ]
>> On 25.08.2012 14:17, Josh Boyer wrote:
>>> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
>>>> On 25.08.2012 14:07, Bruno Wolff III wrote:
>>>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
>>>>>Daniel Mack wrote:
>>>>>>
>>>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>>>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
>>>>>
>>>>> I can try that, but it takes a long time to build a new kernel on my
>>>>> old hardware.
>>>>>
>>>>>> helps? If not, can you summarize again which kernels still work for you
>>>>>> and which don't?
>>>>>
>>>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest
>>>>> that
>>>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
>>>>>
>>>>
>>>> The report you sent doesn't look like it could be caused by e9ba389c5.
>>>> It fixes a kernel Ooops. But as it is the only relevant patch in that
>>>> area, it would be interesting if reverting it fixes anything.
>>>
>>> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
>>> git bisect, Bruno.
>>>
>>>> Btw - thanks a lot for testing -rc kernels, much appreciated!
>>>
>>> Indeed!
>>
>> Could you please try this patch on top of Takashi's? Thanks again!
>>
>>
>> Daniel
>>
>> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch
>> ]
>> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
>> From: Daniel Mack
>> Date: Wed, 29 Aug 2012 13:17:05 +0200
>> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
>>
>> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
>> PCM capture stream") fixed a scheduling-while-atomic bug that happened
>> when snd_usb_endpoint_start was called from the trigger callback, which
>> is an atmic context. However, the patch breaks the idea of the endpoints
>> reference counting, which is the reason why the driver has been
>> refactored lately.
>>
>> Revert that commit and let snd_usb_endpoint_start() take care of the URB
>> cancellation again. As this function is called from both atomic and
>> non-atomic context, add a flag to denote whether the function may sleep.
>>
>> Signed-off-by: Daniel Mack
>> Cc: sta...@kernel.org [3.5+]
>> ---
>> sound/usb/endpoint.c | 10 --
>> sound/usb/endpoint.h | 2 +-
>> sound/usb/pcm.c | 13 +
>> 3 files changed, 14 insertions(+), 11 deletions(-)
>>
>> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
>> index c411812..678456c 100644
>> --- a/sound/usb/endpoint.c
>> +++ b/sound/usb/endpoint.c
>> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint
>> *ep,
>> /**
>> * snd_usb_endpoint_start: start an snd_usb_endpoint
>> *
>> - * @ep: the endpoint to start
>> + * @ep: the endpoint to start
>> + * @can_sleep: flag indicating whether the operation is executed in
>> + * non-atomic context
>> *
>> * A call to this function will increment the use count of the endpoint.
>> * In case it is not already running, the URBs for this endpoint will be
>> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint
>> *ep,
>> *
>> * Returns an error if the URB submission failed, 0 in all other cases.
>> */
>> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
>> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
>> {
>> int err;
>> unsigned int i;
>> @@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
>> if (++ep->use_count != 1)
>> return 0;
>>
>> +/* just to be sure */
>> +deactivate_urbs(ep, 0, can_sleep);
>> +wait_clear_urbs(ep);
>
> It'd be safer to protect the call of wait_clear_urbs() when
> can_sleep=0.
Right. New patch attached.
>From 42ff3e2d34427dc4c6faa09052a2531f2e71d7d6 Mon Sep 17 00:00:00 2001
From: Daniel Mack
Date: Wed, 29 Aug 2012 13:17:05 +0200
Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
Commit e9ba389c5 ("ALSA: usb-a
Re: Logitech USB headset not working in 3.6-rc3
On 29.08.2012 16:14, Takashi Iwai wrote:
> At Wed, 29 Aug 2012 15:32:34 +0200,
> Daniel Mack wrote:
>>
>> [1 ]
>> On 29.08.2012 15:29, Takashi Iwai wrote:
>>> At Wed, 29 Aug 2012 13:26:25 +0200,
>>> Daniel Mack wrote:
>>>>
>>>> [1 ]
>>>> On 25.08.2012 14:17, Josh Boyer wrote:
>>>>> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
>>>>>> On 25.08.2012 14:07, Bruno Wolff III wrote:
>>>>>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
>>>>>>>Daniel Mack wrote:
>>>>>>>>
>>>>>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>>>>>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
>>>>>>>
>>>>>>> I can try that, but it takes a long time to build a new kernel on my
>>>>>>> old hardware.
>>>>>>>
>>>>>>>> helps? If not, can you summarize again which kernels still work for you
>>>>>>>> and which don't?
>>>>>>>
>>>>>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest
>>>>>>> that
>>>>>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
>>>>>>>
>>>>>>
>>>>>> The report you sent doesn't look like it could be caused by e9ba389c5.
>>>>>> It fixes a kernel Ooops. But as it is the only relevant patch in that
>>>>>> area, it would be interesting if reverting it fixes anything.
>>>>>
>>>>> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
>>>>> git bisect, Bruno.
>>>>>
>>>>>> Btw - thanks a lot for testing -rc kernels, much appreciated!
>>>>>
>>>>> Indeed!
>>>>
>>>> Could you please try this patch on top of Takashi's? Thanks again!
>>>>
>>>>
>>>> Daniel
>>>>
>>>> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch
>>>> ]
>>>> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
>>>> From: Daniel Mack
>>>> Date: Wed, 29 Aug 2012 13:17:05 +0200
>>>> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
>>>>
>>>> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
>>>> PCM capture stream") fixed a scheduling-while-atomic bug that happened
>>>> when snd_usb_endpoint_start was called from the trigger callback, which
>>>> is an atmic context. However, the patch breaks the idea of the endpoints
>>>> reference counting, which is the reason why the driver has been
>>>> refactored lately.
>>>>
>>>> Revert that commit and let snd_usb_endpoint_start() take care of the URB
>>>> cancellation again. As this function is called from both atomic and
>>>> non-atomic context, add a flag to denote whether the function may sleep.
>>>>
>>>> Signed-off-by: Daniel Mack
>>>> Cc: sta...@kernel.org [3.5+]
>>>> ---
>>>> sound/usb/endpoint.c | 10 --
>>>> sound/usb/endpoint.h | 2 +-
>>>> sound/usb/pcm.c | 13 +
>>>> 3 files changed, 14 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
>>>> index c411812..678456c 100644
>>>> --- a/sound/usb/endpoint.c
>>>> +++ b/sound/usb/endpoint.c
>>>> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct
>>>> snd_usb_endpoint *ep,
>>>> /**
>>>> * snd_usb_endpoint_start: start an snd_usb_endpoint
>>>> *
>>>> - * @ep: the endpoint to start
>>>> + * @ep: the endpoint to start
>>>> + * @can_sleep:flag indicating whether the operation is executed in
>>>> + *non-atomic context
>>>> *
>>>> * A call to this function will increment the use count of the endpoint.
>>>> * In case it is not already running, the URBs for this endpoint will be
>>>> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct
>>>> snd_usb_endpoint *ep,
>>>> *
>>>> * Returns an error if the URB submission failed, 0 in all other cases.
>>>> */
>>>> -int snd_us
Re: [PATCH v2] regulator: gpio-regulator: add DT bindings
Hi Stephen,
On 10.09.2012 21:40, Stephen Warren wrote:
> On 09/10/2012 09:03 AM, Daniel Mack wrote:
>> Add DT bindings for the gpio-regulator driver and some documentation on
>> how to use it.
>
>> +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
>> @@ -0,0 +1,58 @@
>> +Device tree bindings for GPIO controlled voltages
>> +
>> +Voltage or current regulators on boards that are controlled by GPIOs can
>> +be used by the gpio-regulator driver.
>> +
>> +Required properties:
>> +
>> + - "compatible":must be set to "gpio-regulator"
>> + - "regulator-name":must be set to a string describing the name of
>> this
>> +regulator.
>
> I'd expect the "gpios" property to be listed here.
Yes, I'll add that.
>
>> +Optional properties:
>> +
>> + - "startup-delay": Start-up time in microseconds
>> + - "enable-high": Polarity of enable GPIO. Active high if
>> +defined, otherwise active low
>
> fixed-regulator.txt already has an "enable-active-high" property; it'd
> be nice to be consistent.
Ok.
>> + - "enabled-at-boot": If set, the regulator has been enabled
>> at boot
>> +time
>
> Isn't that regulator-boot-on, as defined in regulator.txt that you
> mentioned?
>
>> + - "regulator-type-voltage":The regulator controls a voltage
>> + - "regulator-type-current":The regulator controls a current
>
> I wonder if it'd be better to differentiate this using different
> compatible values instead?
I like this idea. Will make that "gpio-voltage-regulator" and
"gpio-current-regulator".
>
>> + - "states":An array of possible states, describing
>> the
>> +GPIO states to reach a given value
>> +- "value": The value of the state, in microvolts or
>> +microamperes
>
> A name like "microvolts", "voltage", "microamps", or "current" might be
> more descriptive here.
I'm for "microvolts" and "microamperes". Will change. I just thought it
might be good to keep as close to the struct member names for making it
easiest for users to convert over to DT, but you're right, a more
descriptive property name is certainly better.
>> +- "gpios": bitfield of gpio target-states for the value
>> +The n-th bit in the bitfield describes the
>> +state of the n-th GPIO from the gpios-array
>
> "gpios" sounds like the name of a property that defines which GPIOs are
> used, rather than the value of those GPIOs. Perhaps "gpio-values" instead?
>
> Actually, I wonder if we really even need to represent that values
> explicitly; rather than have a big set of nodes, perhaps you can instead
> have a single property that lists the voltage (or current) that each
> combination of GPIO values gives; something like:
>
> reg_gpio {
> ...
> gpios = <&ggpio 23 0 &gpio 24 0>;
> voltages = <0 100 200 300>;
> };
>
> (As inspiration for that, I looked at
> Documentation/devicetree/bindings/net/mdio-mux-gpio.txt which doesn't
> have a property defining the value of the GPIOs for each combination,
> but rather a node per valid combination).
>
> Perhaps represent and invalid GPIO combination with 0x?
Sorry, I don't follow you on this one. How would you specify the
voltages that way? And The driver allows for arbitrary GPIO patterns to
be set on the GPIOs in order to reach a specific voltage. Could you give
me another example how that would look like in your approach?
Once that topic is agreed on, I'll send out a new version.
>> +Also, all properties described in
>> +Documentation/devicetree/bindings/regulator/regulator.txt are supported as
>> +well.
>> +
>> +Example:
>> +
>> +reg_gpio {
>> +compatible = "gpio-regulator";
>> +regulator-name = "voltage";
>> +regulator-enable-high;
>> +regulator-type-voltage;
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +regulator-always-on;
>> +
>> +gpios = <&gpio 23 0>;
>> +
>> +
Re: FTDI Linux Kernel Driver
Hi Ryan,
On 04.10.2012 04:08, Ryan A. Krenzischek wrote:
> Patch Description: Add product id in ftdi_sio.c struct table ( static
> struct usb_device_id id_table_combined []) and include a define
> statement in ftdi_sio_ids.h for RTSYSTEMS CT63 Radio Cable.
Thanks for sending patches to the mainline maintainers.
However, note that the format you sent them in is not appropriate. Could
you please read Documentation/SubmittingPatches and resend?
Daniel
>
> Output from dmesg regarding the hardware:
>
> [ 5489.423407] usb 10-1: New USB device found, idVendor=2100, idProduct=9e58
> [ 5489.423414] usb 10-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 5489.423421] usb 10-1: Product: CT63 Radio Cable
> [ 5489.423426] usb 10-1: Manufacturer: RT Systems
> [ 5489.423431] usb 10-1: SerialNumber: RTUC68HJ
>
> Output from lsusb -v:
>
> Bus 010 Device 002: ID 2100:9e58
> Device Descriptor:
>bLength18
>bDescriptorType 1
>bcdUSB 2.00
>bDeviceClass0 (Defined at Interface level)
>bDeviceSubClass 0
>bDeviceProtocol 0
>bMaxPacketSize0 8
>idVendor 0x2100
>idProduct 0x9e58
>bcdDevice6.00
>iManufacturer 1 RT Systems
>iProduct2 CT63 Radio Cable
>iSerial 3 RTUC68HJ
>bNumConfigurations 1
>Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 32
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
>(Bus Powered)
> MaxPower 90mA
> Interface Descriptor:
>bLength 9
>bDescriptorType 4
>bInterfaceNumber0
>bAlternateSetting 0
>bNumEndpoints 2
>bInterfaceClass 255 Vendor Specific Class
>bInterfaceSubClass255 Vendor Specific Subclass
>bInterfaceProtocol255 Vendor Specific Protocol
>iInterface 2 CT63 Radio Cable
>Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes2
>Transfer TypeBulk
>Synch Type None
>Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 0
>Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes2
>Transfer TypeBulk
>Synch Type None
>Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 0
> Device Status: 0x
>(Bus Powered)
>
> $> cat /tmp/ftdi-ct63.patch
> diff -uprN linux-3.6-vanilla/drivers/usb/serial/ftdi_sio.c
> /home/ryan/src/linux-3.6-ftdi/drivers/usb/serial/ftdi_sio.c
> --- linux-3.6-vanilla/drivers/usb/serial/ftdi_sio.c 2012-09-30
> 19:47:46.0 -0400
> +++ /home/ryan/src/linux-3.6-ftdi/drivers/usb/serial/ftdi_sio.c
> 2012-10-03 21:44:56.024000806 -0400
> @@ -738,6 +738,7 @@ static struct usb_device_id id_table_com
> { USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) },
> { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_SERIAL_VX7_PID) },
> { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_CT29B_PID) },
> + { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_CT63_PID) },
> { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_RTS01_PID) },
> { USB_DEVICE(FTDI_VID, FTDI_MAXSTREAM_PID) },
> { USB_DEVICE(FTDI_VID, FTDI_PHI_FISCO_PID) },
> diff -uprN linux-3.6-vanilla/drivers/usb/serial/ftdi_sio_ids.h
> /home/ryan/src/linux-3.6-ftdi/drivers/usb/serial/ftdi_sio_ids.h
> --- linux-3.6-vanilla/drivers/usb/serial/ftdi_sio_ids.h 2012-09-30
> 19:47:46.0 -0400
> +++ /home/ryan/src/linux-3.6-ftdi/drivers/usb/serial/ftdi_sio_ids.h
> 2012-10-03 21:45:39.211999231 -0400
> @@ -790,6 +790,7 @@
> #define RTSYSTEMS_VID 0x2100 /* Vendor ID */
> #define RTSYSTEMS_SERIAL_VX7_PID 0x9e52 /* Serial converter for
> VX-7 Radios using FT232RL */
> #define RTSYSTEMS_CT29B_PID0x9e54 /* CT29B Radio Cable */
> +#define RTSYSTEMS_CT63_PID 0x9e58 /* CT63 Radio Cable */
> #define RTSYSTEMS_RTS01_PID0x9e57 /* USB-RTS01 Radio Cable */
>
> Signed-off-by: Ryan A. Krenzischek
>
> 73 de Ryan/W4NTR
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] Idea: dynamic loading of USB quirks
[cc lkml as this might be of broader interest] On 01.11.2012 00:32, maill...@superlative.org wrote: > Dear Alsa community, > I've some minor contributions in the form of patches for USB quirks for > devices in the past. It occurred to me that having these USB quirks hardcoded > into the driver maybe isn't the best thing. > > Looking at the current quirks file, the majority of them are relatively > trivial > and are really just there to give the USB driver a nudge in the right > direction. > > Having to have these hardcoded into the driver creates a number of issues: > > 1. It needs someone with the expertise and will, and access the specific > device > for testing, to build the quirk. To hardened ALSA hackers this seems trivial, > but to an average end user who has a device they want to get supported, this > can be pretty inpenatrable. The complexity of just getting the alsa source > installed and set up for compilation is enough to put off the vast majority > of > users. > > 2. It makes the process of getting the driver "to market" lengthy as these > changes have to go through all of the normal release schedules, and these are > pretty opaque. > > 3. It makes getting changing a driver (because of a bug, or a new release of > hardware) difficult as the revisions need to go through the whole process of > creating a patch, getting it accepted, and then the long kernel release > process, as well as the various distribution release processes. > > It occured to me that there might be a better way where quirks like this > could > be dynamically loaded into the driver after it has loaded. This would a > structured text file describing the quirk to be created and pushed into the > driver. Ultimately this could be wrapped into a framework where quirk files > could be put into a common directory (similar to modprobe.d) with a startup > script which pushed these into the driver. The idea is interesting, but we would need to find a way to not only cover the entries in quirks-list.h but the other hard-coded details as well. I fear that if quirk fixups are done on both the kernel level and loaded from userspace, it actually makes debugging and maintainance harder. Then again, if a versatile and clean solution to this problem is found, there would be tons of other drivers in Linux to benefit from it, just think about the hda driver to begin with. But not only in the ALSA area. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 03.11.2012 15:10, Christof Meerwald wrote: > On Sat, 20 Oct 2012 23:15:17 + (GMT), Artem S. Tashkinov wrote: >> It's almost definitely either a USB driver bug or video4linux driver bug: >> >> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described >> here: >> https://lkml.org/lkml/2012/10/20/35 >> https://lkml.org/lkml/2012/10/20/148 > > Not sure if it's related, but I am seeing a kernel freeze with a > usb-audio headset (connected via an external USB hub) on Linux 3.5.0 > (Ubuntu 12.10) - see Does Ubuntu 12.10 really ship with 3.5.0? Not any more recent > http://comments.gmane.org/gmane.comp.voip.twinkle/3052 and > http://pastebin.com/aHGe1S1X for a self-contained C test. Some questions: - Are you seeing the same issue with 3.6.x? - If you can reproduce this issue, could you paste the messages in dmesg when this happens? Do they resemble to the list corruption that was reported? - Do you see the same problem with 3.4? - Are you able to apply the patch Alan Stern posted in this thread earlier? We should really sort this out, but I unfortunately lack a system or setup that shows the bug. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops while disconnecting USB peripheral (always)
On 23.07.2012 17:04, Sarbojit Ganguly wrote: > On 23 July 2012 20:17, Alan Stern wrote: >> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote: >> >>> Hello Daniel, >>> >>> That is why I provided two stacks, >>> >>> 1st one is when I tried to remove the USB hub (which connects a webcam >>> + microphone) >>> 2nd one is when I tried to remove an USB powered external HDD. >>> >>> Just to make sure whether the problem is with USB sound or the USB >>> subsystem. >> >> Do you stop all the programs that are using the USB devices before >> unplugging the hub? Do you unmount the USB HDD first? > > Yes Alan, I did unmount the HDD > >> >> The first crash shows a problem in the snd-usb-audio driver. >> >> The second crash shows a problem in the VFS layer or in ext3, not in >> the USB stack. > > Yes the issue is in evict() api which gets called when USB disconnect > is triggered. >> >> Alan Stern >> > > Even I was confused in the beginning but after thorough check I > confirmed its presence. I reverted back to my distro's stock kernel > (3.2.0-26-generic) where the issue does not recur. > > I could not analysed further (due to my limited knowledge of USB). > Did you succeed in bisecting this problem down? From what I can tell, there hasn't been any similar report on LKML yet. That makes traking the problem on your machine even more important as you can reproduce it reliably. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops while disconnecting USB peripheral (always)
On 28.07.2012 14:27, Bjørn Mork wrote:
> Daniel Mack writes:
>> On 23.07.2012 16:47, Alan Stern wrote:
>>> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
>>>> That is why I provided two stacks,
>>>>
>>>> 1st one is when I tried to remove the USB hub (which connects a webcam
>>>> + microphone)
>>>> 2nd one is when I tried to remove an USB powered external HDD.
>>>>
>>>> Just to make sure whether the problem is with USB sound or the USB
>>>> subsystem.
>>>
>>> Do you stop all the programs that are using the USB devices before
>>> unplugging the hub? Do you unmount the USB HDD first?
>>>
>>> The first crash shows a problem in the snd-usb-audio driver.
>>>
>>> The second crash shows a problem in the VFS layer or in ext3, not in
>>> the USB stack.
>>
>> I dare to doubt there are two severe bugs of that kind that are 100%
>> reproducible. I haven't had a hotplug crash in any of the two drivers
>> for a long time, and I use both of them extensively.
>
> Actually, based on the recent usb_wwan experience, I'd say that two such
> bugs isn't as unlikely as it may seem at first. Even three if we add
> the now fixed usb_wwan (or six, if we count the three drivers affected
> by the usb_wwan bug). There are probably even more.
>
> The reason is this change:
>
> 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound
>
>
> It will make bugs like this suddenly 100% reproducible. But the bugs
> *are* in the drivers, and may have been there for a long time. The
> drivers have been accessing drvdata after unbinding. They just didn't
> crash prior to that commit.
>
> But the commit is correct, and a very much needed improvement if my
> assumptions are correct. The drivers need fixing and this just makes it
> evident.
Hmm, interesting. Thanks for sharing this. I personally never saw this
bug kicking in, but if I understand your findings correctly, we would
need something like the following patch for snd-usb and the storage driver?
Sarbojit, could you give this a test and see whether your kernel still
crashes in any of the two drivers?
Thanks,
Daniel
diff --git a/sound/usb/card.c b/sound/usb/card.c
index d5b5c33..0e8caaa 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -555,7 +555,7 @@ static void snd_usb_audio_disconnect(struct
usb_device *dev,
struct snd_card *card;
struct list_head *p;
- if (chip == (void *)-1L)
+ if (chip == (void *)-1L || chip == NULL)
return;
card = chip->card;
@@ -610,6 +610,7 @@ static void usb_audio_disconnect(struct
usb_interface *intf)
{
snd_usb_audio_disconnect(interface_to_usbdev(intf),
usb_get_intfdata(intf));
+ usb_set_intfdata(intf, NULL);
}
#ifdef CONFIG_PM
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index d012fe4..36862ee 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -1025,9 +1025,14 @@ void usb_stor_disconnect(struct usb_interface *intf)
{
struct us_data *us = usb_get_intfdata(intf);
+ if (!us)
+ return;
+
US_DEBUGP("storage_disconnect() called\n");
quiesce_and_remove_host(us);
release_everything(us);
+
+ usb_set_intfdata(intf, NULL);
}
EXPORT_SYMBOL_GPL(usb_stor_disconnect);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops while disconnecting USB peripheral (always)
On 28.07.2012 15:25, Bjørn Mork wrote: > Daniel Mack writes: >> On 28.07.2012 14:27, Bjørn Mork wrote: >> >>> The reason is this change: >>> >>> 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound >>> >>> >>> It will make bugs like this suddenly 100% reproducible. But the bugs >>> *are* in the drivers, and may have been there for a long time. The >>> drivers have been accessing drvdata after unbinding. They just didn't >>> crash prior to that commit. > > I just realized that I might have been concluding too quickly here, as > usual.. > > The crashes referred to in this thread were not NULL pointer > dereferences, which makes it less likely that this change is the > cause. Could of course still be related somehow, but not directly. > > >>> But the commit is correct, and a very much needed improvement if my >>> assumptions are correct. The drivers need fixing and this just makes it >>> evident. >> >> Hmm, interesting. Thanks for sharing this. I personally never saw this >> bug kicking in, but if I understand your findings correctly, we would >> need something like the following patch for snd-usb and the storage driver? >> >> Sarbojit, could you give this a test and see whether your kernel still >> crashes in any of the two drivers? >> >> >> Thanks, >> Daniel >> >> >> >> diff --git a/sound/usb/card.c b/sound/usb/card.c >> index d5b5c33..0e8caaa 100644 >> --- a/sound/usb/card.c >> +++ b/sound/usb/card.c >> @@ -555,7 +555,7 @@ static void snd_usb_audio_disconnect(struct >> usb_device *dev, >> struct snd_card *card; >> struct list_head *p; >> >> - if (chip == (void *)-1L) >> + if (chip == (void *)-1L || chip == NULL) >> return; > > I may be wrong, but I don't think you need this is disconnect. The > driver will not be unbound until after disconnect returns. I thought so too, yes. Still, as I don't fully understand the call trace that is involved across all the driver layers, I thought it might we worth a try if that fixes it. > But IMHO, the usage of (void *)-1L as invalid drvdata marker in that > driver should be replaced with NULL. suspend/resume may also be unsafe > for example. Could be, but Sarbojit reported crashes on disconnect, not on suspend. > I don't really think you need those changes for the same reasons I gave > above. > > Sorry if my comment just confused the search for this bug. bisecting it > is probably the easiest way to locate it after all. Yes, definitely. Thanks, anyway, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: genirq: Flags mismatch irq 5. 00000000 (ES1688) vs. 00000000
On 28.07.2012 15:20, Fengguang Wu wrote:
> (ES1688)
> Reply-To:
>
> Hi all,
>
> snd_es1688_create() seems not doing things right. It never frees the
> previously allocated resources on error return.. Anyone cares about
> this driver now?
Could you try the (not even compile-tested) patch attached?
Daniel
diff --git a/sound/isa/es1688/es1688_lib.c b/sound/isa/es1688/es1688_lib.c
index 1d47be8..7cb309a 100644
--- a/sound/isa/es1688/es1688_lib.c
+++ b/sound/isa/es1688/es1688_lib.c
@@ -658,18 +658,25 @@ int snd_es1688_create(struct snd_card *card,
chip->irq = -1;
chip->dma8 = -1;
- if ((chip->res_port = request_region(port + 4, 12, "ES1688")) == NULL) {
+ chip->res_port = request_region(port + 4, 12, "ES1688");
+ if (chip->res_port == NULL) {
snd_printk(KERN_ERR "es1688: can't grab port 0x%lx\n", port + 4);
- return -EBUSY;
+ err = -EBUSY;
+ goto exit;
}
- if (request_irq(irq, snd_es1688_interrupt, 0, "ES1688", (void *) chip)) {
+
+ err = request_irq(irq, snd_es1688_interrupt, 0, "ES1688", (void *) chip);
+ if (err < 0) {
snd_printk(KERN_ERR "es1688: can't grab IRQ %d\n", irq);
- return -EBUSY;
+ goto exit_release_region;
}
+
chip->irq = irq;
- if (request_dma(dma8, "ES1688")) {
+ err = request_dma(dma8, "ES1688");
+
+ if (err < 0) {
snd_printk(KERN_ERR "es1688: can't grab DMA8 %d\n", dma8);
- return -EBUSY;
+ goto exit_release_irq;
}
chip->dma8 = dma8;
@@ -685,14 +692,23 @@ int snd_es1688_create(struct snd_card *card,
err = snd_es1688_probe(chip);
if (err < 0)
- return err;
+ goto exit_release_dma;
err = snd_es1688_init(chip, 1);
if (err < 0)
- return err;
+ goto exit_release_dma;
/* Register device */
return snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops);
+
+exit_release_dma:
+ free_dma(chip->dma8);
+exit_release_irq:
+ free_irq(chip->irq, chip);
+exit_release_region:
+ release_and_free_resource(chip->res_port);
+exit:
+ return err;
}
static struct snd_pcm_ops snd_es1688_playback_ops = {
Re: [PATCH] es1688 - freeup resources on init failure
On 29.07.2012 13:39, Fengguang Wu wrote: >>> err = snd_es1688_init(chip, 1); >>> if (err < 0) >>> - return err; >>> + goto exit_release_dma; >>> >>> /* Register device */ >>> return snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops); >>> + >>> +exit_release_dma: >>> + free_dma(chip->dma8); >>> +exit_release_irq: >>> + free_irq(chip->irq, chip); >>> +exit_release_region: >>> + release_and_free_resource(chip->res_port); >>> +exit: >>> + return err; >> >> You can simply call snd_es1688_free(chip) instead of a bunch of >> labels. That is, all goto's can be "goto exit", and >> >> exit: >> snd_es1688_free(chip); >> return err; > > snd_es1688_free() will call snd_es1688_init() which in turn use the > uninitialized spin locks and other data. So I end up with the below > patch. snd_device_new() could also return errors and will be handled > in the same way. > > I don't have the hardware, however tests show it at least fixed the > boot time irq mismatch warnings. > > Daniel, thanks for your initial implementation and please kindly > confirm the below 3rd version :) Looks good to me, but I don't have the hardware either :) Daniel > --- > es1688 - freeup resources on init failure > > This will fix the following oops: > > [6.169981] genirq: Flags mismatch irq 5. (ES1688) vs. > (ES1688) > [6.170851] Pid: 1, comm: swapper Not tainted 3.5.0-4-gceee0e9 #14 > [6.170851] Call Trace: > [6.170851] [] ? __setup_irq+0x3c7/0x420 > [6.170851] [] ? request_threaded_irq+0x76/0x140 > [6.170851] [] ? snd_es1688_ioctl+0x10/0x10 > [6.170851] [] ? request_threaded_irq+0xb2/0x140 > [6.170851] [] ? snd_es1688_create+0x96/0x330 > [6.170851] [] ? snd_gusextreme_probe+0x18d/0x5a2 > [6.170851] [] ? __driver_attach+0x80/0x80 > [6.170851] [] ? sysfs_create_link+0xf/0x20 > [6.170851] [] ? __driver_attach+0x80/0x80 > [6.170851] [] ? isa_bus_probe+0x12/0x20 > [6.170851] [] ? driver_probe_device+0x55/0x1c0 > [6.170851] [] ? _raw_spin_unlock+0xf/0x30 > [6.170851] [] ? klist_next+0x6a/0xe0 > [6.170851] [] ? isa_bus_match+0x21/0x40 > [6.170851] [] ? bus_for_each_drv+0x34/0x70 > [6.170851] [] ? device_attach+0x7b/0x90 > [6.170851] [] ? __driver_attach+0x80/0x80 > [6.170851] [] ? bus_probe_device+0x5f/0x80 > [6.170851] [] ? device_add+0x573/0x620 > [6.170851] [] ? complete_all+0x40/0x60 > [6.170851] [] ? _raw_spin_unlock_irqrestore+0x1a/0x30 > [6.170851] [] ? isa_register_driver+0xb6/0x150 > [6.170851] [] ? alsa_card_gusmax_init+0xf/0xf > [6.170851] [] ? do_one_initcall+0x7f/0x12b > [6.170851] [] ? kernel_init+0x112/0x1a9 > [6.170851] [] ? do_early_param+0x77/0x77 > [6.170851] [] ? do_one_initcall+0x12b/0x12b > [6.170851] [] ? kernel_thread_helper+0x6/0xd > [6.190170] es1688: can't grab IRQ 5 > [6.190613] genirq: Flags mismatch irq 5. (ES1688) vs. > (ES1688) > [6.191566] Pid: 1, comm: swapper Not tainted 3.5.0-4-gceee0e9 #14 > [6.192394] Call Trace: > [6.192685] [] ? __setup_irq+0x3c7/0x420 > [6.193342] [] ? request_threaded_irq+0x76/0x140 > [6.194081] [] ? snd_es1688_ioctl+0x10/0x10 > [6.194607] [] ? request_threaded_irq+0xb2/0x140 > [6.194607] [] ? snd_es1688_create+0x96/0x330 > [6.194607] [] ? snd_gusextreme_probe+0x18d/0x5a2 > [6.194607] [] ? __driver_attach+0x80/0x80 > [6.194607] [] ? sysfs_create_link+0xf/0x20 > [6.194607] [] ? __driver_attach+0x80/0x80 > [6.194607] [] ? isa_bus_probe+0x12/0x20 > [6.194607] [] ? driver_probe_device+0x55/0x1c0 > [6.194607] [] ? _raw_spin_unlock+0xf/0x30 > [6.194607] [] ? klist_next+0x6a/0xe0 > [6.194607] [] ? isa_bus_match+0x21/0x40 > [6.194607] [] ? bus_for_each_drv+0x34/0x70 > [6.194607] [] ? device_attach+0x7b/0x90 > [6.194607] [] ? __driver_attach+0x80/0x80 > [6.194607] [] ? bus_probe_device+0x5f/0x80 > [6.194607] [] ? device_add+0x573/0x620 > [6.194607] [] ? complete_all+0x40/0x60 > [6.194607] [] ? _raw_spin_unlock_irqrestore+0x1a/0x30 > [6.194607] [] ? isa_register_driver+0xb6/0x150 > [6.194607] [] ? alsa_card_gusmax_init+0xf/0xf > [6.194607] [] ? do_one_initcall+0x7f/0x12b > [6.194607] [] ? kernel_init+0x112/0x1a9 > [6.194607] [] ? do_early_param+0x77/0x77 > [6.194607] [] ? do_one_initcall+0x12b/0x12b > [6.194607] [
[PATCH v3 1/2] lis3: add generic DT matching code
This patch adds logic to parse lis3 properties from a device tree node
and store them in a freshly allocated lis3lv02d_platform_data.
Note that the actual match tables are left out here. This part should
happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
Also adds some DT bindinds documentation.
Signed-off-by: Daniel Mack
---
Changes from v2:
- kzalloc braino
Changes from v1:
- some typos in properties fixed
Documentation/devicetree/bindings/misc/lis302.txt | 74
drivers/misc/lis3lv02d/lis3lv02d.c| 137 ++
drivers/misc/lis3lv02d/lis3lv02d.h| 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
b/Documentation/devicetree/bindings/misc/lis302.txt
new file mode 100644
index 000..66230fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/lis302.txt
@@ -0,0 +1,74 @@
+LIS302 accelerometer devicetree bindings
+
+This device is matched via its bus drivers, and has a number of properties
+that apply in on the generic device (independent from the bus).
+
+
+Required properties for the SPI bindings:
+ - compatible: should be set to "st,lis3lv02d_spi"
+ - reg:the chipselect index
+ - spi-max-frequency: maximal bus speed, should be set to 100 unless
+ constrained by external circuitry
+ - interrupts: the interrupt generated by the device
+
+
+Optional properties for all bus drivers:
+
+ - st,click-single-{x,y,z}:if present, tells the device to issue an
+ interrupt on single click events on the
+ x/y/z axis.
+ - st,click-double-{x,y,z}:if present, tells the device to issue an
+ interrupt on double click events on the
+ x/y/z axis.
+ - st,click-thresh-{x,y,z}:set the x/y/z axis threshold
+ - st,click-click-time-limit: click time limit, from 0 to 127.5msec
+ with step of 0.5 msec
+ - st,click-latency: click latency, from 0 to 255 msec with
+ step of 1 msec.
+ - st,click-window:click window, from 0 to 255 msec with
+ step of 1 msec.
+ - st,irq{1,2}-disable:disable IRQ 1/2
+ - st,irq{1,2}-ff-wu-1:raise IRQ 1/2 on FF_WU_1 condition
+ - st,irq{1,2}-ff-wu-2:raise IRQ 1/2 on FF_WU_2 condition
+ - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
+ - st,irq{1,2}-click: raise IRQ 1/2 on click condition
+ - st,irq-open-drain: consider IRQ lines open-drain
+ - st,irq-active-low: make IRQ lines active low
+ - st,wu-duration-1: duration register for Free-Fall/Wake-Up
+ interrupt 1
+ - st,wu-duration-2: duration register for Free-Fall/Wake-Up
+ interrupt 2
+ - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
+ upper/lower limit
+ - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
+ highpass cut-off frequency
+ - st,hipass{1,2}-disable: disable highpass 1/2.
+ - st,default-rate=: set the default rate
+ - st,axis-{x,y,z}=: set the axis to map to the three coordinates
+
+
+Example for a SPI device node:
+
+ lis302@0 {
+ compatible = "st,lis302dl-spi";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ interrupt-parent = <&gpio>;
+ interrupts = <104 0>;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = <10>;
+ st,click-thresh-y = <10>;
+ st,click-thresh-z = <10>;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ };
+
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index a981e2a..1411fdc 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "lis3lv02d.h"
#define DRIVER_NAME "lis3lv02d"
@@ -912,6 +913,138 @@ static void lis3lv02d_8b_configure(struct lis3lv02d *lis3,
}
}
+#ifdef CONFIG_OF
+static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+{
+ struct lis3lv02d_platform_data *pdata;
+ struct device_node *np = lis3->of_node;
+ u32 tmp;
+
+
[PATCH v3 2/2] lis3-spi: add DT matching table passthru code
If probed from a device tree, this driver now passes the node
information to the generic part, so the runtime information can be
derived.
Successfully tested on a PXA3xx board.
Signed-off-by: Daniel Mack
---
No changes from v1 and v2
drivers/misc/lis3lv02d/lis3lv02d_spi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
index 80880e9..8616054 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "lis3lv02d.h"
@@ -58,6 +59,12 @@ static int lis3_spi_init(struct lis3lv02d *lis3)
static union axis_conversion lis3lv02d_axis_normal =
{ .as_array = { 1, 2, 3 } };
+static struct of_device_id lis302dl_spi_dt_ids[] = {
+ { .compatible = "st,lis302dl-spi" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, lis302dl_spi_dt_ids);
+
static int __devinit lis302dl_spi_probe(struct spi_device *spi)
{
int ret;
@@ -75,6 +82,12 @@ static int __devinit lis302dl_spi_probe(struct spi_device
*spi)
lis3_dev.irq= spi->irq;
lis3_dev.ac = lis3lv02d_axis_normal;
lis3_dev.pdata = spi->dev.platform_data;
+
+#ifdef CONFIG_OF
+ if (of_match_device(lis302dl_spi_dt_ids, &spi->dev))
+ lis3_dev.of_node = spi->dev.of_node;
+#endif
+
spi_set_drvdata(spi, &lis3_dev);
return lis3lv02d_init_device(&lis3_dev);
@@ -121,6 +134,7 @@ static struct spi_driver lis302dl_spi_driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
.pm = &lis3lv02d_spi_pm,
+ .of_match_table = of_match_ptr(lis302dl_spi_dt_ids),
},
.probe = lis302dl_spi_probe,
.remove = __devexit_p(lis302dl_spi_remove),
--
1.7.11.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] onewire: w1-gpio: add ext_pullup_enable pin in platform data
Ping.
On 25.07.2012 22:54, Daniel Mack wrote:
> In the process of porting boards to devicetree implemenation, we should
> keep information about external circuitry where they belong - the
> individual drivers.
>
> This patch adds a way to specify a GPIO to drive the (optional) external
> pull-up logic, rather than using a function pointer for that.
>
> Signed-off-by: Daniel Mack
> Cc: Evgeniy Polyakov
> Cc: Ville Syrjala
> ---
> drivers/w1/masters/w1-gpio.c | 18 +-
> include/linux/w1-gpio.h |1 +
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
> index df600d1..dac88ff 100644
> --- a/drivers/w1/masters/w1-gpio.c
> +++ b/drivers/w1/masters/w1-gpio.c
> @@ -59,6 +59,13 @@ static int __init w1_gpio_probe(struct platform_device
> *pdev)
> if (err)
> goto free_master;
>
> + if (gpio_is_valid(pdata->ext_pullup_enable_pin)) {
> + err = gpio_request_one(pdata->ext_pullup_enable_pin,
> +GPIOF_INIT_LOW, "w1 pullup");
> + if (err < 0)
> + goto free_gpio;
> + }
> +
> master->data = pdata;
> master->read_bit = w1_gpio_read_bit;
>
> @@ -72,15 +79,21 @@ static int __init w1_gpio_probe(struct platform_device
> *pdev)
>
> err = w1_add_master_device(master);
> if (err)
> - goto free_gpio;
> + goto free_gpio_ext_pu;
>
> if (pdata->enable_external_pullup)
> pdata->enable_external_pullup(1);
>
> + if (gpio_is_valid(pdata->ext_pullup_enable_pin))
> + gpio_set_value(pdata->ext_pullup_enable_pin, 1);
> +
> platform_set_drvdata(pdev, master);
>
> return 0;
>
> + free_gpio_ext_pu:
> + if (gpio_is_valid(pdata->ext_pullup_enable_pin))
> + gpio_free(pdata->ext_pullup_enable_pin);
> free_gpio:
> gpio_free(pdata->pin);
> free_master:
> @@ -97,6 +110,9 @@ static int __exit w1_gpio_remove(struct platform_device
> *pdev)
> if (pdata->enable_external_pullup)
> pdata->enable_external_pullup(0);
>
> + if (gpio_is_valid(pdata->ext_pullup_enable_pin))
> + gpio_set_value(pdata->ext_pullup_enable_pin, 0);
> +
> w1_remove_master_device(master);
> gpio_free(pdata->pin);
> kfree(master);
> diff --git a/include/linux/w1-gpio.h b/include/linux/w1-gpio.h
> index 3adeff8..065e3ae 100644
> --- a/include/linux/w1-gpio.h
> +++ b/include/linux/w1-gpio.h
> @@ -19,6 +19,7 @@ struct w1_gpio_platform_data {
> unsigned int pin;
> unsigned int is_open_drain:1;
> void (*enable_external_pullup)(int enable);
> + unsigned int ext_pullup_enable_pin;
> };
>
> #endif /* _LINUX_W1_GPIO_H */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] onewire: w1-gpio: add ext_pullup_enable pin in platform data
On 30.07.2012 19:32, Evgeniy Polyakov wrote: > Hi > > Sorry for long delay > > On Wed, Jul 25, 2012 at 10:54:29PM +0200, Daniel Mack (zon...@gmail.com) > wrote: >> In the process of porting boards to devicetree implemenation, we should >> keep information about external circuitry where they belong - the >> individual drivers. >> >> This patch adds a way to specify a GPIO to drive the (optional) external >> pull-up logic, rather than using a function pointer for that. > > I do not object against this patch, but I have rather limited knowledge > about gpio driver. The first patch just offers a new way to drive an optional external pull-up and as nobody uses that feature currently, there can't be any breakage. And the second patch doesn't change any functional behaviour of the driver, it simply offers a new way to instanciate it. > Patch looks good, feel free to add my > Acked-by: Evgeniy Polyakov Thanks! > > Greg, please pull it into your tree, if Ville does not object. > Thank you. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] onewire: w1-gpio: add ext_pullup_enable pin in platform data
On 31.07.2012 02:59, Ville Syrjälä wrote:
> On Mon, Jul 30, 2012 at 10:12:39PM +0400, Evgeniy Polyakov wrote:
>> Hi
>>
>> Sorry for long delay
>> [resend with fixed Greg's address :)]
>>
>> On Wed, Jul 25, 2012 at 10:54:29PM +0200, Daniel Mack (zon...@gmail.com)
>> wrote:
>>> In the process of porting boards to devicetree implemenation, we should
>>> keep information about external circuitry where they belong - the
>>> individual drivers.
>>>
>>> This patch adds a way to specify a GPIO to drive the (optional) external
>>> pull-up logic, rather than using a function pointer for that.
>>
>> I do not object against this patch, but I have rather limited knowledge
>> about gpio driver. Patch looks good, feel free to add my
>> Acked-by: Evgeniy Polyakov
>>
>> Greg, please pull it into your tree, if Ville does not object.
>
> No objections from me.
I take this as an Acked-by:?
> The only cosmetic issue I spotted was 'pdata' being assigned twice in
> w1_gpio_probe().
Right. Amended patch below.
Thanks a lot,
Daniel
>From 37385d15bbd9dbc637f1e46d962c90be5eeb1409 Mon Sep 17 00:00:00 2001
From: Daniel Mack
Date: Mon, 23 Jul 2012 16:36:35 +0200
Subject: [PATCH v2] onewire: w1-gpio: add DT bindings
This patch add DT bindings to the w1-gpio driver, along with some
documentation on how to use them.
Signed-off-by: Daniel Mack
Acked-by: Evgeniy Polyakov
Acked-by: Ville Syrjala
---
Documentation/devicetree/bindings/w1/w1-gpio.txt | 22 +++
drivers/w1/masters/w1-gpio.c | 48 +++-
2 files changed, 69 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.txt
diff --git a/Documentation/devicetree/bindings/w1/w1-gpio.txt b/Documentation/devicetree/bindings/w1/w1-gpio.txt
new file mode 100644
index 000..6e09c35
--- /dev/null
+++ b/Documentation/devicetree/bindings/w1/w1-gpio.txt
@@ -0,0 +1,22 @@
+w1-gpio devicetree bindings
+
+Required properties:
+
+ - compatible: "w1-gpio"
+ - gpios: one or two GPIO specs:
+ - the first one is used as data I/O pin
+ - the second one is optional. If specified, it is used as
+ enable pin for an external pin pullup.
+
+Optional properties:
+
+ - linux,open-drain: if specified, the data pin is considered in
+ open-drain mode.
+
+Examples:
+
+ onewire@0 {
+ compatible = "w1-gpio";
+ gpios = <&gpio 126 0>, <&gpio 105 0>;
+ };
+
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index dac88ff..6012c4e 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include "../w1.h"
#include "../w1_int.h"
@@ -42,12 +44,55 @@ static u8 w1_gpio_read_bit(void *data)
return gpio_get_value(pdata->pin) ? 1 : 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id w1_gpio_dt_ids[] = {
+ { .compatible = "w1-gpio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, w1_gpio_dt_ids);
+
+static int w1_gpio_probe_dt(struct platform_device *pdev)
+{
+ struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *of_id =
+ of_match_device(w1_gpio_dt_ids, &pdev->dev);
+
+ if (!of_id)
+ return 0;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ if (of_get_property(np, "linux,open-drain", NULL))
+ pdata->is_open_drain = 1;
+
+ pdata->pin = of_get_gpio(np, 0);
+ pdata->ext_pullup_enable_pin = of_get_gpio(np, 1);
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+#else
+static int w1_gpio_probe_dt(struct platform_device *pdev)
+{
+ return 0;
+}
+#endif
+
static int __init w1_gpio_probe(struct platform_device *pdev)
{
struct w1_bus_master *master;
- struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct w1_gpio_platform_data *pdata;
int err;
+ err = w1_gpio_probe_dt(pdev);
+ if (err < 0)
+ return err;
+
+ pdata = pdev->dev.platform_data;
+
if (!pdata)
return -ENXIO;
@@ -151,6 +196,7 @@ static struct platform_driver w1_gpio_driver = {
.driver = {
.name = "w1-gpio",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(w1_gpio_dt_ids),
},
.remove = __exit_p(w1_gpio_remove),
.suspend = w1_gpio_suspend,
--
1.7.11.2
Re: linux-next: Tree for Sept 21 (misc/lis3lv02d DT code)
On 21.09.2012 19:48, Randy Dunlap wrote: > On 09/21/2012 12:01 AM, Stephen Rothwell wrote: > >> Hi all, >> >> Changes since 201209020: >> > > > > on i386: > > ERROR: "lis3lv02d_init_dt" [drivers/misc/lis3lv02d/lis3lv02d_i2c.ko] > undefined! > > Full randconfig file is attached. > Hmm, I cannot reproduce that on my machine with your config, but the attached patch should fix it. Andrew, you already have a patch queued up for this driver - could you fold that one maybe after Randy signals success? Thanks, Daniel >From 7b3210ec41a40f2b667f57eb4478eb5a149199c8 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Fri, 21 Sep 2012 23:14:29 +0200 Subject: [PATCH] misc: lis3: fix undefined reference to lis3lv02d_init_dt Export the symbol to fix linker errors. Signed-off-by: Daniel Mack Reported-by: Randy Dunlap --- drivers/misc/lis3lv02d/lis3lv02d.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c b/drivers/misc/lis3lv02d/lis3lv02d.c index 026021e..f9c24ab 100644 --- a/drivers/misc/lis3lv02d/lis3lv02d.c +++ b/drivers/misc/lis3lv02d/lis3lv02d.c @@ -1089,6 +1089,7 @@ int lis3lv02d_init_dt(struct lis3lv02d *lis3) return 0; } #endif +EXPORT_SYMBOL_GPL(lis3lv02d_init_dt); /* * Initialise the accelerometer and the various subsystems. -- 1.7.11.4
[PATCH] drivers: misc: add gpio wakeup driver
This patch adds a very simple driver that enables GPIO lines as wakeup
sources. It only operates on information passed in via DT, and depends
on CONFIG_OF && CONFIG_PM_SLEEP. It can for example be used to connect
wake-on-LAN (WOL) signals or other electric wakeup networks.
The driver accepts a list of GPIO nodes and claims them along with their
interrupt line. During suspend, the interrupts will be enabled and
selected as wakeup source. The driver doesn't do anything else with the
GPIO lines, and will ignore occured interrupts silently.
Signed-off-by: Daniel Mack
---
.../devicetree/bindings/misc/gpio-wakeup.txt | 16 ++
drivers/misc/Kconfig | 8 +
drivers/misc/Makefile | 1 +
drivers/misc/gpio-wakeup.c | 162 +
4 files changed, 187 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/gpio-wakeup.txt
create mode 100644 drivers/misc/gpio-wakeup.c
diff --git a/Documentation/devicetree/bindings/misc/gpio-wakeup.txt
b/Documentation/devicetree/bindings/misc/gpio-wakeup.txt
new file mode 100644
index 000..6aacd0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/gpio-wakeup.txt
@@ -0,0 +1,16 @@
+GPIO WAKEUP DRIVER BINDINGS
+
+Required:
+
+ compatible: Must be "gpio-wakeup"
+ gpios: At list of GPIO nodes that are enabled as wakeup
+ sources.
+
+
+Example:
+
+ wake_up {
+ compatible = "gpio-wakeup";
+ gpios = <&gpio0 19 0>;
+ };
+
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8dacd4c..c089280 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -528,6 +528,14 @@ config SRAM
the genalloc API. It is supposed to be used for small on-chip SRAM
areas found on many SoCs.
+config GPIO_WAKEUP
+ tristate "GPIO wakeup driver"
+ depends on PM_SLEEP && OF
+ help
+ Say Y to build a driver that can wake up a system from GPIO
+ lines. See Documentation/devicetree/bindings/gpio-wakeup.txt
+ for binding details.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c235d5b..ee4df84 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
obj-$(CONFIG_SRAM) += sram.o
+obj-$(CONFIG_GPIO_WAKEUP) += gpio-wakeup.o
diff --git a/drivers/misc/gpio-wakeup.c b/drivers/misc/gpio-wakeup.c
new file mode 100644
index 000..3c1ef88
--- /dev/null
+++ b/drivers/misc/gpio-wakeup.c
@@ -0,0 +1,162 @@
+/*
+ * Driver to select GPIO lines as wakeup sources from DT.
+ *
+ * Copyright 2013 Daniel Mack
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct gpio_wakeup_priv {
+ unsigned int count;
+ unsigned int irq[0];
+};
+
+static irqreturn_t gpio_wakeup_isr(int irq, void *dev_id)
+{
+ return IRQ_HANDLED;
+}
+
+static int gpio_wakeup_probe(struct platform_device *pdev)
+{
+ int ret, count, i;
+ struct gpio_wakeup_priv *priv;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+
+ if (!np)
+ return -EINVAL;
+
+ count = of_gpio_count(np);
+ if (count == 0)
+ return -EINVAL;
+
+ priv = devm_kzalloc(dev, sizeof(*priv) +
+sizeof(int) * count, GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ for (i = 0; i < count; i++) {
+ unsigned int gpio, irq;
+
+ priv->irq[i] = -EINVAL;
+
+ gpio = of_get_gpio(np, i);
+ if (gpio < 0) {
+ dev_warn(dev, "Unable to get gpio #%d\n", i);
+ continue;
+ }
+
+ irq = gpio_to_irq(gpio);
+ if (irq < 0) {
+ dev_warn(dev, "Can't map GPIO %d to an IRQ\n", gpio);
+ continue;
+ }
+
+ ret = devm_gpio_request_one(dev, gpio, GPIOF_IN, pdev->name);
+ if (ret < 0) {
+ dev_warn(dev, "Unable to request GPIO %d: %d\n",
+gpio, ret);
+ continue;
+ }
+
+ ret = devm_reque
Re: [PATCH] drivers: misc: add gpio wakeup driver
Hi Fabio,
On 01.10.2013 16:01, Fabio Estevam wrote:
> On Tue, Oct 1, 2013 at 10:55 AM, Daniel Mack wrote:
>> This patch adds a very simple driver that enables GPIO lines as wakeup
>> sources. It only operates on information passed in via DT, and depends
>
> Isn't it the same as the existing 'gpio-key,wakeup' ?
Of course, I know the gpio-input driver can provide similar
functionality. My intention was just provide a way to wake up the system
without registering an input device for signals nobody is interested in
eventually.
Don't know if that's reason enough to add a new driver though.
Thanks,
Daniel
>
>> on CONFIG_OF && CONFIG_PM_SLEEP. It can for example be used to connect
>> wake-on-LAN (WOL) signals or other electric wakeup networks.
>>
>> The driver accepts a list of GPIO nodes and claims them along with their
>> interrupt line. During suspend, the interrupts will be enabled and
>> selected as wakeup source. The driver doesn't do anything else with the
>> GPIO lines, and will ignore occured interrupts silently.
>>
>> Signed-off-by: Daniel Mack
>> ---
>> .../devicetree/bindings/misc/gpio-wakeup.txt | 16 ++
>> drivers/misc/Kconfig | 8 +
>> drivers/misc/Makefile | 1 +
>> drivers/misc/gpio-wakeup.c | 162
>> +
>> 4 files changed, 187 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/gpio-wakeup.txt
>> create mode 100644 drivers/misc/gpio-wakeup.c
>>
>> diff --git a/Documentation/devicetree/bindings/misc/gpio-wakeup.txt
>> b/Documentation/devicetree/bindings/misc/gpio-wakeup.txt
>> new file mode 100644
>> index 000..6aacd0f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/gpio-wakeup.txt
>> @@ -0,0 +1,16 @@
>> +GPIO WAKEUP DRIVER BINDINGS
>> +
>> +Required:
>> +
>> + compatible: Must be "gpio-wakeup"
>> + gpios: At list of GPIO nodes that are enabled as wakeup
>> + sources.
>> +
>> +
>> +Example:
>> +
>> + wake_up {
>> + compatible = "gpio-wakeup";
>> + gpios = <&gpio0 19 0>;
>> + };
>> +
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 8dacd4c..c089280 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -528,6 +528,14 @@ config SRAM
>> the genalloc API. It is supposed to be used for small on-chip SRAM
>> areas found on many SoCs.
>>
>> +config GPIO_WAKEUP
>> + tristate "GPIO wakeup driver"
>> + depends on PM_SLEEP && OF
>> + help
>> + Say Y to build a driver that can wake up a system from GPIO
>> + lines. See Documentation/devicetree/bindings/gpio-wakeup.txt
>> + for binding details.
>> +
>> source "drivers/misc/c2port/Kconfig"
>> source "drivers/misc/eeprom/Kconfig"
>> source "drivers/misc/cb710/Kconfig"
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index c235d5b..ee4df84 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI) += mei/
>> obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
>> obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
>> obj-$(CONFIG_SRAM) += sram.o
>> +obj-$(CONFIG_GPIO_WAKEUP) += gpio-wakeup.o
>> diff --git a/drivers/misc/gpio-wakeup.c b/drivers/misc/gpio-wakeup.c
>> new file mode 100644
>> index 000..3c1ef88
>> --- /dev/null
>> +++ b/drivers/misc/gpio-wakeup.c
>> @@ -0,0 +1,162 @@
>> +/*
>> + * Driver to select GPIO lines as wakeup sources from DT.
>> + *
>> + * Copyright 2013 Daniel Mack
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +struct gpio_wakeup_priv {
>> + unsigned int count;
>> + unsigned int irq[0];
>> +};
>> +
>> +static irqreturn_t gpio_wakeup_isr(int irq, void *dev_id)
>
Re: [PATCH] drivers: misc: add gpio wakeup driver
On 02.10.2013 12:57, Mark Brown wrote: > On Tue, Oct 01, 2013 at 04:05:07PM +0200, Daniel Mack wrote: >> On 01.10.2013 16:01, Fabio Estevam wrote: > >>> Isn't it the same as the existing 'gpio-key,wakeup' ? > >> Of course, I know the gpio-input driver can provide similar >> functionality. My intention was just provide a way to wake up the system >> without registering an input device for signals nobody is interested in >> eventually. > >> Don't know if that's reason enough to add a new driver though. > > It does seem somewhat sensible - the signal might not have a sensible > representation as an input device and the gpio-keys binding needs one. > That was my intention as well, yes. Also, a system that does not have any input devices could in theory disable CONFIG_INPUT alltogether. Not sure how realisitic that scenario really is nowadays, but using the gpio input driver for purpose of just waking up on LAN seems somewhat abusive. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] Input: rotary-encoder: Add 'stepped' irq handler
On 04.10.2013 14:53, Ezequiel Garcia wrote:
> Some rotary-encoder devices (such as those with detents) are capable
> of producing a stable event on each step. This commit adds support
> for this case, by implementing a new interruption handler.
>
> The handler needs only detect the direction of the turn and generate
> an event according to this detection.
I think you can squash patch 2/2 into this one. It doesn't make much
sense to have a one-liner patch to just update the documenation separately.
Other than that, the code looks fine to me.
Acked-by: Daniel Mack
Thanks,
Daniel
>
> Cc: Daniel Mack
> Cc: Dmitry Torokhov
> Signed-off-by: Ezequiel Garcia
> ---
> v1->v2:
> * Add DT property handling
> * Replace binary representation by hexa-decimal in the sum encoding
>
> drivers/input/misc/rotary_encoder.c | 41
> +
> include/linux/rotary_encoder.h | 1 +
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/input/misc/rotary_encoder.c
> b/drivers/input/misc/rotary_encoder.c
> index 5b1aff8..6c7a554 100644
> --- a/drivers/input/misc/rotary_encoder.c
> +++ b/drivers/input/misc/rotary_encoder.c
> @@ -117,6 +117,42 @@ static irqreturn_t rotary_encoder_irq(int irq, void
> *dev_id)
> return IRQ_HANDLED;
> }
>
> +static irqreturn_t rotary_encoder_stepped_irq(int irq, void *dev_id)
> +{
> + struct rotary_encoder *encoder = dev_id;
> + int state;
> + unsigned char sum;
> +
> + state = rotary_encoder_get_state(encoder->pdata);
> +
> + /*
> + * We encode the previous and the current state using a byte.
> + * The previous state in the MSB nibble, the current state in the LSB
> + * nibble. Then use a table to decide the direction of the turn.
> + */
> + sum = (encoder->last_stable << 4) + state;
> + switch (sum) {
> + case 0x31:
> + case 0x10:
> + case 0x02:
> + case 0x23:
> + encoder->dir = 0; /* clockwise */
> + break;
> + /*
> + * TODO: Add the other case, and the illegal values should
> + * say a WARN (it's a BUG, but we won't stop the kernel for it :)
> + */
> + default:
> + encoder->dir = 1;
> + }
> +
> + rotary_encoder_report_event(encoder);
> +
> + encoder->last_stable = state;
> +
> + return IRQ_HANDLED;
> +}
> +
> static irqreturn_t rotary_encoder_half_period_irq(int irq, void *dev_id)
> {
> struct rotary_encoder *encoder = dev_id;
> @@ -180,6 +216,8 @@ static struct rotary_encoder_platform_data
> *rotary_encoder_parse_dt(struct devic
> "rotary-encoder,rollover", NULL);
> pdata->half_period = !!of_get_property(np,
> "rotary-encoder,half-period", NULL);
> + pdata->on_each_step = !!of_get_property(np,
> + "rotary-encoder,on-each-step", NULL);
>
> return pdata;
> }
> @@ -254,6 +292,9 @@ static int rotary_encoder_probe(struct platform_device
> *pdev)
> if (pdata->half_period) {
> handler = &rotary_encoder_half_period_irq;
> encoder->last_stable = rotary_encoder_get_state(pdata);
> + } else if (pdata->on_each_step) {
> + handler = &rotary_encoder_stepped_irq;
> + encoder->last_stable = rotary_encoder_get_state(pdata);
> } else {
> handler = &rotary_encoder_irq;
> }
> diff --git a/include/linux/rotary_encoder.h b/include/linux/rotary_encoder.h
> index 3f594dc..499f6f7 100644
> --- a/include/linux/rotary_encoder.h
> +++ b/include/linux/rotary_encoder.h
> @@ -11,6 +11,7 @@ struct rotary_encoder_platform_data {
> bool relative_axis;
> bool rollover;
> bool half_period;
> + bool on_each_step;
> };
>
> #endif /* __ROTARY_ENCODER_H__ */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/15] phy: rename struct omap_control_usb to struct omap_control_phy
On 19.09.2013 15:05, Roger Quadros wrote: > From: Kishon Vijay Abraham I > > Rename struct omap_control_usb to struct omap_control_phy since it can > be used to control PHY of USB, SATA and PCIE. Also move the driver and > include files under *phy* and made the corresponding changes in the users > of phy-omap-control. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Roger Quadros > --- > drivers/phy/Kconfig | 14 ++- > drivers/phy/Makefile |1 + > drivers/phy/phy-omap-control.c | 300 > ++ > drivers/phy/phy-omap-pipe3.c |8 +- > drivers/phy/phy-omap-usb2.c |9 +- > drivers/usb/musb/omap2430.c |2 +- > drivers/usb/phy/Kconfig | 10 - > drivers/usb/phy/Makefile |1 - > drivers/usb/phy/phy-omap-control.c | 300 > -- > include/linux/phy/omap_control_phy.h | 83 ++ > include/linux/usb/omap_control_usb.h | 83 -- > 11 files changed, 406 insertions(+), 405 deletions(-) > create mode 100644 drivers/phy/phy-omap-control.c > delete mode 100644 drivers/usb/phy/phy-omap-control.c > create mode 100644 include/linux/phy/omap_control_phy.h > delete mode 100644 include/linux/usb/omap_control_usb.h In case you do another version of this set, please use "git format-patch -M", which will detect renames and hence make the review much easier. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] drivers: misc: ti_dac7512: drop DAC7512_DRV_NAME
The driver's name can be provided directly, so drop the #define.
Signed-off-by: Daniel Mack
---
drivers/misc/ti_dac7512.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
index db47333..46dfbf3 100644
--- a/drivers/misc/ti_dac7512.c
+++ b/drivers/misc/ti_dac7512.c
@@ -23,8 +23,6 @@
#include
#include
-#define DAC7512_DRV_NAME "dac7512"
-
static ssize_t dac7512_store_val(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -76,7 +74,7 @@ static int dac7512_remove(struct spi_device *spi)
static struct spi_driver dac7512_driver = {
.driver = {
- .name = DAC7512_DRV_NAME,
+ .name = "dac7512",
.owner = THIS_MODULE,
},
.probe = dac7512_probe,
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] dac7512: some cleanups and DT bindings
Here are some trivial things for the ti_dac7512 driver. Mark, can you take them through your spi tree? Thanks, Daniel Daniel Mack (4): drivers: misc: ti_dac7512: drop module version drivers: misc: ti_dac7512: drop DAC7512_DRV_NAME drivers: misc: ti_dac7512: provide a SPI ID table drivers: misc: ti_dac7512: add support for DT matching .../devicetree/bindings/misc/ti,dac7512.txt| 20 +++ drivers/misc/ti_dac7512.c | 23 +- 2 files changed, 38 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/ti,dac7512.txt -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] drivers: misc: ti_dac7512: provide a SPI ID table
This way, the module can be autoloaded by the SPI core.
Signed-off-by: Daniel Mack
---
drivers/misc/ti_dac7512.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
index 46dfbf3..6393a68 100644
--- a/drivers/misc/ti_dac7512.c
+++ b/drivers/misc/ti_dac7512.c
@@ -72,6 +72,12 @@ static int dac7512_remove(struct spi_device *spi)
return 0;
}
+static const struct spi_device_id dac7512_id_table[] = {
+ { "dac7512", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, dac7512_id_table);
+
static struct spi_driver dac7512_driver = {
.driver = {
.name = "dac7512",
@@ -79,6 +85,7 @@ static struct spi_driver dac7512_driver = {
},
.probe = dac7512_probe,
.remove = dac7512_remove,
+ .id_table = dac7512_id_table,
};
module_spi_driver(dac7512_driver);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] drivers: misc: ti_dac7512: add support for DT matching
Only matching is done via DT, no other details can be passed.
Signed-off-by: Daniel Mack
---
.../devicetree/bindings/misc/ti,dac7512.txt | 20
drivers/misc/ti_dac7512.c| 10 ++
2 files changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/ti,dac7512.txt
diff --git a/Documentation/devicetree/bindings/misc/ti,dac7512.txt
b/Documentation/devicetree/bindings/misc/ti,dac7512.txt
new file mode 100644
index 000..1db4593
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ti,dac7512.txt
@@ -0,0 +1,20 @@
+TI DAC7512 DEVICETREE BINDINGS
+
+Required properties:
+
+ - "compatible" Must be set to "ti,dac7512"
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply. In particular, "reg" and "spi-max-frequency" properties must be given.
+
+
+Example:
+
+ spi_master {
+ dac7512: dac7512@0 {
+ compatible = "ti,dac7512";
+ reg = <0>; /* CS0 */
+ spi-max-frequency = <100>;
+ };
+ };
+
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
index 6393a68..83da711 100644
--- a/drivers/misc/ti_dac7512.c
+++ b/drivers/misc/ti_dac7512.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
static ssize_t dac7512_store_val(struct device *dev,
struct device_attribute *attr,
@@ -78,10 +79,19 @@ static const struct spi_device_id dac7512_id_table[] = {
};
MODULE_DEVICE_TABLE(spi, dac7512_id_table);
+#ifdef CONFIG_OF
+static const struct of_device_id dac7512_of_match[] = {
+ { .compatible = "ti,dac7512", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, dac7512_of_match);
+#endif
+
static struct spi_driver dac7512_driver = {
.driver = {
.name = "dac7512",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(dac7512_of_match),
},
.probe = dac7512_probe,
.remove = dac7512_remove,
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] drivers: misc: ti_dac7512: drop module version
Providing a module version doesn't add any value, so drop it.
Signed-off-by: Daniel Mack
---
drivers/misc/ti_dac7512.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
index 9b23722..db47333 100644
--- a/drivers/misc/ti_dac7512.c
+++ b/drivers/misc/ti_dac7512.c
@@ -24,7 +24,6 @@
#include
#define DAC7512_DRV_NAME "dac7512"
-#define DRIVER_VERSION "1.0"
static ssize_t dac7512_store_val(struct device *dev,
struct device_attribute *attr,
@@ -89,4 +88,3 @@ module_spi_driver(dac7512_driver);
MODULE_AUTHOR("Daniel Mack ");
MODULE_DESCRIPTION("DAC7512 16-bit DAC");
MODULE_LICENSE("GPL v2");
-MODULE_VERSION(DRIVER_VERSION);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] dac7512: some cleanups and DT bindings
On 23.09.2013 12:19, Mark Brown wrote: > On Sun, Sep 22, 2013 at 09:51:45PM +0200, Daniel Mack wrote: >> Here are some trivial things for the ti_dac7512 driver. >> >> Mark, can you take them through your spi tree? > > I can but it's normally Greg who looks after drivers/misc - probably > best to at least run these by him. Alright. Greg, I posted the series to LKML yesterday. Can you pick the patches from there or do you want me to resend? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
On 06.09.2012 08:02, Markus Trippelsdorf wrote: > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: >> >> Sound fixes for 3.6-rc5 >> >> There are nothing scaring, contains only small fixes for HD-audio and >> USB-audio: >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs >> - A series of USB-audio regression fixes that are found since 3.5 kernel >> >> -------- >> Daniel Mack (4): >> ALSA: snd-usb: Fix URB cancellation at stream start >> ALSA: snd-usb: restore delay information > > The commit fbcfbf5f above causes the following lines to be printed > whenever I start a new song: Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this patch (fbcfbf5f) brings back now. > delay: estimated 0, actual 352 > delay: estimated 353, actual 705 > > (44.1 * 8 = 352.8) > > This happens with an USB-DAC that identifies itself as "C-Media USB > Headphone Set". And you didn't you see these lines with 3.4? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: snd-usb: "delay: estimated 0, actual 352"
On 06.09.2012 08:53, Markus Trippelsdorf wrote: > On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: >> At Thu, 06 Sep 2012 08:33:30 +0200, >> Daniel Mack wrote: >>> >>> On 06.09.2012 08:02, Markus Trippelsdorf wrote: >>>> On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: >>>>> >>>>> Sound fixes for 3.6-rc5 >>>>> >>>>> There are nothing scaring, contains only small fixes for HD-audio and >>>>> USB-audio: >>>>> - EPSS regression fix and GPIO fix for HD-audio IDT codecs >>>>> - A series of USB-audio regression fixes that are found since 3.5 kernel >>>>> >>>>> >>>>> Daniel Mack (4): >>>>> ALSA: snd-usb: Fix URB cancellation at stream start >>>>> ALSA: snd-usb: restore delay information >>>> >>>> The commit fbcfbf5f above causes the following lines to be printed >>>> whenever I start a new song: >>> >>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this >>> patch (fbcfbf5f) brings back now. >>> >>>> delay: estimated 0, actual 352 >>>> delay: estimated 353, actual 705 >>>> >>>> (44.1 * 8 = 352.8) >>>> >>>> This happens with an USB-DAC that identifies itself as "C-Media USB >>>> Headphone Set". >>> >>> And you didn't you see these lines with 3.4? >> >> Maybe the difference of start condition? >> >> Markus, does the patch below fix anything? > > Unfortunately no. > However reverting the following fixes the problem: > > commit 245baf983cc39524cce39c24d01b276e6e653c9e > Author: Daniel Mack > Date: Thu Aug 30 18:52:30 2012 +0200 > > ALSA: snd-usb: fix calls to next_packet_size > No, this one certainly fixes a problem and does the right thing by restoring the original code. If you wouldn't state that you didn't see the same effect with 3.4(!), before the refactoring done in 3.5, I would believe the device is simply slightly off in its feedback rate and the tighter delay code complains about it while compensating, just as it did before. Are there any more than these two lines? And is audio working at all? Is it distorted in any way? Pierre-Louis, could you check whether I did the right thing when I ported over your delay bits to the new endpoint logic? Maybe I'm missing something here, but I currently don't see it. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: snd-usb: "delay: estimated 0, actual 352"
On 06.09.2012 09:35, Takashi Iwai wrote: > At Thu, 6 Sep 2012 09:17:57 +0200, > Markus Trippelsdorf wrote: >> >> On 2012.09.06 at 09:08 +0200, Daniel Mack wrote: >>> On 06.09.2012 08:53, Markus Trippelsdorf wrote: >>>> On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: >>>>> At Thu, 06 Sep 2012 08:33:30 +0200, >>>>> Daniel Mack wrote: >>>>>> >>>>>> On 06.09.2012 08:02, Markus Trippelsdorf wrote: >>>>>>> On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: >>>>>>>> >>>>>>>> Sound fixes for 3.6-rc5 >>>>>>>> >>>>>>>> There are nothing scaring, contains only small fixes for HD-audio and >>>>>>>> USB-audio: >>>>>>>> - EPSS regression fix and GPIO fix for HD-audio IDT codecs >>>>>>>> - A series of USB-audio regression fixes that are found since 3.5 >>>>>>>> kernel >>>>>>>> >>>>>>>> >>>>>>>> Daniel Mack (4): >>>>>>>> ALSA: snd-usb: Fix URB cancellation at stream start >>>>>>>> ALSA: snd-usb: restore delay information >>>>>>> >>>>>>> The commit fbcfbf5f above causes the following lines to be printed >>>>>>> whenever I start a new song: >>>>>> >>>>>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this >>>>>> patch (fbcfbf5f) brings back now. >>>>>> >>>>>>> delay: estimated 0, actual 352 >>>>>>> delay: estimated 353, actual 705 >>>>>>> >>>>>>> (44.1 * 8 = 352.8) >>>>>>> >>>>>>> This happens with an USB-DAC that identifies itself as "C-Media USB >>>>>>> Headphone Set". >>>>>> >>>>>> And you didn't you see these lines with 3.4? >>>>> >>>>> Maybe the difference of start condition? >>>>> >>>>> Markus, does the patch below fix anything? >>>> >>>> Unfortunately no. >>>> However reverting the following fixes the problem: >>>> >>>> commit 245baf983cc39524cce39c24d01b276e6e653c9e >>>> Author: Daniel Mack >>>> Date: Thu Aug 30 18:52:30 2012 +0200 >>>> >>>> ALSA: snd-usb: fix calls to next_packet_size >>>> >>> >>> No, this one certainly fixes a problem and does the right thing by >>> restoring the original code. >>> >>> If you wouldn't state that you didn't see the same effect with 3.4(!), >>> before the refactoring done in 3.5, I would believe the device is simply >>> slightly off in its feedback rate and the tighter delay code complains >>> about it while compensating, just as it did before. >>> >>> Are there any more than these two lines? And is audio working at all? Is >>> it distorted in any way? >> >> There are only these two lines (printed whenever sound starts). Audio is >> working just fine with no distortions. >> >> I did see similar lines before when the system load was very high >> (happend during "make check" when building glibc). >> >> Here is what Pierre-Louis wrote in November 2011: >> >> »This was supposed to be an informational message, I thought it was only >> enabled for debug. Regular users don't really need to know.« > > I guess the problem is that the new endpoint scheme doesn't count the > last_delay update unless the stream is triggered. In the old code, > retire_playback_urb is always called even before the trigger(START) is > set. And, there retire_playback_urb() does nothing but updating the > delay information. > > In the new code, retire_playback_urb is set only at > snd_usb_substream_playback_trigger(). Thus at the very first shot, > the delay account got confused. In that case, I'd say we can also safely remove the debug output then. Let's wait for Pierre-Louis' judgement here. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] DaVinci DMA engine conversion
Hi Matt, On 27.08.2012 17:33, Daniel Mack wrote: > On 23.08.2012 03:09, Matt Porter wrote: >> This series begins the conversion of the DaVinci private EDMA API >> implementation to a DMA engine driver and converts two of the three >> in-kernel users of the private EDMA API to DMA engine. >> >> The approach taken is similar to the recent OMAP DMA Engine >> conversion. The EDMA DMA Engine driver is a wrapper around the existing >> private EDMA implementation and registers the platform device within >> the driver. This allows the conversion series to stand alone with just >> the drivers and no changes to platform code. It also allows peripheral >> drivers to continue to use the private EDMA implementation until they >> are converted. >> >> The EDMA DMA Engine driver supports slave transfers only at this time. It >> is planned to add cyclic transfers in support of audio peripherals. >> >> There are three users of the private EDMA API in the kernel now: >> davinci_mmc, spi-davinci, and davinci-mcasp. This series provides DMA >> Engine conversions for the davinci_mmc and spi-davinci drivers which >> use the supported slave transfers. >> >> This series has been tested on an AM18x EVM and Hawkboard with >> driver performance comparable to that of the private EDMA API >> implementations. Both MMC0 and MMC1 are tested which handles the >> DA850/OMAP-L138/AM18x specific case where MMC1 uses DMA channels on >> a second EDMA channel controller. All other platforms have a simpler >> design with just a single EDMA channel controller. >> >> For those wanting to easily test this series, I've pushed a branch for >> each version to my github tree at https://github.com/ohporter/linux. The >> current branch is edma-dmaengine-v3. >> >> After this series, the current plan is to complete the mcasp driver >> conversion which includes adding cyclic dma support. This will then >> enable the removal and refactoring of the private EDMA API functionality >> into the EDMA DMA Engine driver. Since EDMA is also used on the AM33xx >> family of parts in mach-omap2/, the plan is to enable this driver on >> that platform as well. > > Once you have a patch for the McASP driver conversion, I can happily > test this on a AM33xx board, together with Gururaja's latest McASP > refactoring series. Let me know how I can help you here. Did you find some time yet to continue on this side? I don't want to appear pushy, but as I need to finish some DT transition on a AM33xx-based board, I would much like to help out here, in case I can do anything to help speed things along. Many thanks for your work! Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: snd-usb: "delay: estimated 0, actual 352"
On 06.09.2012 16:31, Takashi Iwai wrote: > At Thu, 6 Sep 2012 15:17:58 +0200, > Markus Trippelsdorf wrote: >> >> On 2012.09.06 at 15:08 +0200, Takashi Iwai wrote: >>> At Thu, 6 Sep 2012 11:43:48 +0200, >>> Markus Trippelsdorf wrote: On 2012.09.06 at 10:21 +0200, Takashi Iwai wrote: > At Thu, 06 Sep 2012 09:35:26 +0200, > Takashi Iwai wrote: > > In short, a patch like below may fix the issue (note: completely > untested!) No it doesn't, unfortunately... >>> >>> OK, I start tracking down the problem a bit more deeply now. >>> >>> The issue happens when the first two URBs are passed to >>> retire_playback_urb(). These are URBs filled before start_endpoints() >>> are set, so they contain actually zero size. Even though these are >>> a sort of dummy packets, the driver still tries to check with the >>> queued delay account, and gives bogus errors. >>> >>> So, essentially the messages are harmless and nothing to worry too >>> much, but surely it doesn't look sexy. >>> >>> The patch below should fix the problem. Please give it a try. >> >> Yes, your patch finally fixes the problem. >> Thank you Takashi-san. > > Thanks for your quick test! > > If Daniel has no objection with that patch, I'm going to merge it. No objections from my side. I also gave it a quick test, and even though I never saw the problem Markus was seeing, I agree to your findings. Many thanks, everyone :) Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2012-09-06-16-46 uploaded (drivers/misc/lis3lv02d/lis3lv02d_spi.c)
On 08.09.2012 02:50, Randy Dunlap wrote: > On 09/06/2012 04:47 PM, a...@linux-foundation.org wrote: > >> The mm-of-the-moment snapshot 2012-09-06-16-46 has been uploaded to >> >>http://www.ozlabs.org/~akpm/mmotm/ >> > > > > on x86_64: > > CONFIG_OF and CONFIG_DTC are not enabled. > > > drivers/misc/lis3lv02d/lis3lv02d_spi.c:137:3: error: implicit declaration of > function 'of_match_ptr' > drivers/misc/lis3lv02d/lis3lv02d_spi.c:137:3: error: initializer element is > not constant > drivers/misc/lis3lv02d/lis3lv02d_spi.c:137:3: error: (near initialization for > 'lis302dl_spi_driver.driver.of_match_table') > > Thanks - the attached patch fixes it. Daniel >From 3c415511cb825d5b5d015b716e14d720a3d56bf6 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Sat, 8 Sep 2012 12:41:33 +0200 Subject: [PATCH] lis3: lis3lv02d_spi.c: include linux/of.h This include is needed to define of_match:ptr() for !CONFIG_OF && 1CONFIG_DTC. Signed-off-by: Daniel Mack Reported-by: Randy Dunlap --- drivers/misc/lis3lv02d/lis3lv02d_spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/lis3lv02d/lis3lv02d_spi.c b/drivers/misc/lis3lv02d/lis3lv02d_spi.c index 8616054..23f3986 100644 --- a/drivers/misc/lis3lv02d/lis3lv02d_spi.c +++ b/drivers/misc/lis3lv02d/lis3lv02d_spi.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include "lis3lv02d.h" -- 1.7.11.4
[PATCH] regulator: gpio-regulator: add DT bindings
Add DT bindings for the gpio-regulator driver and some documentation on
how to use it.
Signed-off-by: Daniel Mack
---
.../bindings/regulator/gpio-regulator.txt | 58 ++
drivers/regulator/gpio-regulator.c | 118 -
2 files changed, 175 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/regulator/gpio-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
new file mode 100644
index 000..ea3eb09
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -0,0 +1,58 @@
+Device tree bindings for GPIO controlled voltages
+
+Voltage or current regulators on boards that are controlled by GPIOs can
+be used by the gpio-regulator driver.
+
+Required properties:
+
+ - "compatible": must be set to "gpio-regulator"
+ - "regulator-name": must be set to a string describing the name of this
+ regulator.
+
+Optional properties:
+
+ - "startup-delay":Start-up time in microseconds
+ - "enable-high": Polarity of enable GPIO. Active high if
+ defined, otherwise active low
+ - "enabled-at-boot": If set, the regulator has been enabled at boot
+ time
+ - "regulator-type-voltage": The regulator controls a voltage
+ - "regulator-type-current": The regulator controls a current
+ - "states": An array of possible states, describing the
+ GPIO states to reach a given value
+ - "value": The value of the state, in microvolts or
+ microamperes
+ - "gpios": bitfield of gpio target-states for the value
+ The n-th bit in the bitfield describes the
+ state of the n-th GPIO from the gpios-array
+
+Also, all properties described in
+Documentation/devicetree/bindings/regulator/regulator.txt are supported as
+well.
+
+Example:
+
+ reg_gpio {
+ compatible = "gpio-regulator";
+ regulator-name = "voltage";
+ regulator-enable-high;
+ regulator-type-voltage;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+
+ gpios = <&gpio 23 0>;
+
+ states {
+ state-on {
+ value = <330>;
+ gpios = <0x1>;
+ };
+
+ state-off {
+ value = <0>;
+ gpios = <0x0>;
+ };
+ };
+ };
+
diff --git a/drivers/regulator/gpio-regulator.c
b/drivers/regulator/gpio-regulator.c
index 8b5944f..c44edd0 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -25,10 +25,14 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -134,13 +138,124 @@ static struct regulator_ops gpio_regulator_current_ops =
{
.set_current_limit = gpio_regulator_set_current_limit,
};
+#ifdef CONFIG_OF
+static const struct of_device_id gpio_regulator_dt_ids[] = {
+ { .compatible = "gpio-regulator", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gpio_regulator_dt_ids);
+
+static int gpio_regulator_probe_dt(struct platform_device *pdev)
+{
+ struct device_node *states, *np = pdev->dev.of_node;
+ struct gpio_regulator_config *config;
+ int ret, i;
+
+ if (!np)
+ return 0;
+
+ config = kzalloc(sizeof(config), GFP_KERNEL);
+ if (!config) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+
+ config->nr_gpios = of_gpio_named_count(np, "gpios");
+ config->gpios = kcalloc(config->nr_gpios, sizeof(struct gpio),
+ GFP_KERNEL);
+ if (!config->gpios) {
+ ret = -ENOMEM;
+ goto exit_free_config;
+ }
+
+ for (i = 0; i < config->nr_gpios; i++) {
+ int gpio = of_get_named_gpio(np, "gpios", i);
+
+ config->gpios[i].gpio = gpio;
+ config->gpios[i].flags = GPIOF_DIR_OUT;
+ }
+
+ config->supply_name =
+ kstrdup(of_get_property(np, "regulator-name", NULL),
+ GFP_KERNEL);
+ of_property_read_u32(np, "startup-delay", &config->startup_delay);
[PATCH v2] regulator: gpio-regulator: add DT bindings
Add DT bindings for the gpio-regulator driver and some documentation on
how to use it.
Signed-off-by: Daniel Mack
---
v1 -> v2
Fixed wrong kzalloc() size.
.../bindings/regulator/gpio-regulator.txt | 58 ++
drivers/regulator/gpio-regulator.c | 118 -
2 files changed, 175 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/regulator/gpio-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
new file mode 100644
index 000..ea3eb09
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -0,0 +1,58 @@
+Device tree bindings for GPIO controlled voltages
+
+Voltage or current regulators on boards that are controlled by GPIOs can
+be used by the gpio-regulator driver.
+
+Required properties:
+
+ - "compatible": must be set to "gpio-regulator"
+ - "regulator-name": must be set to a string describing the name of this
+ regulator.
+
+Optional properties:
+
+ - "startup-delay":Start-up time in microseconds
+ - "enable-high": Polarity of enable GPIO. Active high if
+ defined, otherwise active low
+ - "enabled-at-boot": If set, the regulator has been enabled at boot
+ time
+ - "regulator-type-voltage": The regulator controls a voltage
+ - "regulator-type-current": The regulator controls a current
+ - "states": An array of possible states, describing the
+ GPIO states to reach a given value
+ - "value": The value of the state, in microvolts or
+ microamperes
+ - "gpios": bitfield of gpio target-states for the value
+ The n-th bit in the bitfield describes the
+ state of the n-th GPIO from the gpios-array
+
+Also, all properties described in
+Documentation/devicetree/bindings/regulator/regulator.txt are supported as
+well.
+
+Example:
+
+ reg_gpio {
+ compatible = "gpio-regulator";
+ regulator-name = "voltage";
+ regulator-enable-high;
+ regulator-type-voltage;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+
+ gpios = <&gpio 23 0>;
+
+ states {
+ state-on {
+ value = <330>;
+ gpios = <0x1>;
+ };
+
+ state-off {
+ value = <0>;
+ gpios = <0x0>;
+ };
+ };
+ };
+
diff --git a/drivers/regulator/gpio-regulator.c
b/drivers/regulator/gpio-regulator.c
index 8b5944f..d34ec68 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -25,10 +25,14 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -134,13 +138,124 @@ static struct regulator_ops gpio_regulator_current_ops =
{
.set_current_limit = gpio_regulator_set_current_limit,
};
+#ifdef CONFIG_OF
+static const struct of_device_id gpio_regulator_dt_ids[] = {
+ { .compatible = "gpio-regulator", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gpio_regulator_dt_ids);
+
+static int gpio_regulator_probe_dt(struct platform_device *pdev)
+{
+ struct device_node *states, *np = pdev->dev.of_node;
+ struct gpio_regulator_config *config;
+ int ret, i;
+
+ if (!np)
+ return 0;
+
+ config = kzalloc(sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+
+ config->nr_gpios = of_gpio_named_count(np, "gpios");
+ config->gpios = kcalloc(config->nr_gpios, sizeof(struct gpio),
+ GFP_KERNEL);
+ if (!config->gpios) {
+ ret = -ENOMEM;
+ goto exit_free_config;
+ }
+
+ for (i = 0; i < config->nr_gpios; i++) {
+ int gpio = of_get_named_gpio(np, "gpios", i);
+
+ config->gpios[i].gpio = gpio;
+ config->gpios[i].flags = GPIOF_DIR_OUT;
+ }
+
+ config->supply_name =
+ kstrdup(of_get_property(np, "regulator-name", NULL),
+ GFP_KERNEL);
+ of_property_read_u32(np, "startup-delay", &con
Re: 3.6.0 regression, distorted sound failure while using jack and hd-audio
(cc alsa-devel) On 07.10.2012 21:34, Helge Hafting wrote: > My sound setup works fine with 3.5.4, but have serious problems with 3.6.0 > > It is sound through jack that breaks, simply using "aplay" directly with the > alsa device works. > > When I use jack, my setup works fine with 3.5.4. But boot into 3.6.0, > and I get badly distorted sound as if using an extremely overdone reverb > effect. > And jack reports tons of xruns, several per second. > > This can be worked around by going from 256 to 512 frames/period in the jack > settings. But that also double the latency, which makes keyboard playing less > pleasant. > > It is not a case of 256 frames/period being (almost) too extreme for the > machine. With kernel 3.5.4, > I can use 128 frames/period and get mostly ok sound, with only an occational > xrun (and a correseponding pop in the sound). So I use 256 because that's > solid. > But with 3.6.0, not even 256 is enough. And it is not an occational pop, but > awful distortion all the time. > > I don't really know what has changed from 3.5.4 to 3.6.0. The hd-audio driver? > Something in alsa? Or the scheduling? > > Machine: Dell precision M6600 laptop, 8GB, 2.2GHz quad-core i7. > Usually at 800MHz to save power, this is enough for making sound. > Kernels: 64-bit 3.5.4 or 3.6.0 > Distro: funtoo > > Audio according to lspci: > 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family > High Definition Audio Controller (rev 04) > > Please tell if there is anything I should try. I can test other kernel > versions > or try patches. > > Helge Hafting > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb 3.0 hard drive doesn't work
(cc linux-usb) On 07.10.2012 10:48, 王思源 wrote: > hi, > i have a usb 3.0 hard drive and a laptop with usb 3.0 port. > when the hard drive is connected to the usb 3.0 port, the drive could > not be found. > the dmesg output is listed below. > additinal info: > 1) the usb 3.0 hard drive can be found when connected to usb 2.0 port. > 2) the usb 2.0 hard drive can be found when connected to usb 3.0 port. > 3) mouse works when connected to the usb 3.0 port. > 4) it is archlinux and kernel version is 3.5.5-1-ARCH > it seems that it is not the linux driver's problem, because the mouse > could work and the hard drive is found due to the dmesg. > is this a bug? > would someone help me? > thank you! > > dmesg out put when usb 3.0 hard drive is conneted to usb 3.0 port: > [ 646.077385] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd > [ 646.171319] usbcore: registered new interface driver uas > [ 646.175313] Initializing USB Mass Storage driver... > [ 646.175501] scsi4 : usb-storage 2-2:1.0 > [ 646.175665] usbcore: registered new interface driver usb-storage > [ 646.175667] USB Mass Storage support registered. > [ 657.149403] scsi 4:0:0:0: Direct-Access WD My Passport > 0730 1016 PQ: 0 ANSI: 6 > [ 657.149974] sd 4:0:0:0: [sdb] 976707584 512-byte logical blocks: > (500 GB/465 GiB) > [ 657.150223] sd 4:0:0:0: [sdb] Write Protect is off > [ 657.150232] sd 4:0:0:0: [sdb] Mode Sense: 47 00 10 08 > [ 657.150456] sd 4:0:0:0: [sdb] No Caching mode page present > [ 657.150462] sd 4:0:0:0: [sdb] Assuming drive cache: write through > [ 657.151436] sd 4:0:0:0: [sdb] No Caching mode page present > [ 657.151440] sd 4:0:0:0: [sdb] Assuming drive cache: write through > [ 657.159907] sdb: sdb1 > [ 657.160852] sd 4:0:0:0: [sdb] No Caching mode page present > [ 657.160858] sd 4:0:0:0: [sdb] Assuming drive cache: write through > [ 657.160861] sd 4:0:0:0: [sdb] Attached SCSI disk > [ 657.268875] usb 2-2: Device not responding to set address. > [ 657.471456] usb 2-2: Device not responding to set address. > [ 657.674211] usb 2-2: device not accepting address 2, error -71 > [ 657.780745] usb 2-2: Device not responding to set address. > [ 657.983519] usb 2-2: Device not responding to set address. > [ 658.186214] usb 2-2: device not accepting address 2, error -71 > [ 658.292717] usb 2-2: Device not responding to set address. > [ 658.495537] usb 2-2: Device not responding to set address. >From the logs, this smells like a power supply problem. Can you connect an external supply or do you have a powered USB3 hub? It's possible that it draws less power in USB2.0 mode, so that would explain what you describe. But I could be wrong alltogether :) Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Convert davinci ASoC to genalloc SRAM
On 10.10.2012 08:54, Kumar, Anil wrote: > On Thu, Oct 04, 2012 at 15:45:43, Porter, Matt wrote: >> This series converts davinci ASoC to use genalloc and enables >> that support on DA850. It applies on top of the uio_pruss/genalloc >> series [1] which allows DaVinci to provide a gen_pool via pdata >> for driver use. >> >> I've tested this on the AM180x EVM. Note that prior to this, >> the SRAM paths in the driver were completely unused. I've only >> enabled ping-pong buffering on the platform I can test as it's >> best to allow those with DM644x and similar platforms to set the >> playback/capture sram size to something that's known to work >> for them. >> >> [1] http://www.spinics.net/lists/arm-kernel/msg198854.html > > Tested on DA850 EVM after applying patches from [1] above. > Tested on Linux-torvalds 3.6-rc6 master branch. > Tested ASoC module (aplay & arecord for various frequencies) > > Acked-by: Kumar, Anil As you're on it, could you also quickly merge this branch git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/davinci And see if my recent patches for more McASP flexibility cause any trouble on your hardware? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Convert davinci ASoC to genalloc SRAM
On 10.10.2012 11:59, Kumar, Anil wrote:
> On Wed, Oct 10, 2012 at 12:34:47, Daniel Mack wrote:
>> On 10.10.2012 08:54, Kumar, Anil wrote:
>>> On Thu, Oct 04, 2012 at 15:45:43, Porter, Matt wrote:
>>>> This series converts davinci ASoC to use genalloc and enables
>>>> that support on DA850. It applies on top of the uio_pruss/genalloc
>>>> series [1] which allows DaVinci to provide a gen_pool via pdata
>>>> for driver use.
>>>>
>>>> I've tested this on the AM180x EVM. Note that prior to this,
>>>> the SRAM paths in the driver were completely unused. I've only
>>>> enabled ping-pong buffering on the platform I can test as it's
>>>> best to allow those with DM644x and similar platforms to set the
>>>> playback/capture sram size to something that's known to work
>>>> for them.
>>>>
>>>> [1] http://www.spinics.net/lists/arm-kernel/msg198854.html
>>>
>>> Tested on DA850 EVM after applying patches from [1] above.
>>> Tested on Linux-torvalds 3.6-rc6 master branch.
>>> Tested ASoC module (aplay & arecord for various frequencies)
>>>
>>> Acked-by: Kumar, Anil
>>
>> As you're on it, could you also quickly merge this branch
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>> topic/davinci
>>
>> And see if my recent patches for more McASP flexibility cause any
>> trouble on your hardware?
>>
>>
>> Daniel
>>
>>
>
> I have merged it with 3.6-rc6 and I have got error at compile time.
> I have fixed this locally with the following patch [1].
> Kindly confirm if the patch is correct?
I did the same thing locally, but I considered this a merge conflict.
> With that
> Tested on DA850 EVM
> Tested on Linux-torvalds 3.6-rc6 master branch merged + [1]
> Tested ASoC module (aplay & arecord for various frequencies)
>
> Tested-By: Kumar, Anil
Ok, that's good to hear. Thanks a lot :)
Daniel
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 09da4e5..9c02a45 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -591,7 +591,7 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
> struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
> size_t period_len, enum dma_transfer_direction direction,
> - unsigned long flags, void *context);
> + void *context);
> struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
> struct dma_chan *chan, struct dma_interleaved_template *xt,
> unsigned long flags);
> @@ -656,7 +656,7 @@ static inline struct dma_async_tx_descriptor
> *dmaengine_prep_dma_cyclic(
> size_t period_len, enum dma_transfer_direction dir)
> {
> return chan->device->device_prep_dma_cyclic(chan, buf_addr, buf_len,
> - period_len, dir, flags, NULL);
> + period_len, dir, NULL);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] Convert davinci ASoC to genalloc SRAM
On 17.10.2012 15:51, Mark Brown wrote: > On Thu, Oct 11, 2012 at 05:33:47PM -0400, Matt Porter wrote: > >> This series converts davinci ASoC to use genalloc and enables >> that support on DA850. It applies to mainline on top of the >> uio_pruss/genalloc series [1] which allows DaVinci to provide >> a gen_pool via pdata for driver use. > > I tried to apply these patches but patch 2 doesn't apply against > v3.7-rc1 I guess due to the series you mention. What's the plan for > merging that series? It'd also be good to get Daniel's patch squashed > in. I'll resend the rebased patches from my 3.7-rc1 development branch with my patch squashed into 1/2. Matt, hope you're ok with that? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] ASoC: davinci: replace private sram api with genalloc
On 18.10.2012 17:21, Matt Porter wrote:
> On Fri, Oct 12, 2012 at 07:15:53PM +0200, Daniel Mack wrote:
>> Hi Matt,
>>
>> On 11.10.2012 23:33, Matt Porter wrote:
>>> Removes the DaVinci private SRAM API and replaces it with
>>> the genalloc API. The SRAM gen_pool is passed in pdata since
>>> DaVinci is in the early stages of DT conversion.
>>>
>>> Signed-off-by: Matt Porter
>>> ---
>>> include/linux/platform_data/davinci_asp.h |3 +++
>>> sound/soc/davinci/davinci-mcasp.c |2 ++
>>> sound/soc/davinci/davinci-pcm.c | 18 --
>>> sound/soc/davinci/davinci-pcm.h |2 ++
>>> 4 files changed, 19 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/include/linux/platform_data/davinci_asp.h
>>> b/include/linux/platform_data/davinci_asp.h
>>> index d0c5825..f3d6e4f 100644
>>> --- a/include/linux/platform_data/davinci_asp.h
>>> +++ b/include/linux/platform_data/davinci_asp.h
>>> @@ -16,6 +16,8 @@
>>> #ifndef __DAVINCI_ASP_H
>>> #define __DAVINCI_ASP_H
>>>
>>> +#include
>>> +
>>> struct snd_platform_data {
>>> u32 tx_dma_offset;
>>> u32 rx_dma_offset;
>>> @@ -30,6 +32,7 @@ struct snd_platform_data {
>>> unsigned enable_channel_combine:1;
>>> unsigned sram_size_playback;
>>> unsigned sram_size_capture;
>>> + struct gen_pool *sram_pool;
>>>
>>> /*
>>> * If McBSP peripheral gets the clock from an external pin,
>>> diff --git a/sound/soc/davinci/davinci-mcasp.c
>>> b/sound/soc/davinci/davinci-mcasp.c
>>> index 714e51e..52194bb 100644
>>> --- a/sound/soc/davinci/davinci-mcasp.c
>>> +++ b/sound/soc/davinci/davinci-mcasp.c
>>> @@ -1098,6 +1098,7 @@ static int davinci_mcasp_probe(struct platform_device
>>> *pdev)
>>> dma_data = &dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK];
>>> dma_data->asp_chan_q = pdata->asp_chan_q;
>>> dma_data->ram_chan_q = pdata->ram_chan_q;
>>> + dma_data->sram_pool = pdata->sram_pool;
>>> dma_data->sram_size = pdata->sram_size_playback;
>>> dma_data->dma_addr = (dma_addr_t) (pdata->tx_dma_offset +
>>> mem->start);
>>> @@ -1115,6 +1116,7 @@ static int davinci_mcasp_probe(struct platform_device
>>> *pdev)
>>> dma_data = &dev->dma_params[SNDRV_PCM_STREAM_CAPTURE];
>>> dma_data->asp_chan_q = pdata->asp_chan_q;
>>> dma_data->ram_chan_q = pdata->ram_chan_q;
>>> + dma_data->sram_pool = pdata->sram_pool;
>>> dma_data->sram_size = pdata->sram_size_capture;
>>> dma_data->dma_addr = (dma_addr_t)(pdata->rx_dma_offset +
>>> mem->start);
>>> diff --git a/sound/soc/davinci/davinci-pcm.c
>>> b/sound/soc/davinci/davinci-pcm.c
>>> index 93ea3bf..d2cc169 100644
>>> --- a/sound/soc/davinci/davinci-pcm.c
>>> +++ b/sound/soc/davinci/davinci-pcm.c
>>> @@ -16,6 +16,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -23,7 +24,6 @@
>>> #include
>>>
>>> #include
>>> -#include
>>>
>>> #include "davinci-pcm.h"
>>>
>>> @@ -259,7 +259,8 @@ static void davinci_pcm_dma_irq(unsigned link, u16
>>> ch_status, void *data)
>>> }
>>> }
>>>
>>> -static int allocate_sram(struct snd_pcm_substream *substream, unsigned
>>> size,
>>> +static int allocate_sram(struct snd_pcm_substream *substream,
>>> + struct gen_pool *sram_pool, unsigned size,
>>> struct snd_pcm_hardware *ppcm)
>>> {
>>> struct snd_dma_buffer *buf = &substream->dma_buffer;
>>> @@ -271,9 +272,10 @@ static int allocate_sram(struct snd_pcm_substream
>>> *substream, unsigned size,
>>> return 0;
>>>
>>> ppcm->period_bytes_max = size;
>>> - iram_virt = sram_alloc(size, &iram_phys);
>>> + iram_virt = (void *)gen_pool_alloc(sram_pool, size);
>>
>> Did you see my patch that stubs out all functions that use gen_pool_*
>> functions for !CONFIG_GENERIC_ALLOCATOR configs? It should still apply
>> nicely on top of this one, and is necessary for AM33xx-only builds.
>
> Sorry, I've had the last week of list traffic go to /dev/null. Catching
> up now and I do see that. I'm assuming that will all be in your updated
> series with these patches squashed in?
Yes, exactly. I already sent them out yesterday.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 01:15, Artem S. Tashkinov wrote: > You don't get me - I have *no* VirtualBox (or any proprietary) modules running > - but I can reproduce this problem using *the same system running under* > VirtualBox > in Windows 7 64. > > It's almost definitely either a USB driver bug or video4linux driver bug: > > I'm CC'ing linux-media and linux-usb mailing lists, the problem is described > here: > https://lkml.org/lkml/2012/10/20/35 > https://lkml.org/lkml/2012/10/20/148 > > Here are the last lines from my dmesg (with usbmon loaded): > > [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg evt 0002 > [ 292.168091] ehci_hcd :00:1f.5: GetStatus port:1 status 00100a 0 ACK > POWER sig=se0 PEC CSC > [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s > [ 292.174883] usb 1-1: USB disconnect, device number 2 > [ 292.178045] usb 1-1: unregistering device > [ 292.183539] usb 1-1: unregistering interface 1-1:1.0 > [ 292.197034] usb 1-1: unregistering interface 1-1:1.1 > [ 292.204317] usb 1-1: unregistering interface 1-1:1.2 > [ 292.234519] usb 1-1: unregistering interface 1-1:1.3 > [ 292.236175] usb 1-1: usb_disable_device nuking all URBs > [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status > 0x100 > [ 294.364279] hub 1-0:1.0: hub_suspend > [ 294.366045] usb usb1: bus auto-suspend, wakeup 1 > [ 294.367375] ehci_hcd :00:1f.5: suspend root hub > [ 296.501084] usb usb1: usb wakeup-resume > [ 296.508311] usb usb1: usb auto-resume > [ 296.509833] ehci_hcd :00:1f.5: resume root hub > [ 296.560149] hub 1-0:1.0: hub_resume > [ 296.562240] ehci_hcd :00:1f.5: GetStatus port:1 status 001003 0 ACK > POWER sig=se0 CSC CONNECT > [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001 > [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt > [ 296.673222] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s > [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd > [ 300.547237] usb 1-1: skipped 1 descriptor after configuration > [ 300.549443] usb 1-1: skipped 4 descriptors after interface > [ 300.552273] usb 1-1: skipped 2 descriptors after interface > [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint > [ 300.559392] usb 1-1: skipped 2 descriptors after interface > [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint > [ 300.562169] usb 1-1: skipped 2 descriptors after interface > [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint > [ 300.564639] usb 1-1: skipped 2 descriptors after interface > [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint > [ 300.567084] usb 1-1: skipped 9 descriptors after interface > [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint > [ 300.570484] usb 1-1: skipped 53 descriptors after interface > [ 300.595843] usb 1-1: default language 0x0409 > [ 300.602503] usb 1-1: USB interface quirks for this device: 2 > [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2 > [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d > [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, > SerialNumber=1 > [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0 > [ 300.617703] usb 1-1: usb_probe_device > [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice > [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0) > [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface > [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id > [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1) > [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2) > [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface > [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id > [ 301.059395] uvcvideo: Found UVC 1.00 device (046d:081d) > [ 301.090173] input: UVC Camera (046d:081d) as > /devices/pci:00/:00:1f.5/usb1/1-1/1-1:1.2/input/input7 That seems to be a Logitech model. > [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3) > [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.196606] set resolution quirk: cval->res = 384 > [ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: RX > [ 390.729568] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 > us] > 437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 > [1/0 us] > -115:128 16 < > f5ade900 2296566256 C Ii:1:003:7 -2:128 0 > [ 391.100896] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > [ 391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > f5ade900 2296926929 S Ii:1:003:7[
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 12:34, Daniel Mack wrote: > On 21.10.2012 01:15, Artem S. Tashkinov wrote: >> You don't get me - I have *no* VirtualBox (or any proprietary) modules >> running >> - but I can reproduce this problem using *the same system running under* >> VirtualBox >> in Windows 7 64. >> >> It's almost definitely either a USB driver bug or video4linux driver bug: >> >> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described >> here: >> https://lkml.org/lkml/2012/10/20/35 >> https://lkml.org/lkml/2012/10/20/148 >> >> Here are the last lines from my dmesg (with usbmon loaded): >> >> [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg evt 0002 >> [ 292.168091] ehci_hcd :00:1f.5: GetStatus port:1 status 00100a 0 ACK >> POWER sig=se0 PEC CSC >> [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s >> [ 292.174883] usb 1-1: USB disconnect, device number 2 >> [ 292.178045] usb 1-1: unregistering device >> [ 292.183539] usb 1-1: unregistering interface 1-1:1.0 >> [ 292.197034] usb 1-1: unregistering interface 1-1:1.1 >> [ 292.204317] usb 1-1: unregistering interface 1-1:1.2 >> [ 292.234519] usb 1-1: unregistering interface 1-1:1.3 >> [ 292.236175] usb 1-1: usb_disable_device nuking all URBs >> [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms >> status 0x100 >> [ 294.364279] hub 1-0:1.0: hub_suspend >> [ 294.366045] usb usb1: bus auto-suspend, wakeup 1 >> [ 294.367375] ehci_hcd :00:1f.5: suspend root hub >> [ 296.501084] usb usb1: usb wakeup-resume >> [ 296.508311] usb usb1: usb auto-resume >> [ 296.509833] ehci_hcd :00:1f.5: resume root hub >> [ 296.560149] hub 1-0:1.0: hub_resume >> [ 296.562240] ehci_hcd :00:1f.5: GetStatus port:1 status 001003 0 ACK >> POWER sig=se0 CSC CONNECT >> [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001 >> [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt >> [ 296.673222] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s >> [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd >> [ 300.547237] usb 1-1: skipped 1 descriptor after configuration >> [ 300.549443] usb 1-1: skipped 4 descriptors after interface >> [ 300.552273] usb 1-1: skipped 2 descriptors after interface >> [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint >> [ 300.559392] usb 1-1: skipped 2 descriptors after interface >> [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint >> [ 300.562169] usb 1-1: skipped 2 descriptors after interface >> [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint >> [ 300.564639] usb 1-1: skipped 2 descriptors after interface >> [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint >> [ 300.567084] usb 1-1: skipped 9 descriptors after interface >> [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint >> [ 300.570484] usb 1-1: skipped 53 descriptors after interface >> [ 300.595843] usb 1-1: default language 0x0409 >> [ 300.602503] usb 1-1: USB interface quirks for this device: 2 >> [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2 >> [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d >> [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, >> SerialNumber=1 >> [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0 >> [ 300.617703] usb 1-1: usb_probe_device >> [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice >> [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0) >> [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface >> [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id >> [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1) >> [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2) >> [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface >> [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id >> [ 301.059395] uvcvideo: Found UVC 1.00 device (046d:081d) >> [ 301.090173] input: UVC Camera (046d:081d) as >> /devices/pci:00/:00:1f.5/usb1/1-1/1-1:1.2/input/input7 > > That seems to be a Logitech model. > >> [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3) >> [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] >> [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] >> [ 301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule >> [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] >> [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 13:59, Artem S. Tashkinov wrote: > On Oct 21, 2012, Borislav Petkov wrote: >> >> On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote: >>> The freeze happens on my *host* Linux PC. For an experiment I decided >>> to check if I could reproduce the freeze under a virtual machine - it >>> turns out the Linux kernel running under it also freezes. >> >> I know that - but a freeze != oops - at least not necessarily. Which >> means it could very well be a different issue now that vbox is gone. >> >> Or, it could be the same issue with different incarnations: with vbox >> you get the corruptions and without it, you get the freezes. I'm >> assuming you do the same flash player thing in both cases? >> >> Here's a crazy idea: can you try to reproduce it in KVM? > > OK, dismiss VBox altogether - it has a very buggy USB implementation, thus > it just hangs when trying to access my webcam. Ok. > What I've found out is that my system crashes *only* when I try to enable > usb-audio (from the same webcam) - I still have no idea how to capture a > panic message, but I ran > > "while :; do dmesg -c; done" in xterm, then I got like thousands of messages > and I photographed my monitor: > > http://imageshack.us/a/img685/9452/panicz.jpg A hint at least. How did you enable the audio record exactly? Can you reproduce this with arecord? What chipset are you on? Please provide both "lspci -v" and "lsusb -v" dumps. As I said, I fail to reproduce that issue on any of my machines. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 13:59, Artem S. Tashkinov wrote: > On Oct 21, 2012, Borislav Petkov wrote: >> >> On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote: >>> The freeze happens on my *host* Linux PC. For an experiment I decided >>> to check if I could reproduce the freeze under a virtual machine - it >>> turns out the Linux kernel running under it also freezes. >> >> I know that - but a freeze != oops - at least not necessarily. Which >> means it could very well be a different issue now that vbox is gone. >> >> Or, it could be the same issue with different incarnations: with vbox >> you get the corruptions and without it, you get the freezes. I'm >> assuming you do the same flash player thing in both cases? >> >> Here's a crazy idea: can you try to reproduce it in KVM? > > OK, dismiss VBox altogether - it has a very buggy USB implementation, thus > it just hangs when trying to access my webcam. > > What I've found out is that my system crashes *only* when I try to enable > usb-audio (from the same webcam) It would also be interesting to know whether you have problems with *only* the video capture, with some tool like "cheese". It might be you're hitting a host controller issue here, and then isochronous input packets on the video interface would most likely also trigger such am effect. Actually, knowing whether that's the case would be crucial for further debugging. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
[Cc: alsa-devel]
On 21.10.2012 14:30, Artem S. Tashkinov wrote:
> On Oct 21, 2012, Daniel Mack wrote:
>
>> A hint at least. How did you enable the audio record exactly? Can you
>> reproduce this with arecord?
>>
>> What chipset are you on? Please provide both "lspci -v" and "lsusb -v"
>> dumps. As I said, I fail to reproduce that issue on any of my machines.
>
> All other applications can read from the USB audio without problems, it's
> just something in the way Adobe Flash polls my audio input which causes
> a crash.
>
> Just video capture (without audio) works just fine in Adobe Flash.
Ok, so that pretty much rules out the host controller. I just wonder why
I still don't see it here, and I haven't heard of any such problem from
anyone else.
Some more questions:
- Which version of Flash are you running?
- Does this also happen with Firefox?
- Does flash access the device directly or via PulseAudio?
- Could you please apply the attached patch and see what it spits out to
dmesg once Flash opens the device? It returns -EINVAL in the hw_params
callback to prevent the actual streaming. On my machine with Flash
11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane.
Or does your machine still crash before anything is written to the logs?
> Only and only when I choose to use
>
> USB Device 0x46d:0x81d my system crashes in Adobe Flash.
>
> See the screenshot:
>
> https://bugzilla.kernel.org/attachment.cgi?id=84151
When exactly does the crash happen? Right after you selected that entry
from the list? There's a little recording level meter in that dialog.
Does that show any input from the microphone?
> My hardware information can be fetched from here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=49181
>
> On a second thought that can be even an ALSA crash or pretty much
> anything else.
We'll see. Thanks for your help to sort this out!
Daniel
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index f782ce1..5664b45 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -453,6 +453,18 @@ static int snd_usb_hw_params(struct snd_pcm_substream *substream,
unsigned int channels, rate, format;
int ret, changed;
+
+ printk(">>> %s()\n", __func__);
+
+ printk("format: %d\n", params_format(hw_params));
+ printk("rate: %d\n", params_rate(hw_params));
+ printk("channels: %d\n", params_channels(hw_params));
+ printk("buffer bytes: %d\n", params_buffer_bytes(hw_params));
+ printk("period bytes: %d\n", params_period_bytes(hw_params));
+ printk("access: %d\n", params_access(hw_params));
+
+ return -EINVAL;
+
ret = snd_pcm_lib_alloc_vmalloc_buffer(substream,
params_buffer_bytes(hw_params));
if (ret < 0)
Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 16:57, Artem S. Tashkinov wrote: >> On Oct 21, 2012, Daniel Mack wrote: >> >> [Cc: alsa-devel] >> >> On 21.10.2012 14:30, Artem S. Tashkinov wrote: >>> On Oct 21, 2012, Daniel Mack wrote: >>> >>>> A hint at least. How did you enable the audio record exactly? Can you >>>> reproduce this with arecord? >>>> >>>> What chipset are you on? Please provide both "lspci -v" and "lsusb -v" >>>> dumps. As I said, I fail to reproduce that issue on any of my machines. >>> >>> All other applications can read from the USB audio without problems, it's >>> just something in the way Adobe Flash polls my audio input which causes >>> a crash. >>> >>> Just video capture (without audio) works just fine in Adobe Flash. >> >> Ok, so that pretty much rules out the host controller. I just wonder why >> I still don't see it here, and I haven't heard of any such problem from >> anyone else. >> >> Some more questions: >> >> - Which version of Flash are you running? > > Google Chrome has its own version of Adobe Flash: > > Name: Shockwave Flash > Description: Shockwave Flash 11.4 r31 > Version: 11.4.31.110 So that's the same that I'm using. >> - Does this also happen with Firefox? > > No, Adobe Flash in Firefox is an older version (Shockwave Flash 11.1 r102), > it shows > just two input devices instead of three which the newer Flash players sees. > > * HDA Intel PCH > * USB Device 0x46d:0x81d And that works, I assume? Does the second choice in the newer Flash version work maybe? >> - Does flash access the device directly or via PulseAudio? > > PA is not installed on my computer, so Flash accesses it directly via ALSA > calls. Ok, Same here. >> - Could you please apply the attached patch and see what it spits out to >> dmesg once Flash opens the device? It returns -EINVAL in the hw_params >> callback to prevent the actual streaming. On my machine with Flash >> 11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane. >> Or does your machine still crash before anything is written to the logs? > > I will try it a bit later. Yes, we need to trace the call chain and see at which point the trouble starts. What could help is tracing the google-chrome binary with strace maybe. At least we would see the ioctl command sequence, if the log file survives the crash. As the usb list is still in Cc: - Artem's lcpci dump shows that his machine features XHCI controllers. Can anyone think of a relation to this problem? And Artem, is there any way you boot your system on an older machine that only has EHCI ports? Thinking about it, I wonder whether the freeze in VBox and the crashes on native hardware have the same root cause. In that case, would it be possible to share that VBox image? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/5] rtc: omap: dt support
On 19.10.2012 11:59, Afzal Mohammed wrote:
> enhance rtc-omap driver with DT capability
>
> Signed-off-by: Afzal Mohammed
> Acked-by: Sekhar Nori
> ---
>
> v4:
> Proper devicetree documentation
>
> v2:
> Use compatible as ti,da830-rtc instead of ti,am1808-rtc
>
> Documentation/devicetree/bindings/rtc/rtc-omap.txt | 17 +
> drivers/rtc/rtc-omap.c | 18 ++
> 2 files changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-omap.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> new file mode 100644
> index 000..b47aa41
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -0,0 +1,17 @@
> +TI Real Time Clock
> +
> +Required properties:
> +- compatible: "ti,da830-rtc"
> +- reg: Address range of rtc register set
> +- interrupts: rtc timer, alarm interrupts in order
> +- interrupt-parent: phandle for the interrupt controller
> +
> +Example:
> +
> +rtc@1c23000 {
> + compatible = "ti,da830-rtc";
> + reg = <0x23000 0x1000>;
> + interrupts = <19
> + 19>;
> + interrupt-parent = <&intc>;
> +};
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index d948426..dff9ff4 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -20,6 +20,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -298,6 +300,8 @@ static struct rtc_class_ops omap_rtc_ops = {
> static int omap_rtc_alarm;
> static int omap_rtc_timer;
>
> +#define OMAP_RTC_DATA_DA830_IDX 1
> +
> static struct platform_device_id omap_rtc_devtype[] = {
> {
> .name = DRIVER_NAME,
> @@ -309,12 +313,25 @@ static struct platform_device_id omap_rtc_devtype[] = {
> };
> MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
>
> +static const struct of_device_id omap_rtc_of_match[] = {
> + { .compatible = "ti,da830-rtc",
> + .data = &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
Wouldn't it make sense to list all the compatible models here? The
advantage of a compatible list is that we can name the models
explicitly, or maybe at least "davinci-rtc". Is there any reason for
this particular name?
Daniel
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
> +
> static int __init omap_rtc_probe(struct platform_device *pdev)
> {
> struct resource *res, *mem;
> struct rtc_device *rtc;
> u8 reg, new_ctrl;
> const struct platform_device_id *id_entry;
> + const struct of_device_id *of_id;
> +
> + of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
> + if (of_id)
> + pdev->id_entry = of_id->data;
>
> omap_rtc_timer = platform_get_irq(pdev, 0);
> if (omap_rtc_timer <= 0) {
> @@ -510,6 +527,7 @@ static struct platform_driver omap_rtc_driver = {
> .driver = {
> .name = DRIVER_NAME,
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(omap_rtc_of_match),
> },
> .id_table = omap_rtc_devtype,
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 21:49, Artem S. Tashkinov wrote: >> >> On Oct 21, 2012, Borislav Petkov wrote: >> >> On Sun, Oct 21, 2012 at 11:59:36AM +, Artem S. Tashkinov wrote: >>> http://imageshack.us/a/img685/9452/panicz.jpg >>> >>> list_del corruption. prev->next should be ... but was ... >> >> Btw, this is one of the debug options I told you to enable. >> >>> I cannot show you more as I have no serial console to use :( and the kernel >>> doesn't have enough time to push error messages to rsyslog and fsync >>> /var/log/messages >> >> I already told you how to catch that oops: boot with "pause_on_oops=600" >> on the kernel command line and photograph the screen when the first oops >> happens. This'll show us where the problem begins. > > This option didn't have any effect, or maybe it's because it's such a serious > crash > the kernel has no time to actually print an ooops/panic message. > > dmesg messages up to a crash can be seen here: > https://bugzilla.kernel.org/attachment.cgi?id=84221 Nice. Could you do that again with the patch applied I sent yo some hours ago? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 22:43, Artem S. Tashkinov wrote: >> Nice. Could you do that again with the patch applied I sent yo some >> hours ago? > > That patch was of no help - the system has crashed and I couldn't spot > relevant > messages. > > I've no idea what it means. The sequence of driver callbacks issued on a stream start is .open() .hw_params() .prepare() .trigger() If the ALSA part really causes this issue, the bad things happen either in any of the driver callback functions or in the core underneath. The patch I sent returns an error from the hw_params callback, and as you still see the problem, that means that the crash happens before any of the USB audio streaming really starts. Could you try and return -EINVAL from snd_usb_capture_open() please? If anyone has a better idea on how to debug this, please chime in. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 22.10.2012 17:17, Alan Stern wrote:
> On Sun, 21 Oct 2012, Artem S. Tashkinov wrote:
>
>> dmesg messages up to a crash can be seen here:
>> https://bugzilla.kernel.org/attachment.cgi?id=84221
>
> The first problem in the log is endpoint list corruption. Here's a
> debugging patch which should provide a little more information.
Maybe add a BUG() after each of these dev_err() so we stop at the first
occurance and also see where we're coming from?
> drivers/usb/core/hcd.c | 36
> 1 file changed, 36 insertions(+)
>
> Index: usb-3.6/drivers/usb/core/hcd.c
> ===
> --- usb-3.6.orig/drivers/usb/core/hcd.c
> +++ usb-3.6/drivers/usb/core/hcd.c
> @@ -1083,6 +1083,8 @@ EXPORT_SYMBOL_GPL(usb_calc_bus_time);
>
> /*-*/
>
> +static bool list_error;
> +
> /**
> * usb_hcd_link_urb_to_ep - add an URB to its endpoint queue
> * @hcd: host controller to which @urb was submitted
> @@ -1126,6 +1128,20 @@ int usb_hcd_link_urb_to_ep(struct usb_hc
>*/
> if (HCD_RH_RUNNING(hcd)) {
> urb->unlinked = 0;
> +
> + {
> + struct list_head *cur = &urb->ep->urb_list;
> + struct list_head *prev = cur->prev;
> +
> + if (prev->next != cur && !list_error) {
> + list_error = true;
> + dev_err(&urb->dev->dev,
> + "ep %x list add corruption: %p %p %p\n",
> + urb->ep->desc.bEndpointAddress,
> + cur, prev, prev->next);
> + }
> + }
> +
> list_add_tail(&urb->urb_list, &urb->ep->urb_list);
> } else {
> rc = -ESHUTDOWN;
> @@ -1193,6 +1209,26 @@ void usb_hcd_unlink_urb_from_ep(struct u
> {
> /* clear all state linking urb to this dev (and hcd) */
> spin_lock(&hcd_urb_list_lock);
> + {
> + struct list_head *cur = &urb->urb_list;
> + struct list_head *prev = cur->prev;
> + struct list_head *next = cur->next;
> +
> + if (prev->next != cur && !list_error) {
> + list_error = true;
> + dev_err(&urb->dev->dev,
> + "ep %x list del corruption prev: %p %p %p\n",
> + urb->ep->desc.bEndpointAddress,
> + cur, prev, prev->next);
> + }
> + if (next->prev != cur && !list_error) {
> + list_error = true;
> + dev_err(&urb->dev->dev,
> + "ep %x list del corruption next: %p %p %p\n",
> + urb->ep->desc.bEndpointAddress,
> + cur, next, next->prev);
> + }
> + }
> list_del_init(&urb->urb_list);
> spin_unlock(&hcd_urb_list_lock);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] w1:masters/w1-gpio.c: fix error using "__devinit" and "__devexit"
On 11.12.2012 13:08, Cong Ding wrote:
> w1:masters/w1-gpio.c: fix error using "__devinit" and "__devexit"
>
> we should use "__devinit" to mark the probe function, "__devexit" to
> mark the remove function, and "__devexit_p" to mark the pointer to the
> remove function.
Nope. CONFIG_HOTPLUG is going away as an option, so you should rather
kill all the __dev* annotations.
Thanks,
Daniel
> the error was found by the following compilation warning:
> WARNING: drivers/w1/masters/w1-gpio.o(.data+0x0): Section mismatch in
> reference from the variable w1_gpio_driver to the function
> .init.text:w1_gpio_probe()
> The variable w1_gpio_driver references
> the function __init w1_gpio_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> Signed-off-by: Cong Ding
> ---
> drivers/w1/masters/w1-gpio.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
> index 85b363a..33edc3b 100644
> --- a/drivers/w1/masters/w1-gpio.c
> +++ b/drivers/w1/masters/w1-gpio.c
> @@ -72,7 +72,7 @@ static int w1_gpio_probe_dt(struct platform_device *pdev)
> return 0;
> }
>
> -static int __init w1_gpio_probe(struct platform_device *pdev)
> +static int __devinit w1_gpio_probe(struct platform_device *pdev)
> {
> struct w1_bus_master *master;
> struct w1_gpio_platform_data *pdata;
> @@ -158,7 +158,7 @@ static int __init w1_gpio_probe(struct platform_device
> *pdev)
> return err;
> }
>
> -static int __exit w1_gpio_remove(struct platform_device *pdev)
> +static int __devexit w1_gpio_remove(struct platform_device *pdev)
> {
> struct w1_bus_master *master = platform_get_drvdata(pdev);
> struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
> @@ -210,7 +210,7 @@ static struct platform_driver w1_gpio_driver = {
> .of_match_table = of_match_ptr(w1_gpio_dt_ids),
> },
> .probe = w1_gpio_probe,
> - .remove = __exit_p(w1_gpio_remove),
> + .remove = __devexit_p(w1_gpio_remove),
> .suspend = w1_gpio_suspend,
> .resume = w1_gpio_resume,
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 07.11.2012 20:19, Takashi Iwai wrote:
> At Wed, 7 Nov 2012 12:34:43 -0500 (EST),
> Alan Stern wrote:
>>
>> On Mon, 5 Nov 2012, Christof Meerwald wrote:
>>
>>> BTW, I have been able to reproduce the problem on a completely
>>> different machine (also running Ubuntu 12.10, but different hardware).
>>> The important thing appears to be that the USB audio device is
>>> connected via a USB 2.0 hub (and then using the test code posted in
>>> http://pastebin.com/aHGe1S1X specifying the audio device as
>>> "plughw:Set" (or whatever it's called) seems to trigger the freeze).
>>
>> Christof: Thank you for that reference, it was a big help. After
>> crashing my system many times I have tracked the problem, at least in
>> part. The patch below should prevent your system from freezing.
>>
>>
>> Takashi: It turns out the the problem is triggered when the audio
>> subsystem calls snd_usb_endpoint_stop() with wait == 0 and then calls
>> snd_usb_endpoint_start(). Since the driver doesn't wait for the
>> outstanding URBs to finish, it tries to submit them again while they
>> are still active.
>>
>> Normally the USB core would realize this and fail the submission, but a
>> bug in ehci-hcd prevented this from happening. (That bug is what the
>> patch below fixes.) The URB gets added to the active list twice,
>> resulting in list corruption and an oops in interrupt context, which
>> freezes the system.
>>
>> The user program that triggers the problem basically looks like this:
>>
>> snd_pcm_prepare(rec_pcm);
>> snd_pcm_start(rec_pcm);
>> snd_pcm_drop(rec_pcm);
>>
>> snd_pcm_prepare(rec_pcm);
>> snd_pcm_start(rec_pcm);
>>
>> The snd_pcm_drop call unlinks the URBs but does not wait for them to
>> finish. Then the second snd_pcm_start call submits the URBs before
>> they have finished.
Thanks for investigating on this and to everyone who so quickyl tested
the provided patch. Seems like we got the right idea where the problem
really is.
However, the proposed patch seems wrong to me (see below).
>> What is the right solution for this problem?
>
> How about the patch below? (It's for 3.6, and won't be applied cleanly
> to 3.7, but easy to adapt.)
>
>
> Takashi
>
> ---
> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> index d9de667..38830e2 100644
> --- a/sound/usb/endpoint.c
> +++ b/sound/usb/endpoint.c
> @@ -35,6 +35,7 @@
>
> #define EP_FLAG_ACTIVATED0
> #define EP_FLAG_RUNNING 1
> +#define EP_FLAG_STOPPING 2
>
> /*
> * snd_usb_endpoint is a model that abstracts everything related to an
> @@ -502,10 +503,19 @@ static int wait_clear_urbs(struct snd_usb_endpoint *ep)
> if (alive)
> snd_printk(KERN_ERR "timeout: still %d active urbs on EP #%x\n",
> alive, ep->ep_num);
> + clear_bit(EP_FLAG_STOPPING, &ep->flags);
>
> return 0;
> }
>
> +/* wait until urbs are really dropped */
> +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep)
> +{
> + if (test_bit(EP_FLAG_STOPPING, &ep->flags))
> + wait_clear_urbs(ep);
> +}
> +
> +
> /*
> * unlink active urbs.
> */
> @@ -913,6 +923,8 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
>
> if (wait)
> wait_clear_urbs(ep);
> + else
> + set_bit(EP_FLAG_STOPPING, &ep->flags);
> }
> }
>
> diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
> index cbbbdf2..c1540a4 100644
> --- a/sound/usb/endpoint.h
> +++ b/sound/usb/endpoint.h
> @@ -16,6 +16,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
> void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
> int force, int can_sleep, int wait);
> +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep);
> int snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
> int snd_usb_endpoint_deactivate(struct snd_usb_endpoint *ep);
> void snd_usb_endpoint_free(struct list_head *head);
> diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> index f782ce1..aee3ab0 100644
> --- a/sound/usb/pcm.c
> +++ b/sound/usb/pcm.c
> @@ -546,6 +546,11 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream
> *substream)
> if (snd_BUG_ON(!subs->data_endpoint))
> return -EIO;
>
> + if (subs->sync_endpoint)
> + snd_usb_endpoint_sync_stop(subs->sync_endpoint);
> + if (subs->data_endpoint)
> + snd_usb_endpoint_sync_stop(subs->data_endpoint);
We can't simply stop both endpoints in the prepare callback. The essence
of the new reference-counting system is that we can use endpoints from
multiple contexts, and the logic inside endpoint.c will care about when
to start up and take down the urbs. The idea here is that endoints can
be run for many purposes, and the new implementation that was added
allows capture endpoints to run purely as timing reference fo
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 08.11.2012 07:43, Takashi Iwai wrote:
> At Thu, 08 Nov 2012 01:42:59 +0100,
> Daniel Mack wrote:
>>
>> On 07.11.2012 20:19, Takashi Iwai wrote:
>>> At Wed, 7 Nov 2012 12:34:43 -0500 (EST),
>>> Alan Stern wrote:
>>>>
>>>> On Mon, 5 Nov 2012, Christof Meerwald wrote:
>>>>
>>>>> BTW, I have been able to reproduce the problem on a completely
>>>>> different machine (also running Ubuntu 12.10, but different hardware).
>>>>> The important thing appears to be that the USB audio device is
>>>>> connected via a USB 2.0 hub (and then using the test code posted in
>>>>> http://pastebin.com/aHGe1S1X specifying the audio device as
>>>>> "plughw:Set" (or whatever it's called) seems to trigger the freeze).
>>>>
>>>> Christof: Thank you for that reference, it was a big help. After
>>>> crashing my system many times I have tracked the problem, at least in
>>>> part. The patch below should prevent your system from freezing.
>>>>
>>>>
>>>> Takashi: It turns out the the problem is triggered when the audio
>>>> subsystem calls snd_usb_endpoint_stop() with wait == 0 and then calls
>>>> snd_usb_endpoint_start(). Since the driver doesn't wait for the
>>>> outstanding URBs to finish, it tries to submit them again while they
>>>> are still active.
>>>>
>>>> Normally the USB core would realize this and fail the submission, but a
>>>> bug in ehci-hcd prevented this from happening. (That bug is what the
>>>> patch below fixes.) The URB gets added to the active list twice,
>>>> resulting in list corruption and an oops in interrupt context, which
>>>> freezes the system.
>>>>
>>>> The user program that triggers the problem basically looks like this:
>>>>
>>>> snd_pcm_prepare(rec_pcm);
>>>> snd_pcm_start(rec_pcm);
>>>> snd_pcm_drop(rec_pcm);
>>>>
>>>> snd_pcm_prepare(rec_pcm);
>>>> snd_pcm_start(rec_pcm);
>>>>
>>>> The snd_pcm_drop call unlinks the URBs but does not wait for them to
>>>> finish. Then the second snd_pcm_start call submits the URBs before
>>>> they have finished.
>>
>>
>> Thanks for investigating on this and to everyone who so quickyl tested
>> the provided patch. Seems like we got the right idea where the problem
>> really is.
>>
>> However, the proposed patch seems wrong to me (see below).
>>
>>>> What is the right solution for this problem?
>>>
>>> How about the patch below? (It's for 3.6, and won't be applied cleanly
>>> to 3.7, but easy to adapt.)
>>>
>>>
>>> Takashi
>>>
>>> ---
>>> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
>>> index d9de667..38830e2 100644
>>> --- a/sound/usb/endpoint.c
>>> +++ b/sound/usb/endpoint.c
>>> @@ -35,6 +35,7 @@
>>>
>>> #define EP_FLAG_ACTIVATED 0
>>> #define EP_FLAG_RUNNING1
>>> +#define EP_FLAG_STOPPING 2
>>>
>>> /*
>>> * snd_usb_endpoint is a model that abstracts everything related to an
>>> @@ -502,10 +503,19 @@ static int wait_clear_urbs(struct snd_usb_endpoint
>>> *ep)
>>> if (alive)
>>> snd_printk(KERN_ERR "timeout: still %d active urbs on EP #%x\n",
>>> alive, ep->ep_num);
>>> + clear_bit(EP_FLAG_STOPPING, &ep->flags);
>>>
>>> return 0;
>>> }
>>>
>>> +/* wait until urbs are really dropped */
>>> +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep)
>>> +{
>>> + if (test_bit(EP_FLAG_STOPPING, &ep->flags))
>>> + wait_clear_urbs(ep);
>>> +}
>>> +
>>> +
>>> /*
>>> * unlink active urbs.
>>> */
>>> @@ -913,6 +923,8 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
>>>
>>> if (wait)
>>> wait_clear_urbs(ep);
>>> + else
>>> + set_bit(EP_FLAG_STOPPING, &ep->flags);
>>> }
>>> }
>>>
>>> diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
>>> index cbbbdf2..c1540a4 100644
>>> --- a/sound/usb/endpoint.h
>>> +++ b/sound/usb/endpoint.h
>>> @@ -16,6 +16
Re: [PATCH 1/2] ALSA: ASoc: spdif_transciever: Add DT support
Hi Michal,
On 19.04.2013 15:38, Michal Bachraty wrote:
> Add devicetree support for this dummy audio soc driver.
I think Mark wants to see only "ASoC:" in the patch subjects now.
>
> Signed-off-by: Michal Bachraty
> ---
> sound/soc/codecs/spdif_transciever.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/sound/soc/codecs/spdif_transciever.c
> b/sound/soc/codecs/spdif_transciever.c
> index 112a49d..4c8c295 100644
> --- a/sound/soc/codecs/spdif_transciever.c
> +++ b/sound/soc/codecs/spdif_transciever.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #define DRV_NAME "spdif-dit"
>
> @@ -52,12 +53,21 @@ static int spdif_dit_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id spdif_dit_dt_ids[] = {
> + { .compatible = DRV_NAME, },
I think this needs a "linux," prefix. Just put the whole string here.
Same goes for the patch against the spdif_receiver driver.
Thanks,
Daniel
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, spdif_dits_dt_ids);
> +#endif
> +
> static struct platform_driver spdif_dit_driver = {
> .probe = spdif_dit_probe,
> .remove = spdif_dit_remove,
> .driver = {
> .name = DRV_NAME,
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(spdif_dit_dt_ids),
> },
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 2/2] ALSA: ASoc: davinci-mcasp: Add Support BCLK-to-LRCLK ratio for TDM modes
On 19.04.2013 15:28, Michal Bachraty wrote:
> For TDM mode, BCLK-to-LCLK ratio is computed as (tdm_slots) x (word_length).
> I2S mode is only subset of TDM mode with specific tdm_slots = 2 channels.
> Also bclk_lrclk_ratio can be greater than 255, therefore u16 need to be used.
>
> Signed-off-by: Michal Bachraty
Acked-by: Daniel Mack
> ---
> sound/soc/davinci/davinci-mcasp.c |7 ---
> sound/soc/davinci/davinci-mcasp.h |2 +-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/davinci/davinci-mcasp.c
> b/sound/soc/davinci/davinci-mcasp.c
> index 63633e9..d54e0d9 100644
> --- a/sound/soc/davinci/davinci-mcasp.c
> +++ b/sound/soc/davinci/davinci-mcasp.c
> @@ -636,11 +636,12 @@ static int davinci_config_channel_size(struct
> davinci_audio_dev *dev,
>* callback, take it into account here. That allows us to for example
>* send 32 bits per channel to the codec, while only 16 of them carry
>* audio payload.
> - * The clock ratio is given for a full period of data (both left and
> - * right channels), so it has to be divided by 2.
> + * The clock ratio is given for a full period of data (for I2S format
> + * both left and right channels), so it has to be divided by number of
> + * tdm-slots (for I2S - divided by 2).
>*/
> if (dev->bclk_lrclk_ratio)
> - word_length = dev->bclk_lrclk_ratio / 2;
> + word_length = dev->bclk_lrclk_ratio / dev->tdm_slots;
>
> /* mapping of the XSSZ bit-field as described in the datasheet */
> fmt = (word_length >> 1) - 1;
> diff --git a/sound/soc/davinci/davinci-mcasp.h
> b/sound/soc/davinci/davinci-mcasp.h
> index 0edd3b5..a9ac0c1 100644
> --- a/sound/soc/davinci/davinci-mcasp.h
> +++ b/sound/soc/davinci/davinci-mcasp.h
> @@ -38,7 +38,7 @@ struct davinci_audio_dev {
> u8 num_serializer;
> u8 *serial_dir;
> u8 version;
> - u8 bclk_lrclk_ratio;
> + u16 bclk_lrclk_ratio;
>
> /* McASP FIFO related */
> u8 txnumevt;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] ALSA: ASoC davinci-pcm, davinci-mcasp Clean up active_serializers
On 19.04.2013 15:28, Michal Bachraty wrote:
> As pointed of by Vaibhav, commit message: "ASoC: davinci-mcasp: Add support
> for multichannel playback"
> number of active serializers can be hidden into fifo_level variable, which is
> set in davimci-mcasp.
You need to reformat the commit log so it does not exceed 80 characters
per line. Also, as you're on it, you can omit "ALSA" in the subject and
add two colons (after 'ASoC' and 'mcasp') for better readability.
Other than that, looks good to me. I've been using that patch for a
while now and it works fine for me.
Thanks,
Daniel
>
> Signed-off-by: Michal Bachraty
> ---
> sound/soc/davinci/davinci-mcasp.c |8 +---
> sound/soc/davinci/davinci-pcm.c | 11 +--
> sound/soc/davinci/davinci-pcm.h |1 -
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/sound/soc/davinci/davinci-mcasp.c
> b/sound/soc/davinci/davinci-mcasp.c
> index 8a9c0ee..63633e9 100644
> --- a/sound/soc/davinci/davinci-mcasp.c
> +++ b/sound/soc/davinci/davinci-mcasp.c
> @@ -834,17 +834,20 @@ static int davinci_mcasp_hw_params(struct
> snd_pcm_substream *substream,
> int word_length;
> u8 fifo_level;
> u8 slots = dev->tdm_slots;
> + u8 active_serializers;
> int channels;
> struct snd_interval *pcm_channels = hw_param_interval(params,
> SNDRV_PCM_HW_PARAM_CHANNELS);
> channels = pcm_channels->min;
>
> + active_serializers = (channels + slots - 1) / slots;
> +
> if (davinci_hw_common_param(dev, substream->stream, channels) ==
> -EINVAL)
> return -EINVAL;
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> - fifo_level = dev->txnumevt;
> + fifo_level = dev->txnumevt * active_serializers;
> else
> - fifo_level = dev->rxnumevt;
> + fifo_level = dev->rxnumevt * active_serializers;
>
> if (dev->op_mode == DAVINCI_MCASP_DIT_MODE)
> davinci_hw_dit_param(dev);
> @@ -889,7 +892,6 @@ static int davinci_mcasp_hw_params(struct
> snd_pcm_substream *substream,
> dma_params->acnt = dma_params->data_type;
>
> dma_params->fifo_level = fifo_level;
> - dma_params->active_serializers = (channels + slots - 1) / slots;
> davinci_config_channel_size(dev, word_length);
>
> return 0;
> diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
> index 0161579..8460edc 100644
> --- a/sound/soc/davinci/davinci-pcm.c
> +++ b/sound/soc/davinci/davinci-pcm.c
> @@ -182,7 +182,6 @@ static void davinci_pcm_enqueue_dma(struct
> snd_pcm_substream *substream)
> unsigned short acnt;
> unsigned int count;
> unsigned int fifo_level;
> - unsigned char serializers = prtd->params->active_serializers;
>
> period_size = snd_pcm_lib_period_bytes(substream);
> dma_offset = prtd->period * period_size;
> @@ -196,14 +195,14 @@ static void davinci_pcm_enqueue_dma(struct
> snd_pcm_substream *substream)
> data_type = prtd->params->data_type;
> count = period_size / data_type;
> if (fifo_level)
> - count /= fifo_level * serializers;
> + count /= fifo_level;
>
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> src = dma_pos;
> dst = prtd->params->dma_addr;
> src_bidx = data_type;
> dst_bidx = 4;
> - src_cidx = data_type * fifo_level * serializers;
> + src_cidx = data_type * fifo_level;
> dst_cidx = 0;
> } else {
> src = prtd->params->dma_addr;
> @@ -211,7 +210,7 @@ static void davinci_pcm_enqueue_dma(struct
> snd_pcm_substream *substream)
> src_bidx = 0;
> dst_bidx = data_type;
> src_cidx = 0;
> - dst_cidx = data_type * fifo_level * serializers;
> + dst_cidx = data_type * fifo_level;
> }
>
> acnt = prtd->params->acnt;
> @@ -226,8 +225,8 @@ static void davinci_pcm_enqueue_dma(struct
> snd_pcm_substream *substream)
> ASYNC);
> else
> edma_set_transfer_params(prtd->asp_link[0], acnt,
> - fifo_level * serializers,
> - count, fifo_level * serializers,
> + fifo_level,
> + count, fifo_level,
> ABSYNC);
> }
>
> diff --git a/sound/soc/davinci/davinci-pcm.h b/sound/soc/davinci/davinci-pcm.h
> index 0d84d32..fbb710c 100644
> --- a/sound/soc/davinci/davinci-pcm.h
> +++ b/sound/soc/davinci/davinci-pcm.h
> @@ -27,7 +27,6 @@ struct davinci_pcm_dma_params {
> unsigned char data_type;/* xfer data type */
> unsigned char convert_mono_stereo;
> unsigned int fifo
[PATCH] regmap: cache: bail in regmap_async_complete() for bus-less maps
Commit f8bd822cb ("regmap: cache: Factor out block sync") made
regcache_rbtree_sync() call regmap_async_complete(), which in turn does
not check for map->bus before dereferencing it.
This causes a NULL pointer dereference on bus-less maps.
Signed-off-by: Daniel Mack
Cc: sta...@vger.kernel.org [v3.10 only]
---
drivers/base/regmap/regmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index a941dcf..d0c81d1 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1717,7 +1717,7 @@ int regmap_async_complete(struct regmap *map)
int ret;
/* Nothing to do with no async support */
- if (!map->bus->async_write)
+ if (!map->bus || !map->bus->async_write)
return 0;
trace_regmap_async_complete_start(map->dev);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: Add PCM1681 codec driver.
Hi Marek,
On 26.06.2013 15:05, Marek Belisko wrote:
> PCM1681 can be controlled via I2C, SPI or in bootstrap mode. This code add
> support only for I2C mode.
>
> Signed-off-by: Marek Belisko
> ---
> .../devicetree/bindings/sound/ti,pcm1681.txt | 15 +
> sound/soc/codecs/Kconfig |4 +
> sound/soc/codecs/Makefile |2 +
> sound/soc/codecs/pcm1681.c | 328
>
> 4 files changed, 349 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/ti,pcm1681.txt
> create mode 100644 sound/soc/codecs/pcm1681.c
>
> diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt
> b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt
> new file mode 100644
> index 000..4df1718
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt
> @@ -0,0 +1,15 @@
> +Texas Instruments PCM1681 8-channel PWM Processor
> +
> +Required properties:
> +
> + - compatible: Should contain "ti,pcm1681".
> + - reg: The i2c address. Should contain <0x4c>.
> +
> +Examples:
> +
> + i2c_bus {
> + pcm1681@4c {
> + compatible = "ti,pcm1681";
> + reg = <0x4c>;
> + };
> + };
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index badb6fb..e2daf82 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -54,6 +54,7 @@ config SND_SOC_ALL_CODECS
> select SND_SOC_MC13783 if MFD_MC13XXX
> select SND_SOC_ML26124 if I2C
> select SND_SOC_HDMI_CODEC
> + select SND_SOC_PCM1681 if I2C
> select SND_SOC_PCM3008
> select SND_SOC_RT5631 if I2C
> select SND_SOC_RT5640 if I2C
> @@ -292,6 +293,9 @@ config SND_SOC_MAX9850
> config SND_SOC_HDMI_CODEC
> tristate
>
> +config SND_SOC_PCM1681
> + tristate
> +
> config SND_SOC_PCM3008
> tristate
>
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index 70fd806..4a068d2 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -42,6 +42,7 @@ snd-soc-max9850-objs := max9850.o
> snd-soc-mc13783-objs := mc13783.o
> snd-soc-ml26124-objs := ml26124.o
> snd-soc-hdmi-codec-objs := hdmi.o
> +snd-soc-pcm1681-objs := pcm1681.o
> snd-soc-pcm3008-objs := pcm3008.o
> snd-soc-rt5631-objs := rt5631.o
> snd-soc-rt5640-objs := rt5640.o
> @@ -171,6 +172,7 @@ obj-$(CONFIG_SND_SOC_MAX9850) += snd-soc-max9850.o
> obj-$(CONFIG_SND_SOC_MC13783)+= snd-soc-mc13783.o
> obj-$(CONFIG_SND_SOC_ML26124)+= snd-soc-ml26124.o
> obj-$(CONFIG_SND_SOC_HDMI_CODEC) += snd-soc-hdmi-codec.o
> +obj-$(CONFIG_SND_SOC_PCM1681)+= snd-soc-pcm1681.o
> obj-$(CONFIG_SND_SOC_PCM3008)+= snd-soc-pcm3008.o
> obj-$(CONFIG_SND_SOC_RT5631) += snd-soc-rt5631.o
> obj-$(CONFIG_SND_SOC_RT5640) += snd-soc-rt5640.o
> diff --git a/sound/soc/codecs/pcm1681.c b/sound/soc/codecs/pcm1681.c
> new file mode 100644
> index 000..6122fd1
> --- /dev/null
> +++ b/sound/soc/codecs/pcm1681.c
> @@ -0,0 +1,328 @@
> +/*
> + * PCM1681 ASoC codec driver
> + *
> + * Copyright (c) StreamUnlimited GmbH 2013
> + * Marek Belisko
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PCM1681_PCM_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
> + SNDRV_PCM_FMTBIT_S24_LE)
> +
> +#define PCM1681_PCM_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 | \
> + SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | \
> + SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | \
> + SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000)
> +
> +#define PCM1681_SOFT_MUTE_ALL0xff
> +#define PCM1681_DEEMPH_RATE_MASK 0x18
> +#define PCM1681_DEEMPH_MASK 0x01
> +
> +#define PCM1681_ATT_CONTROL(X) (X <= 6 ? X : X + 9) /* Attenuation
> level */
> +#define PCM1681_SOFT_MUTE0x07/* Soft mute control register */
> +#define PCM1681_DAC_CONTROL 0x08/* DAC operation control */
> +#define PCM1681_FMT_CONTROL 0x09/* Audio interface data format */
> +#define PCM1681_DEEMPH_CONTROL 0x0a/* De-emphasis control */
> +#define PCM1681_ZERO_DETECT_STATUS 0x0e/* Zero detect status
Re: [PATCH] ASoC: Add PCM1681 codec driver.
On 26.06.2013 15:46, Marek Belisko wrote:
> Hi Daniel,
> On 06/26/2013 03:16 PM, Daniel Mack wrote:
>> Hi Marek,
>>
>> On 26.06.2013 15:05, Marek Belisko wrote:
>>> PCM1681 can be controlled via I2C, SPI or in bootstrap mode. This code add
>>> support only for I2C mode.
>>>
>>> Signed-off-by: Marek Belisko
>>> ---
>>> .../devicetree/bindings/sound/ti,pcm1681.txt | 15 +
>>> sound/soc/codecs/Kconfig |4 +
>>> sound/soc/codecs/Makefile |2 +
>>> sound/soc/codecs/pcm1681.c | 328
>>>
>>> 4 files changed, 349 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/sound/ti,pcm1681.txt
>>> create mode 100644 sound/soc/codecs/pcm1681.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt
>>> b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt
>>> new file mode 100644
>>> index 000..4df1718
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt
>>> @@ -0,0 +1,15 @@
>>> +Texas Instruments PCM1681 8-channel PWM Processor
>>> +
>>> +Required properties:
>>> +
>>> + - compatible: Should contain "ti,pcm1681".
>>> + - reg:The i2c address. Should contain <0x4c>.
>>> +
>>> +Examples:
>>> +
>>> + i2c_bus {
>>> + pcm1681@4c {
>>> + compatible = "ti,pcm1681";
>>> + reg = <0x4c>;
>>> + };
>>> + };
>>> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
>>> index badb6fb..e2daf82 100644
>>> --- a/sound/soc/codecs/Kconfig
>>> +++ b/sound/soc/codecs/Kconfig
>>> @@ -54,6 +54,7 @@ config SND_SOC_ALL_CODECS
>>> select SND_SOC_MC13783 if MFD_MC13XXX
>>> select SND_SOC_ML26124 if I2C
>>> select SND_SOC_HDMI_CODEC
>>> + select SND_SOC_PCM1681 if I2C
>>> select SND_SOC_PCM3008
>>> select SND_SOC_RT5631 if I2C
>>> select SND_SOC_RT5640 if I2C
>>> @@ -292,6 +293,9 @@ config SND_SOC_MAX9850
>>> config SND_SOC_HDMI_CODEC
>>> tristate
>>>
>>> +config SND_SOC_PCM1681
>>> + tristate
>>> +
>>> config SND_SOC_PCM3008
>>> tristate
>>>
>>> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
>>> index 70fd806..4a068d2 100644
>>> --- a/sound/soc/codecs/Makefile
>>> +++ b/sound/soc/codecs/Makefile
>>> @@ -42,6 +42,7 @@ snd-soc-max9850-objs := max9850.o
>>> snd-soc-mc13783-objs := mc13783.o
>>> snd-soc-ml26124-objs := ml26124.o
>>> snd-soc-hdmi-codec-objs := hdmi.o
>>> +snd-soc-pcm1681-objs := pcm1681.o
>>> snd-soc-pcm3008-objs := pcm3008.o
>>> snd-soc-rt5631-objs := rt5631.o
>>> snd-soc-rt5640-objs := rt5640.o
>>> @@ -171,6 +172,7 @@ obj-$(CONFIG_SND_SOC_MAX9850) += snd-soc-max9850.o
>>> obj-$(CONFIG_SND_SOC_MC13783) += snd-soc-mc13783.o
>>> obj-$(CONFIG_SND_SOC_ML26124) += snd-soc-ml26124.o
>>> obj-$(CONFIG_SND_SOC_HDMI_CODEC) += snd-soc-hdmi-codec.o
>>> +obj-$(CONFIG_SND_SOC_PCM1681) += snd-soc-pcm1681.o
>>> obj-$(CONFIG_SND_SOC_PCM3008) += snd-soc-pcm3008.o
>>> obj-$(CONFIG_SND_SOC_RT5631) += snd-soc-rt5631.o
>>> obj-$(CONFIG_SND_SOC_RT5640) += snd-soc-rt5640.o
>>> diff --git a/sound/soc/codecs/pcm1681.c b/sound/soc/codecs/pcm1681.c
>>> new file mode 100644
>>> index 000..6122fd1
>>> --- /dev/null
>>> +++ b/sound/soc/codecs/pcm1681.c
>>> @@ -0,0 +1,328 @@
>>> +/*
>>> + * PCM1681 ASoC codec driver
>>> + *
>>> + * Copyright (c) StreamUnlimited GmbH 2013
>>> + * Marek Belisko
>>> + *
>>> + * 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 Genera
Re: v3.11-rc1 USB regressions
Hi Aaro,
On 16.07.2013 00:56, Aaro Koskinen wrote:
> Hi,
>
> I think USB tree introduced regressions in v3.11-rc1, at least for some
> OMAP devices using legacy boot.
Thanks for checking the tree so early.
> I have only bisected these; I have no
> idea what the real fixes are but the following reverts make Nokia OMAP2+
> boards again usable for kernel development work (they need working USB
> connection for interacting with the device):
>
> 1) USB peripheral mode (g_ether) is broken on Nokia N900, N950 and N9
>(USB_MUSB_OMAP2PLUS). To make it it work, I need to revert three
>commits:
>
> 09fc7d22b024692b2fe8a943b246de1af307132b
> usb: musb: fix incorrect usage of resource pointer
> (Reverting this fixes the g_ether probe failure "couldn't find
>an available UDC")
Can't say much about this one, but I'd like you to only keep this one
reverted and sort out the regressions in the musb core first.
> fe4cb0912f8e737f8e4b8b38b9e692f8062f5423
> usb: musb: gadget: remove hcd initialization
> (Reverting this fixes error "cdc_ether: probe of 4-1:1.0 failed
>with error -110" seen on the host side.)
Which role does your musb-based hardware have in this case, and which
MUSB_* config symbols do you set? You should have USB_MUSB_GADGET.
> 8b125df5b24cfb0ec7fa1971e343cc0badc1827d
> usb: musb: eliminate musb_to_hcd
> (Reverting this fixes compilation error cause by the previous
>revert.)
>
> 2) USB peripheral mode (g_ether) is broken also on Nokia N800 and N810
>(USB_MUSB_TUSB6010). In addition to the above, I need to also revert
>the following:
>
> b7e2e75a8c6062afe1dd88b0b299938e5d36dff8
> usb: gadget: drop unused USB_GADGET_MUSB_HDRC
>
>(This commit is clearly incorrect - code checking for this still
>remain in the tree (see e.g. N8x0 board file), so it's not "unused".)
Good catch, I didn't expect board files to depend on config symbols that
have no effect on the driver itself.
Please check the attached patch and let me know if it helps.
Thanks,
Daniel
>From 5f33d42f2dffb82d22b83a030f14fe2331a935b7 Mon Sep 17 00:00:00 2001
From: Daniel Mack
Date: Tue, 16 Jul 2013 08:19:49 +0200
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
dropped a config symbol that was unused by the musb core, but it turns
out that board support code still had references to it.
As the core now handles both dual role and host-only modes, we can just
pass MUSB_OTG as mode from board files.
Signed-off-by: Daniel Mack
---
arch/arm/mach-omap2/board-n8x0.c | 4
arch/arm/mach-omap2/usb-musb.c | 5 +
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index f6eeb87..827d150 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -122,11 +122,7 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data tusb_data = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
.mode = MUSB_OTG,
-#else
- .mode = MUSB_HOST,
-#endif
.set_power = tusb_set_power,
.min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
.power = 100, /* Max 100 mA VBUS for host mode */
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8c4de27..bc89723 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -38,11 +38,8 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data musb_plat = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
.mode = MUSB_OTG,
-#else
- .mode = MUSB_HOST,
-#endif
+
/* .clock is set dynamically */
.config = &musb_config,
--
1.8.1.4
Re: v3.11-rc1 USB regressions
On 16.07.2013 20:26, Aaro Koskinen wrote: > Hi, > > On Tue, Jul 16, 2013 at 11:22:47AM +0300, Felipe Balbi wrote: >>> On Tue, Jul 16, 2013 at 12:30:00PM +0530, Kishon Vijay Abraham I wrote: >>>> On Tuesday 16 July 2013 12:03 PM, Daniel Mack wrote: >>>>> Hi Aaro, >>>>> >>>>> On 16.07.2013 00:56, Aaro Koskinen wrote: >>>>>> Hi, >>>>>> >>>>>> I think USB tree introduced regressions in v3.11-rc1, at least for some >>>>>> OMAP devices using legacy boot. >>>>> >>>>> Thanks for checking the tree so early. >>>>> >>>>>> I have only bisected these; I have no >>>>>> idea what the real fixes are but the following reverts make Nokia OMAP2+ >>>>>> boards again usable for kernel development work (they need working USB >>>>>> connection for interacting with the device): >>>>>> >>>>>> 1) USB peripheral mode (g_ether) is broken on Nokia N900, N950 and N9 >>>>>>(USB_MUSB_OMAP2PLUS). To make it it work, I need to revert three >>>>>>commits: >>>>>> >>>>>> 09fc7d22b024692b2fe8a943b246de1af307132b >>>>>> usb: musb: fix incorrect usage of resource pointer >>>>>> (Reverting this fixes the g_ether probe failure "couldn't find >>>>>> an available UDC") >>>> >>>> I've posted a patch fixing the issue >>>> http://comments.gmane.org/gmane.linux.usb.general/89541 >>>> There were some comments on it. I'll be posting a new version for it. >>> >>> hmm, n8x0 used tusb6010, so perhaps a similar patch needs to be cooked >>> for that too. Right now, let's to the minimum fix, which is just to >>> increment the array size to 3 and for v3.12 we do the changes that I >>> suggested. >> >> this should solve the problem on n900 and n8x0, it's pretty much >> kishon's original patch, so I guess it deserves his authorship: > > Thanks, and yes it fixes this issue. I tested both N900 and N800, so > feel free to add my Tested-by. Together with my patch I take it? Does your Tested-by apply to this one as well? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-kernel@vger.kernel.org
No functional change, just makes the code shorter.
Signed-off-by: Daniel Mack
---
drivers/regulator/max8660.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index ba3b8af..a5caaa0 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -314,6 +314,7 @@ static int max8660_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
{
struct regulator_dev **rdev;
+ struct device *dev = &client->dev;
struct max8660_platform_data *pdata = client->dev.platform_data;
struct regulator_config config = { };
struct max8660 *max8660;
@@ -321,11 +322,11 @@ static int max8660_probe(struct i2c_client *client,
unsigned int type;
if (pdata->num_subdevs > MAX8660_V_END) {
- dev_err(&client->dev, "Too many regulators found!\n");
+ dev_err(dev, "Too many regulators found!\n");
return -EINVAL;
}
- max8660 = devm_kzalloc(&client->dev, sizeof(struct max8660) +
+ max8660 = devm_kzalloc(dev, sizeof(struct max8660) +
sizeof(struct regulator_dev *) * MAX8660_V_END,
GFP_KERNEL);
if (!max8660)
@@ -384,7 +385,7 @@ static int max8660_probe(struct i2c_client *client,
case MAX8660_V7:
if (type == MAX8661) {
- dev_err(&client->dev, "Regulator not on this
chip!\n");
+ dev_err(dev, "Regulator not on this chip!\n");
goto err_out;
}
@@ -393,7 +394,7 @@ static int max8660_probe(struct i2c_client *client,
break;
default:
- dev_err(&client->dev, "invalid regulator %s\n",
+ dev_err(dev, "invalid regulator %s\n",
pdata->subdevs[i].name);
goto err_out;
}
@@ -404,14 +405,14 @@ static int max8660_probe(struct i2c_client *client,
id = pdata->subdevs[i].id;
- config.dev = &client->dev;
+ config.dev = dev;
config.init_data = pdata->subdevs[i].platform_data;
config.driver_data = max8660;
rdev[i] = regulator_register(&max8660_reg[id], &config);
if (IS_ERR(rdev[i])) {
ret = PTR_ERR(rdev[i]);
- dev_err(&client->dev, "failed to register %s\n",
+ dev_err(dev, "failed to register %s\n",
max8660_reg[id].name);
goto err_unregister;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] regulators: max8660: use i2c_id->driver_data rather than ->name
Introduce an enum and denote the device type via struct i2c_id's
driver_data field rather than comparing strings.
Signed-off-by: Daniel Mack
---
drivers/regulator/max8660.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index d428ef9..ba3b8af 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -305,6 +305,11 @@ static const struct regulator_desc max8660_reg[] = {
},
};
+enum {
+ MAX8660 = 0,
+ MAX8661 = 1,
+};
+
static int max8660_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
{
@@ -313,6 +318,7 @@ static int max8660_probe(struct i2c_client *client,
struct regulator_config config = { };
struct max8660 *max8660;
int boot_on, i, id, ret = -EINVAL;
+ unsigned int type;
if (pdata->num_subdevs > MAX8660_V_END) {
dev_err(&client->dev, "Too many regulators found!\n");
@@ -327,6 +333,7 @@ static int max8660_probe(struct i2c_client *client,
max8660->client = client;
rdev = max8660->rdev;
+ type = i2c_id->driver_data;
if (pdata->en34_is_high) {
/* Simulate always on */
@@ -376,7 +383,7 @@ static int max8660_probe(struct i2c_client *client,
break;
case MAX8660_V7:
- if (!strcmp(i2c_id->name, "max8661")) {
+ if (type == MAX8661) {
dev_err(&client->dev, "Regulator not on this
chip!\n");
goto err_out;
}
@@ -431,8 +438,8 @@ static int max8660_remove(struct i2c_client *client)
}
static const struct i2c_device_id max8660_id[] = {
- { "max8660", 0 },
- { "max8661", 0 },
+ { .name = "max8660", .driver_data = MAX8660 },
+ { .name = "max8661", .driver_data = MAX8661 },
{ }
};
MODULE_DEVICE_TABLE(i2c, max8660_id);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] regulators: max8660: add DT bindings
This patch adds devicetree bindings for max8660, along with some
documentation.
Signed-off-by: Daniel Mack
---
.../devicetree/bindings/regulator/max8660.txt | 47 +
drivers/regulator/max8660.c| 79 +-
include/linux/regulator/max8660.h | 3 +-
3 files changed, 127 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/max8660.txt
diff --git a/Documentation/devicetree/bindings/regulator/max8660.txt
b/Documentation/devicetree/bindings/regulator/max8660.txt
new file mode 100644
index 000..03dd839
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8660.txt
@@ -0,0 +1,47 @@
+Maxim MAX8660 voltage regulator
+
+Required properties:
+- compatible: must be equal to "maxim,max8660"
+- reg: I2C slave address, usually 0x34
+- any required generic properties defined in regulator.txt
+
+Example:
+
+ i2c_master {
+ max8660@34 {
+ compatible = "maxim,max8660";
+ reg = <0x34>;
+
+ regulators {
+ regulator@0 {
+ regulator-compatible= "V3(DCDC)";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <180>;
+ };
+
+ regulator@1 {
+ regulator-compatible= "V4(DCDC)";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <180>;
+ };
+
+ regulator@2 {
+ regulator-compatible= "V5(LDO)";
+ regulator-min-microvolt = <170>;
+ regulator-max-microvolt = <200>;
+ };
+
+ regulator@3 {
+ regulator-compatible= "V6(LDO)";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+
+ regulator@4 {
+ regulator-compatible= "V7(LDO)";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+ };
+ };
+ };
diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index a5caaa0..597d311 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -44,6 +44,9 @@
#include
#include
#include
+#include
+#include
+#include
#define MAX8660_DCDC_MIN_UV 725000
#define MAX8660_DCDC_MAX_UV180
@@ -310,6 +313,62 @@ enum {
MAX8661 = 1,
};
+#ifdef CONFIG_OF
+static const struct of_device_id max8660_dt_ids[] = {
+ { .compatible = "maxim,max8660", .data = (void *) MAX8660 },
+ { .compatible = "maxim,max8661", .data = (void *) MAX8661 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, max8660_dt_ids);
+
+static int max8660_pdata_from_dt(struct device *dev,
+struct max8660_platform_data *pdata)
+{
+ int matched, i;
+ struct device_node *np;
+ struct max8660_subdev_data *sub;
+ struct of_regulator_match rmatch[ARRAY_SIZE(max8660_reg)];
+
+ np = of_find_node_by_name(dev->of_node, "regulators");
+ if (!np) {
+ dev_err(dev, "missing 'regulators' subnode in DT\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(rmatch); i++)
+ rmatch[i].name = max8660_reg[i].name;
+
+ matched = of_regulator_match(dev, np, rmatch, ARRAY_SIZE(rmatch));
+ if (matched <= 0)
+ return matched;
+
+ pdata->subdevs = devm_kzalloc(dev, sizeof(struct max8660_subdev_data) *
+ matched, GFP_KERNEL);
+ if (!pdata->subdevs)
+ return -ENOMEM;
+
+ pdata->num_subdevs = matched;
+
+ sub = pdata->subdevs;
+
+ for (i = 0; i < matched; i++) {
+ sub->id = i;
+ sub->name = rmatch[i].name;
+ sub->platform_data = rmatch[i].init_data;
+ sub->of_node = rmatch[i].of_node;
+ sub++;
+ }
+
+ return 0;
+}
+#else
+static inline int max8660_pdata_from_dt(struct device *dev,
+
[PATCH v2] regulators: max8660: add DT bindings
This patch adds devicetree bindings for max8660, along with some
documentation.
Signed-off-by: Daniel Mack
---
v2:
- fixed documentation
- use of_match_ptr
- only pass the of_nodes internally
.../devicetree/bindings/regulator/max8660.txt | 47 +
drivers/regulator/max8660.c| 81 +-
include/linux/regulator/max8660.h | 2 +-
3 files changed, 128 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/max8660.txt
diff --git a/Documentation/devicetree/bindings/regulator/max8660.txt
b/Documentation/devicetree/bindings/regulator/max8660.txt
new file mode 100644
index 000..8ba994d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8660.txt
@@ -0,0 +1,47 @@
+Maxim MAX8660 voltage regulator
+
+Required properties:
+- compatible: must be one of "maxim,max8660", "maxim,max8661"
+- reg: I2C slave address, usually 0x34
+- any required generic properties defined in regulator.txt
+
+Example:
+
+ i2c_master {
+ max8660@34 {
+ compatible = "maxim,max8660";
+ reg = <0x34>;
+
+ regulators {
+ regulator@0 {
+ regulator-compatible= "V3(DCDC)";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <180>;
+ };
+
+ regulator@1 {
+ regulator-compatible= "V4(DCDC)";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <180>;
+ };
+
+ regulator@2 {
+ regulator-compatible= "V5(LDO)";
+ regulator-min-microvolt = <170>;
+ regulator-max-microvolt = <200>;
+ };
+
+ regulator@3 {
+ regulator-compatible= "V6(LDO)";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+
+ regulator@4 {
+ regulator-compatible= "V7(LDO)";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+ };
+ };
+ };
diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index a5caaa0..e67a863 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -44,6 +44,9 @@
#include
#include
#include
+#include
+#include
+#include
#define MAX8660_DCDC_MIN_UV 725000
#define MAX8660_DCDC_MAX_UV180
@@ -310,6 +313,62 @@ enum {
MAX8661 = 1,
};
+#ifdef CONFIG_OF
+static const struct of_device_id max8660_dt_ids[] = {
+ { .compatible = "maxim,max8660", .data = (void *) MAX8660 },
+ { .compatible = "maxim,max8661", .data = (void *) MAX8661 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, max8660_dt_ids);
+
+static int max8660_pdata_from_dt(struct device *dev,
+struct device_node **of_node,
+struct max8660_platform_data *pdata)
+{
+ int matched, i;
+ struct device_node *np;
+ struct max8660_subdev_data *sub;
+ struct of_regulator_match rmatch[ARRAY_SIZE(max8660_reg)];
+
+ np = of_find_node_by_name(dev->of_node, "regulators");
+ if (!np) {
+ dev_err(dev, "missing 'regulators' subnode in DT\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(rmatch); i++)
+ rmatch[i].name = max8660_reg[i].name;
+
+ matched = of_regulator_match(dev, np, rmatch, ARRAY_SIZE(rmatch));
+ if (matched <= 0)
+ return matched;
+
+ pdata->subdevs = devm_kzalloc(dev, sizeof(struct max8660_subdev_data) *
+ matched, GFP_KERNEL);
+ if (!pdata->subdevs)
+ return -ENOMEM;
+
+ pdata->num_subdevs = matched;
+ sub = pdata->subdevs;
+
+ for (i = 0; i < matched; i++) {
+ sub->id = i;
+ sub->name = rmatch[i].name;
+ sub->platform_data = rmatch[i].init_data;
+
[PATCH v3] regulators: max8660: add DT bindings
This patch adds devicetree bindings for max8660, along with some
documentation.
Signed-off-by: Daniel Mack
---
v3:
- fix non-dt function stub
v2:
- fixed documentation
- use of_match_ptr
- only pass the of_nodes internally
.../devicetree/bindings/regulator/max8660.txt | 47 +
drivers/regulator/max8660.c| 82 +-
include/linux/regulator/max8660.h | 2 +-
3 files changed, 129 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/max8660.txt
diff --git a/Documentation/devicetree/bindings/regulator/max8660.txt
b/Documentation/devicetree/bindings/regulator/max8660.txt
new file mode 100644
index 000..8ba994d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8660.txt
@@ -0,0 +1,47 @@
+Maxim MAX8660 voltage regulator
+
+Required properties:
+- compatible: must be one of "maxim,max8660", "maxim,max8661"
+- reg: I2C slave address, usually 0x34
+- any required generic properties defined in regulator.txt
+
+Example:
+
+ i2c_master {
+ max8660@34 {
+ compatible = "maxim,max8660";
+ reg = <0x34>;
+
+ regulators {
+ regulator@0 {
+ regulator-compatible= "V3(DCDC)";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <180>;
+ };
+
+ regulator@1 {
+ regulator-compatible= "V4(DCDC)";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <180>;
+ };
+
+ regulator@2 {
+ regulator-compatible= "V5(LDO)";
+ regulator-min-microvolt = <170>;
+ regulator-max-microvolt = <200>;
+ };
+
+ regulator@3 {
+ regulator-compatible= "V6(LDO)";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+
+ regulator@4 {
+ regulator-compatible= "V7(LDO)";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+ };
+ };
+ };
diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index a5caaa0..7e6177e 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -44,6 +44,9 @@
#include
#include
#include
+#include
+#include
+#include
#define MAX8660_DCDC_MIN_UV 725000
#define MAX8660_DCDC_MAX_UV180
@@ -310,6 +313,63 @@ enum {
MAX8661 = 1,
};
+#ifdef CONFIG_OF
+static const struct of_device_id max8660_dt_ids[] = {
+ { .compatible = "maxim,max8660", .data = (void *) MAX8660 },
+ { .compatible = "maxim,max8661", .data = (void *) MAX8661 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, max8660_dt_ids);
+
+static int max8660_pdata_from_dt(struct device *dev,
+struct device_node **of_node,
+struct max8660_platform_data *pdata)
+{
+ int matched, i;
+ struct device_node *np;
+ struct max8660_subdev_data *sub;
+ struct of_regulator_match rmatch[ARRAY_SIZE(max8660_reg)];
+
+ np = of_find_node_by_name(dev->of_node, "regulators");
+ if (!np) {
+ dev_err(dev, "missing 'regulators' subnode in DT\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(rmatch); i++)
+ rmatch[i].name = max8660_reg[i].name;
+
+ matched = of_regulator_match(dev, np, rmatch, ARRAY_SIZE(rmatch));
+ if (matched <= 0)
+ return matched;
+
+ pdata->subdevs = devm_kzalloc(dev, sizeof(struct max8660_subdev_data) *
+ matched, GFP_KERNEL);
+ if (!pdata->subdevs)
+ return -ENOMEM;
+
+ pdata->num_subdevs = matched;
+ sub = pdata->subdevs;
+
+ for (i = 0; i < matched; i++) {
+ sub->id = i;
+ sub->name = rmatch[i].name;
+
[PATCH] regulators: max8660: fix build warnings
Fix a build warning for !CONFIG_OF and a cast from void* to
unsigned int which is invalid on 64bit machines.
Signed-off-by: Daniel Mack
Reported-by: Fengguang Wu
---
drivers/regulator/max8660.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index 7e6177e..aa8d823 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -364,7 +364,7 @@ static int max8660_pdata_from_dt(struct device *dev,
#else
static inline int max8660_pdata_from_dt(struct device *dev,
struct device_node **of_node,
- struct max8660_platform_data **pdata)
+ struct max8660_platform_data *pdata)
{
return 0;
}
@@ -380,7 +380,7 @@ static int max8660_probe(struct i2c_client *client,
struct max8660 *max8660;
int boot_on, i, id, ret = -EINVAL;
struct device_node *of_node[MAX8660_V_END];
- unsigned int type;
+ unsigned long type;
if (dev->of_node && !pdata) {
const struct of_device_id *id;
@@ -395,7 +395,7 @@ static int max8660_probe(struct i2c_client *client,
return ret;
pdata = &pdata_of;
- type = (unsigned int) id->data;
+ type = (unsigned long) id->data;
} else {
type = i2c_id->driver_data;
memset(of_node, 0, sizeof(of_node));
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: generic: add simple card with devicetree support
Hi, On 20.07.2013 19:25, Jean-Francois Moine wrote: > This generic simple card driver uses DT values to instanciate an audio > system in which the real work is done by the subdrivers (audio > controller, audio codec and pcm/dma controller). > > Signed-off-by: Jean-Francois Moine > --- > diff --git a/sound/soc/generic/simple-dt-card.c > b/sound/soc/generic/simple-dt-card.c > new file mode 100644 There is a simple-card driver in the tree already, and there were several attempts to add DT bindings for it in the past - have you seen that? Search for "ASoC: add simple-card DT support" in the archives ... Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: generic: add simple card with devicetree support
On 21.07.2013 13:24, Jean-Francois Moine wrote: > On Sat, 20 Jul 2013 22:23:36 +0200 > Daniel Mack wrote: > >> There is a simple-card driver in the tree already, and there were >> several attempts to add DT bindings for it in the past - have you seen >> that? Search for "ASoC: add simple-card DT support" in the archives ... > > Hi Daniel, > > Thanks, that is what I was searching. > > I will wait for Kuninori. Well, Kuninori recently stated he's currently too busy to continue. Given his permission, it might be an option to pick up where he left off and finish the open topics. Depends on how urgent your need is I guess. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v3.11-rc1 USB regressions
Hi Aaro, On 24.07.2013 20:51, Aaro Koskinen wrote: > On Tue, Jul 16, 2013 at 08:57:10PM +0300, Aaro Koskinen wrote: >> Here are full details: >> >> Kernel v3.11-rc1 and the following USB fixes: >> ARM: omap2: fix musb usage for n8x0 >> musb: omap: Fix: pass all the resources to musb core > > [...] > >> When I revert fe4cb0912f8e737f8e4b8b38b9e692f8062f5423 and >> 8b125df5b24cfb0ec7fa1971e343cc0badc1827d, it works like before (3.10): > > I'm now running -rc2 with above fixes and reverts (the only way to get > USB working). I'm seeing an additional issue, the following crash happens > always on N900 when doing "poweroff": Yes, with the mentioned patches reverted, musb_to_hcd() will return a faulty pointer. You can't easily revert them unfortunately. Your platform needs a real fix, I just have trouble understanding why a removed usb_add_hcd() would make the gadget code fail. Sorry for the trouble, but I don't currently have a board with musb in gadget mode to reproduce this issue. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v3.11-rc1 USB regressions
On 25.07.2013 02:30, Aaro Koskinen wrote: > On Wed, Jul 24, 2013 at 09:04:28PM +0200, Daniel Mack wrote: >> On 24.07.2013 20:51, Aaro Koskinen wrote: >>>> When I revert fe4cb0912f8e737f8e4b8b38b9e692f8062f5423 and >>>> 8b125df5b24cfb0ec7fa1971e343cc0badc1827d, it works like before (3.10): >>> >>> I'm now running -rc2 with above fixes and reverts (the only way to get >>> USB working). I'm seeing an additional issue, the following crash happens >>> always on N900 when doing "poweroff": >> >> Yes, with the mentioned patches reverted, musb_to_hcd() will return a >> faulty pointer. You can't easily revert them unfortunately. >> >> Your platform needs a real fix, I just have trouble understanding why a >> removed usb_add_hcd() would make the gadget code fail. >> >> Sorry for the trouble, but I don't currently have a board with musb in >> gadget mode to reproduce this issue. > > If you have any ideas what to look for, I can maybe try to debug this > issue. Please try changing the .mode field of musb_board_data to MUSB_OTG in your board file (arch/arm/mach-omap2/board-rx51.c). That should bring back the call to usb_add_hcd(), provided that you have USB_MUSB_DUAL_ROLE=y. I still don't see a reason why this is should be necessary for peripheral-only use though. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg macro in Documentation/kdump/gdbmacros.txt outdated
On 01.03.2013 02:31, Andreas Fenkart wrote: > Is there an updated version matching the changed printk structure? I hacked something up a while ago, but it's not perfect. The code below stops dumping too early IIRC, but I never got around to fix that. Maybe someone wants to look at it and help debug, so we can put it into gdbmacros.txt ... Thanks, Daniel define dmesg set $idx = 0 set $seq = 0 while ($seq++ < log_next_seq) set $buf = log_buf + $idx set $log = (struct log *) $buf if ($log->len == 0) loop_break end printf "%s\n", (char *) ($buf + sizeof(struct log)) set $idx += $log->len end end document dmesg dmesg Print the content of the kernel message buffer end -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH v3] davinci-mcasp: Add support for multichannel playback
Hi Michal,
On 28.02.2013 16:07, Michal Bachraty wrote:
> Davinci McASP has support for I2S multichannel playback.
> For I2S playback/receive, each serializer is capable to play 2 channels
> (L/R) audio data.Serializer function (Playback-receive-none) is configured
> in DT, depending on hardware specification. It is possible to play less
> channels than configured in DT. For that purpose,only specific number of
> active serializers are enabled. McASP FIFO need to have DMA transfer Bcnt
> set to number of enabled serializers, otherwise no data are transfered to
> McASP and Alsa generates "DMA/IRQ playback write error (DMA or IRQ trouble?)"
> error. For TDM mode, McASP is capable to play or receive 32 channels for one
> serializer. McAsp has support for max 16 serializer, therefore max channels
> is 32 * 8.
>
> Signed-off-by: Michal Bachraty
Ok, I successfully tested this now, and it seems to work fine. You can
take my
Tested-by: Daniel Mack
One thing that has to be considered by users of the driver is that the
'serial-dir' DT property has to contain enough '1' entries for
multichannel playback (or enough '2's for multichannel record). So this
information is not actually something that describes the hardware, but
rather some resource that can be and should be allocated dynamically by
the driver at run-time. Should we consider dropping this property?
Thanks,
Daniel
> ---
> sound/soc/davinci/davinci-mcasp.c | 66
> -
> sound/soc/davinci/davinci-pcm.c | 16 +
> sound/soc/davinci/davinci-pcm.h |1 +
> 3 files changed, 68 insertions(+), 15 deletions(-)
>
> diff --git a/sound/soc/davinci/davinci-mcasp.c
> b/sound/soc/davinci/davinci-mcasp.c
> index d2ca682..0a1af1a 100644
> --- a/sound/soc/davinci/davinci-mcasp.c
> +++ b/sound/soc/davinci/davinci-mcasp.c
> @@ -235,6 +235,10 @@
> #define DISMOD (val)(val<<2)
> #define TXSTATE BIT(4)
> #define RXSTATE BIT(5)
> +#define SRMOD_MASK 3
> +#define SRMOD_INACTIVE 0
> +#define SRMOD_TX 1
> +#define SRMOD_RX 2
>
> /*
> * DAVINCI_MCASP_LBCTL_REG - Loop Back Control Register Bits
> @@ -657,12 +661,15 @@ static int davinci_config_channel_size(struct
> davinci_audio_dev *dev,
> return 0;
> }
>
> -static void davinci_hw_common_param(struct davinci_audio_dev *dev, int
> stream)
> +static int davinci_hw_common_param(struct davinci_audio_dev *dev, int stream,
> + int channels)
> {
> int i;
> u8 tx_ser = 0;
> u8 rx_ser = 0;
> -
> + u8 ser;
> + u8 slots = dev->tdm_slots;
> + u8 max_active_serializers = (channels + slots - 1) / slots;
> /* Default configuration */
> mcasp_set_bits(dev->base + DAVINCI_MCASP_PWREMUMGT_REG, MCASP_SOFT);
>
> @@ -680,16 +687,42 @@ static void davinci_hw_common_param(struct
> davinci_audio_dev *dev, int stream)
> }
>
> for (i = 0; i < dev->num_serializer; i++) {
> + if (dev->serial_dir[i] == TX_MODE)
> + tx_ser++;
> + if (dev->serial_dir[i] == RX_MODE)
> + rx_ser++;
> + }
> +
> + if (stream == SNDRV_PCM_STREAM_PLAYBACK)
> + ser = tx_ser;
> + else
> + ser = rx_ser;
> +
> + if (ser < max_active_serializers) {
> + dev_warn(dev->dev, "stream has more channels (%d) than are "
> + "enabled in mcasp (%d)\n", channels, ser * slots);
> + return -EINVAL;
> + }
> +
> + tx_ser = 0;
> + rx_ser = 0;
> +
> + for (i = 0; i < dev->num_serializer; i++) {
> mcasp_set_bits(dev->base + DAVINCI_MCASP_XRSRCTL_REG(i),
> dev->serial_dir[i]);
> - if (dev->serial_dir[i] == TX_MODE) {
> + if (dev->serial_dir[i] == TX_MODE &&
> + tx_ser < max_active_serializers) {
> mcasp_set_bits(dev->base + DAVINCI_MCASP_PDIR_REG,
> AXR(i));
> tx_ser++;
> - } else if (dev->serial_dir[i] == RX_MODE) {
> + } else if (dev->serial_dir[i] == RX_MODE &&
> + rx_ser < max_active_serializers) {
> mcasp_clr_bits(dev->base + DAVINCI_MCASP_PDIR_REG,
> AXR(i));
> rx_ser++;
> + } else {
> + mcasp_mod_bits(dev->base + DAVINCI
Re: [PATCH] clk: add si5351 i2c common clock driver
Hi Sebastian,
On 27.02.2013 11:01, Sebastian Hesselbarth wrote:
> first of all sorry for the late answer but thanks for testing the driver.
>
> On 2/19/13, Daniel Mack wrote:
>> Hi Sebastian,
>>
>> I did some more tests today and it took me a while to dig for the root
>> cause why things were not working for me in the first place - see below.
>>
>>
>> On 09.02.2013 13:59, Sebastian Hesselbarth wrote:
>>
>>> +==Example==
>>> +
>>> +/* 25MHz reference crystal */
>>> +ref25: ref25M {
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>;
>>> + clock-frequency = <2500>;
>>> +};
>>> +
>>> +i2c-master-node {
>>> +
>>> + /* Si5351a msop10 i2c clock generator */
>>> + si5351a: clock-generator@60 {
>>> + compatible = "silabs,si5351a-msop";
>>> + reg = <0x60>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + #clock-cells = <1>;
>>> +
>>> + /* connect xtal input to 25MHz reference */
>>> + clocks = <&ref25>;
>>
>> As referred to in another thread, registering the ref25M clock that way
>> didn't suffice for me on my platform - but that's a different story.
>
> I guess "fixed-clock" isn't registered by OMAP's clock init code? I had
> to do this on dove, too. Actually, I will come back to clock initialization
> for
> dove later and was hoping that there will be some global way of registering
> core common clock drivers (or at least fixed-clock) until then.
>
>>> +static void si5351_read_parameters(struct si5351_driver_data *drvdata,
>>> + unsigned char reg, struct si5351_parameters *params)
>>> +{
>>> + unsigned char buf[SI5351_PARAMETERS_LENGTH];
>>
>> On a general note, I think you can use u8 instead of unsigned char all
>> over the place here, which will save you some indentation trouble.
>
> Ok, I guess I was deriving "unsigned char" usage from other clock drivers
> and never went to u8. But I ll reconsider using u8 when all issues are
> worked out.
>
>>> +static inline int _si5351_clkout_reparent(struct si5351_driver_data
>>> *drvdata,
>>> + unsigned char num, unsigned char parent)
>>> +{
>>> + struct clk *pclk;
>>> +
>>> + if (num > 8 ||
>>> + (drvdata->variant == SI5351_VARIANT_A3 && num > 3))
>>> + return -EINVAL;
>>> +
>>> + switch (parent) {
>>> + case 0:
>>> + pclk = drvdata->msynth[num].hw.clk;
>>> + break;
>>> + case 1:
>>> + pclk = drvdata->msynth[0].hw.clk;
>>> + if (num >= 4)
>>> + pclk = drvdata->msynth[4].hw.clk;
>>> + break;
>>> + case 2:
>>> + pclk = drvdata->xtal.clk;
>>> + break;
>>> + case 3:
>>> + if (drvdata->variant != SI5351_VARIANT_C)
>>> + return -EINVAL;
>>> + pclk = drvdata->clkin.clk;
>>> + break;
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> + return clk_set_parent(drvdata->clkout[num].hw.clk, pclk);
>>> +}
>>
>> [...]
>>
>>> +static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
>>> +{
>>> + struct si5351_hw_data *hwdata =
>>> + container_of(hw, struct si5351_hw_data, hw);
>>> + unsigned val;
>>> +
>>> + val = 0;
>>> + hw->clk->flags &= ~CLK_SET_RATE_PARENT;
>>> + switch (index) {
>>> + case 0:
>>> + hw->clk->flags |= CLK_SET_RATE_PARENT;
>>> + val = SI5351_CLK_INPUT_MULTISYNTH_N;
>>> + break;
>>
>> I fugured that _si5351_clkout_reparent() wouldn't actually call
>> ->set_parent() on the clock, which leads to the fact that
>> CLK_SET_RATE_PARENT is not set in the flags. That way, only the clkout
>> end leaf is actually supplied with a new rate, which leads to incorrect
>> effective clocks, depending on the current multisynth/pll configuration.
>
> Yeah, true. Unfortunately, _clkout_reparent() is more like a dirty hack to
> allow to reparent the clock output. At registration internal configuration of
> si5351 is not known an
Re: Question about fixed-clock
Hi eyerone,
On 19.02.2013 18:32, Daniel Mack wrote:
> On 19.02.2013 18:22, Mike Turquette wrote:
>> > Quoting Daniel Mack (2013-02-19 01:53:18)
>>> >> Hi Fabio,
>>> >> Hi Afzal,
>>> >>
>>> >> On 19.02.2013 02:33, Fabio Estevam wrote:
>>>> >>> On Mon, Feb 18, 2013 at 8:55 PM, Daniel Mack wrote:
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> This might be a stupid question, but I'm somehow stuck here. I'm
>>>>> >>>> using a
>>>>> >>>> driver with the following DTS sub-node:
>>>>> >>>>
>>>>> >>>> ref25: ref25M {
>>>>> >>>> compatible = "fixed-clock";
>>>>> >>>> #clock-cells = <0>;
>>>>> >>>> clock-frequency = <2500>;
>>>>> >>>> };
>>>>> >>>>
>>>>> >>>> clock-generator@0 {
>>>>> >>>> /* ... */
>>>>> >>>> #clock-cells = <1>;
>>>>> >>>> clocks = <&ref25>;
>>>>> >>>> }
>>>>> >>>>
>>>>> >>>> The device driver for clock-generator uses something like the
>>>>> >>>> following
>>>>> >>>> call to get its clock:
>>>>> >>>>
>>>>> >>>> clk = of_clk_get(np, 0);
>>>>> >>>>
>>>>> >>>> but the return value is ERR_PTR(-ENOENT) and I also can't find this
>>>>> >>>> clock in the clk debugfs tree.
>>>>> >>>>
>>>>> >>>> This is on a OMAP/AM33xx device with kernel 3.8-rc7 plus the -next
>>>>> >>>> tips
>>>>> >>>> of arm-soc and omap, but with no other special clock options
>>>>> >>>> selected in
>>>>> >>>> the config. Is there anything I'm missing to correctly instantiate
>>>>> >>>> the
>>>>> >>>> dummy clock?
>>>> >>>
>>>> >>> Have you registered it with clk_register_fixed_rate() ?
>>>> >>>
>>>> >>> In imx we use imx_clk_fixed, which in turns call
>>>> >>> clk_register_fixed_rate().
>>>> >>>
>>>> >>> Take a look at arch/arm/mach-imx/clk-imx51-imx53.c for a reference.
>>> >>
>>> >> Hmm no, I didn't do anything else than adding it to the DT in the first
>>> >> place, hoping that a driver will pick it up and add the clock for me.
>>> >> But it turns out that of_clk_init() is not called at all on my platform.
>>> >>
>>> >> I'm doing this now from omap_generic_init() and it works. If that's an
>>> >> appropriate place to call it, I can provide a patch.
>>> >>
>> >
>> > You can provide a patch, but your example above is for a dummy clock,
>> > correct?
> No, it's a real clock with a fixed frequency on the board, which feeds
> another clock chip. I thought this is what fixed-clock is for, just like
> what a fixed-regulator does? Or how would you describe such a thing in
> DT, in order to use it as input to another device?
>
>> > It would be best to post your patch along with a real-world
>> > use for calling of_clk_init().
> Not sure what you mean exactly, but the patch is attached. However, I
> still think I lack some understanding here - the fact that compatible
> strings have to be passed explicitly from generic code feels wrong.
>
>
> Thanks,
> Daniel
>
>
> 0001-ARM-OMAP-generic-add-call-to-of_clk_init.patch
>
>
> From 850120371830ffb5e2146aeb2d21c724d6ded09e Mon Sep 17 00:00:00 2001
> From: Daniel Mack
> Date: Tue, 19 Feb 2013 12:05:25 +0100
> Subject: [PATCH] ARM: OMAP: generic: add call to of_clk_init()
>
> This is needed to instanciate fixed clocks in the DT.
>
> Signed-off-by: Daniel Mack
> ---
> arch/arm/mach-omap2/board-generic.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 0274ff7..3580f16 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -35,6 +36,11 @@ static struct of_device_id omap_dt_match_table[]
> __initdata = {
> { }
> };
>
> +static const __initconst struct of_device_id clk_match[] = {
> + { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> + {}
> +};
> +
> static void __init omap_generic_init(void)
> {
> omap_sdrc_init(NULL, NULL);
> @@ -49,6 +55,7 @@ static void __init omap_generic_init(void)
> omap4_panda_display_init_of();
> else if (of_machine_is_compatible("ti,omap4-sdp"))
> omap_4430sdp_display_init_of();
> + of_clk_init(clk_match);
> }
>
> #ifdef CONFIG_SOC_OMAP2420
Any opinion about this approach?
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi-gpio: init CS before spi_bitbang_setup()
Cc: Mark
On 09.04.2013 18:40, Josef Ahmad wrote:
> spi_bitbang_setup() deasserts the chip select line to initialise
> the device. The chip select GPIO line is obtained from
> spi_gpio->cs_gpios[] private data.
> Currently, devices that are not registered under devicetree
> environment will call into spi_bitbang_setup() with stale
> cs_gpios[].
>
> This patch ensures spi_gpio->cs_gpios[] is always initialised prior
> to calling spi_bitbang_setup().
>
> Reviewed-by: Daniel Mack
> Signed-off-by: Josef Ahmad
> ---
> drivers/spi/spi-gpio.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
> index c7cf0b7..0fa345c 100644
> --- a/drivers/spi/spi-gpio.c
> +++ b/drivers/spi/spi-gpio.c
> @@ -265,9 +265,9 @@ static int spi_gpio_setup(struct spi_device *spi)
> }
> }
> if (!status) {
> - status = spi_bitbang_setup(spi);
> /* in case it was initialized from static board data */
> spi_gpio->cs_gpios[spi->chip_select] = cs;
> + status = spi_bitbang_setup(spi);
> }
>
> if (status) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi-gpio: init CS before spi_bitbang_setup()
On 09.04.2013 19:08, Mark Brown wrote: > On Tue, Apr 09, 2013 at 07:06:32PM +0200, Daniel Mack wrote: >> Cc: Mark >> >> On 09.04.2013 18:40, Josef Ahmad wrote: >>> spi_bitbang_setup() deasserts the chip select line to initialise >>> the device. The chip select GPIO line is obtained from > > Please resend the patch - git am doesn't know how to strip off quotation > stuff! > The reply was fyi only, as the patch also went to spi-devel-general. Can you pick it from there or should Josef send it again with your address in Cc:? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regmap: Question about devices with unequal register sizes
On 17.02.2013 17:23, Mark Brown wrote: > On Sat, Feb 16, 2013 at 06:03:51PM +0100, Daniel Mack wrote: > >> The register layout is described on page 26, and they call their >> registers 'subaddresses'. Up to sub-address 0x1c, I see no problem >> mapping that to a simple 8-bit regmap layout, but above that, access >> gets trickier because registers change their sizes, which breaks the cache. > > The regmap I/O code isn't making any effort to support such devices, the > hardware is just too crazy to worry about. The best you can do is use > the no-bus support and open code your physical I/O so you can still use > the cache. So it turns out I need to write these registers now on the TAS5086 codec, which has such a strange layout. I wonder how I can possibly open code the physical I/O with registers that are up to 20 bytes in size, while the reg_write callback in struct regmap_config assumes an unsigned int suffices for the data? Any example you can point me to? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH, for-next] pinctrl: fix mutex deadlock in get_pinctrl_dev_from_of_node()
This obvious bug was introduced by d755910b7 ("pinctrl: move subsystem
mutex to pinctrl_dev struct").
Signed-off-by: Daniel Mack
---
This applies on today's linux-next.
drivers/pinctrl/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 37cd774..78eae4d 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -129,7 +129,7 @@ struct pinctrl_dev *get_pinctrl_dev_from_of_node(struct
device_node *np)
return pctldev;
}
- mutex_lock(&pinctrldev_list_mutex);
+ mutex_unlock(&pinctrldev_list_mutex);
return NULL;
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware: move EXPORT_SYMBOL annotations
Move EXPORT_SYMBOL annotations so they follow immediately after the
closing function brace line.
Signed-off-by: Daniel Mack
---
drivers/base/firmware_class.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 4b1f926..4d9643f 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1079,6 +1079,7 @@ request_firmware(const struct firmware **firmware_p,
const char *name,
{
return _request_firmware(firmware_p, name, device, true, false);
}
+EXPORT_SYMBOL(request_firmware);
/**
* release_firmware: - release the resource associated with a firmware image
@@ -1092,6 +1093,7 @@ void release_firmware(const struct firmware *fw)
kfree(fw);
}
}
+EXPORT_SYMBOL(release_firmware);
/* Async support */
struct firmware_work {
@@ -1172,6 +1174,7 @@ request_firmware_nowait(
schedule_work(&fw_work->work);
return 0;
}
+EXPORT_SYMBOL(request_firmware_nowait);
/**
* cache_firmware - cache one firmware image in kernel memory space
@@ -1202,6 +1205,7 @@ int cache_firmware(const char *fw_name)
return ret;
}
+EXPORT_SYMBOL_GPL(cache_firmware);
/**
* uncache_firmware - remove one cached firmware image
@@ -1232,6 +1236,7 @@ int uncache_firmware(const char *fw_name)
return -EINVAL;
}
+EXPORT_SYMBOL_GPL(uncache_firmware);
#ifdef CONFIG_PM_SLEEP
static ASYNC_DOMAIN_EXCLUSIVE(fw_cache_domain);
@@ -1536,9 +1541,3 @@ static void __exit firmware_class_exit(void)
fs_initcall(firmware_class_init);
module_exit(firmware_class_exit);
-
-EXPORT_SYMBOL(release_firmware);
-EXPORT_SYMBOL(request_firmware);
-EXPORT_SYMBOL(request_firmware_nowait);
-EXPORT_SYMBOL_GPL(cache_firmware);
-EXPORT_SYMBOL_GPL(uncache_firmware);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: move EXPORT_SYMBOL annotations
On 27.05.2013 10:35, Takashi Iwai wrote:
> At Thu, 23 May 2013 22:17:18 +0200,
> Daniel Mack wrote:
>>
>> Move EXPORT_SYMBOL annotations so they follow immediately after the
>> closing function brace line.
>>
>> Signed-off-by: Daniel Mack
>
> Acked-by: Takashi Iwai
Thanks. Greg, could you take this through your tree?
Daniel
>
>
> thanks,
>
> Takashi
>
>> ---
>> drivers/base/firmware_class.c | 11 +--
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>> index 4b1f926..4d9643f 100644
>> --- a/drivers/base/firmware_class.c
>> +++ b/drivers/base/firmware_class.c
>> @@ -1079,6 +1079,7 @@ request_firmware(const struct firmware **firmware_p,
>> const char *name,
>> {
>> return _request_firmware(firmware_p, name, device, true, false);
>> }
>> +EXPORT_SYMBOL(request_firmware);
>>
>> /**
>> * release_firmware: - release the resource associated with a firmware image
>> @@ -1092,6 +1093,7 @@ void release_firmware(const struct firmware *fw)
>> kfree(fw);
>> }
>> }
>> +EXPORT_SYMBOL(release_firmware);
>>
>> /* Async support */
>> struct firmware_work {
>> @@ -1172,6 +1174,7 @@ request_firmware_nowait(
>> schedule_work(&fw_work->work);
>> return 0;
>> }
>> +EXPORT_SYMBOL(request_firmware_nowait);
>>
>> /**
>> * cache_firmware - cache one firmware image in kernel memory space
>> @@ -1202,6 +1205,7 @@ int cache_firmware(const char *fw_name)
>>
>> return ret;
>> }
>> +EXPORT_SYMBOL_GPL(cache_firmware);
>>
>> /**
>> * uncache_firmware - remove one cached firmware image
>> @@ -1232,6 +1236,7 @@ int uncache_firmware(const char *fw_name)
>>
>> return -EINVAL;
>> }
>> +EXPORT_SYMBOL_GPL(uncache_firmware);
>>
>> #ifdef CONFIG_PM_SLEEP
>> static ASYNC_DOMAIN_EXCLUSIVE(fw_cache_domain);
>> @@ -1536,9 +1541,3 @@ static void __exit firmware_class_exit(void)
>>
>> fs_initcall(firmware_class_init);
>> module_exit(firmware_class_exit);
>> -
>> -EXPORT_SYMBOL(release_firmware);
>> -EXPORT_SYMBOL(request_firmware);
>> -EXPORT_SYMBOL(request_firmware_nowait);
>> -EXPORT_SYMBOL_GPL(cache_firmware);
>> -EXPORT_SYMBOL_GPL(uncache_firmware);
>> --
>> 1.8.1.4
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Patches
Hi Miles, On Thu, Mar 7, 2013 at 11:02 AM, Miles Rout wrote: > I'm probably stepping on some toes here, but is it really necessary to > post raw patches to this list? They do rather clog up one's inbox. It depends what your patches are for. If you're working on a specific subsystem, it might also suffice sending the patches to the appropriate mailing list for that subsystem. Just make sure to always Cc: the maintainers of the bits you're patching, and check the file MAINTAINERS in your Linux tree. Also read up Documentation/SubmittingPatches for general information. > What's wrong with git? Nothing's wrong with git. It's just that sending patches to a mailing list makes it easier for people to comment on them. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
