> Oops, I seemed to copy Q1.14 instead of Q14.1, but isn't it still the same.
> When I added some debug messages it still seemed to be corret.
>
> Lowest number (-32768) is represented with 16th bit '1' and the rest are
> zeros, right? That is 0x8000.
> -1 has all the bits set (0x) and 0 has
> I'm a bit confused. What do you mean by that?
>
> AFAICS, Q1.14 defines values [-16384.0, +16383.5], which are mapped in the
> driver to integers [-32768, 32767], right? Moreover, those Q1.14 values in
> registers are mapped to [-2, 2] in HW. So is there a problem somewhere?
>
> Cheers, Ilkka
> +
> +static const struct snd_kcontrol_new omap_mcbsp2_st_controls[] = {
> + SOC_SINGLE_EXT("McBSP2 Sidetone Switch", 1, 0, 1, 0,
> + omap_mcbsp_st_get_mode, omap_mcbsp_st_put_mode),
> + OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP2 Sidetone Channel 0 Volume",
> +
Mark Brown wrote:
>> Will this ever be revisited =) ? If so, I think there's going to be a
>> jungle in finding the right spots - you need to remember the bypass
>> paths also (bias is not on necessarily).
>
> The bias is always on when any path through the chip is on, this was
> fixed in either .
> Isn't the better way to achieve this thing, at least from the OFF mode
> perspective, is to provide similar implementation for McBSP in
> omap3_core_save_context () / omap3_core_restore_context(), in
> file arch/arm/mach-omap2/pm34xx.c? Code for other core peripherals
> is already there and we h
>>
>> I would say the default mode for the omap34xx should be also element as
>> it keeps the omap_pcm_pointer behavior the same than currently and
>> avoids possible regression.
>
> Yes, the default mode should be the element mode in my opinion as well.
>
> --
> Péter
Well, the element mode i
>>
>> +/** McBSP IRQSTATUS bit definitions
>> /
>> +#define IRQST_XRDY (1<<10)
>> +#define IRQST_RRDY (1<<3)
>> +
>> /** McBSP WAKEUPEN bit definitions
>> */
>> #define XEMPTYEOFEN 0x40
>> It is possible for GPIO IRQ lines configured with
>> falling edge triggering only to get IRQs at the
>> rising edge upon the exit of offmode. And vice
>> versa. Prevent such IRQs to arrive by generating
>> the IRQ obeying the detection scheme.
>
> Is the situation still the same if we temporari
>> l ^= bank->saved_datain;
>> l &= bank->non_wakeup_gpios;
>> - if (l) {
>> +
>> + /*
>> + * No need to generate IRQs for the rising edge for gpio IRQs
>> + * configured with falling edge only; and vice versa.
>> +
Jarkko Nikula [jhnik...@gmail.com] wrote:
> Are you sure this change is necessary? CLKSRG is kind of master clock
> to McBSP so original stetson guessed (?) 100 us should be fine for all
> serial links where bit clock is higher than 20 kHz.
The McBSP / DMA stuff doesn't really work properly, when
> Didn't check any deeply can clk_disable sleep in any case but anyway
> there is no need to cover it with spinlock so better to not hold the
> lock while disabling.
>
>
> Jarkko
Actually, is there any room for the race? I remember someone saying
the clk:s have counters, so:
1. If mcbsp is "ta
> Race here? See, McBSP is marked free before disabling the clocks and
> thus omap_mcbsp_request can start enabling them. So should you keep
> clock disabling after test for mcbsp->free as here now but mark McBSP
> free only after clocks are disabled?
>
> I think you should send this as an separa
> The problem with Eero's patch is that it changes the internal clock
> (again thanks to that confusing table). You should be able to use same
> for all modes. Also note that the noise filter is one internel clock
> period. Currently the driver uses 19.2 MHz which exceeds the I2C spec
> max. So 24
> So, it might be worth considering my following proposition?"
> Now, from a s/w perspective, If we would like to have it so that we can
> configure tHigh and tLow based on devices, electrical characteristics on
> a bus, not just speed of the bus, the current implementation would
> probably need t
> ;) Aye Aye I wonder if the equation you provided is based on
> emperical measurement? if so would it vary based on electrical
> characteristics of a platform? I mean beagleboard Vs Zoom Vs SDP
> atleast have variances of i2c trace lengths and number of devices per
> i2c bus.. wont the equat
> But my question is this: why are we trying to a different equation
> here compared to the equation in the TRM?
Don't just blindly trust the TRM, all that matters is the real signal
caught in the scope. That is what you want to verify.
- Eero
--
To unsubscribe from this list: send the line "uns
> I am not entirely sure about the basis of Eero's equation:
>
> scll = (scl+3) * iclk
> sclh = (scl+9) * iclk
No, no:
Exactly the opposite,
+ fsscll = internal_clk / (dev->speed * 2) - 3;
+ fssclh = internal_clk / (dev->speed * 2) - 9;
means a longer
17 matches
Mail list logo
