e. Considering that this
driver is specific to the Freescale hypervisor, so I don't see any harm in using
ioctls.
> For an ioctl, please follow the normal pattern of defining a separate
> structure for each case, no union.
Ok. This will break our e
question. This header file is currently licensed under the GPL v2
only. Does that mean that any application that includes this header file so
that it can talk to the driver/hypervisor also needs to be licensed under the
GPL?
--
Timur Tabi
Linux kernel develop
ivers/misc,
>> > because
>> > it's just a single driver with a miscellaneous collection of interfaces.
> Ok, fair enough. If nobody has a strong preference any other way, just make it
> drivers/firmware then.
Did you mean to say drivers/misc?
--
Timur Tabi
Li
partition upon receiving the
shutdown doorbell from a manager partition
4. An interface for receiving callbacks when a managed partition shuts down.
Signed-off-by: Timur Tabi
---
drivers/misc/Kconfig |7 +
drivers/misc/Makefile |1 +
drivers/misc/fsl_hypervisor.c | 954
d what's wrong with drivers/misc, especially since my
driver registers as a "misc" driver.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
e an example of a driver that *does* belong in drivers/misc?
Frankly, I just don't see what's wrong with a repository of various drivers that
don't really belong anywhere else.
And what about my concern that my driver will be the only one in drivers/virt?
--
Ti
ilar drivers in other
> places, e.g. drivers/ps3/ps3-sys-manager.c, drivers/s390/char/vmcp.c
> or parts of drivers/xen.
Alright, drivers/virt it is. I'll post a v4 once everyone else has had a chance
to comment on v3.
--
Timur Tabi
Linux kernel
ter that the SPI flash driver goes through the hypervisor
abstration? One of the patches in this patchset is a TTY driver that goes
through the Freescale hypervisor. I put the drivers in drivers/tty.
--
Timur Tabi
Linux kernel developer at Freescale
__
is enabled only if U-Boot enables it, and U-Boot will set the
property if the clock is enabled. A future version of the P1022DS audio
driver will configure the clock itself, but for now, the driver should
not be told that the clock is running when it isn't.
Signed-off-by: Timur Tabi
---
Witho
is enabled only if U-Boot enables it, and U-Boot will set the
property if the clock is enabled. A future version of the P1022DS audio
driver will configure the clock itself, but for now, the driver should
not be told that the clock is running when it isn't.
Also fix the FIFO depth to 15, instea
The platform file for the Freecale P1022DS reference board is not freeing
the ioremap() mapping of the PIXIS and global utilities nodes it creates.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p1022_ds.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff
.
Signed-off-by: Timur Tabi
---
drivers/Kconfig|2 +
drivers/Makefile |3 +
drivers/virt/Kconfig | 22 +
drivers/virt/Makefile |5 +
drivers/virt/fsl_hypervisor.c | 961
include/linux/Kbuild
so you could use
>
> * struct fsl_hv_ioctl_restart: - restart a partition
>
Ok, I'll change it.
>> > + * fsl_hv_event_register -- register a callback for failover events
> Documentation/kernel-doc-nano-HOWTO.txt says to use one '-' here, not 2.
Ok. I'
Randy Dunlap wrote:
> But it sounds like virt/ needs virt/host/ and virt/guest/ to me.
I'm okay with that idea, except there's a consensus that drivers should be in
drivers/.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxpp
don't know what the holdup is.
> but what makes it a "driver"?
That's a good point.
Ok, so maybe I don't have any really good answers here. :-)
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ll fix that after we've updated the applications. But we have a
chicken-or-the-egg problem where we need the same application to work with the
new and old ioctl interface for a period of time.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linu
down.
Signed-off-by: Timur Tabi
---
drivers/Kconfig|2 +
drivers/Makefile |3 +
drivers/virt/Kconfig | 32 ++
drivers/virt/Makefile |5 +
drivers/virt/fsl_hypervisor.c | 983
include/linux
it's actually not
being used, or that it won't conflict in the future.
So is it okay to stick with 0, or do I need to pick a new number?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
h.
Ok, I was really hoping to avoid doing this. Like I said, binary compatibility
is important, and changing the type will break my existing apps. Are you
insisting that I pick a new number?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ou can then drop that patch and use the upstream version of the
> interfaces.
I think I can make that work.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ernel but not their apps, and then wonder why nothing
works.
But as Arnd pointed out, it really isn't as big of deal as I make it out to be.
I can maintain compatibility internally. I blame my allergy medicine.
--
Timur Tabi
Linux kernel developer at Freescale
___
down.
Signed-off-by: Timur Tabi
---
Documentation/ioctl/ioctl-number.txt |1 +
drivers/Kconfig |2 +
drivers/Makefile |3 +
drivers/virt/Kconfig | 32 ++
drivers/virt/Makefile|5 +
drivers/virt
CONFIG_PPC_EPAPR_HV_BYTECHAN adds support for the Freescale hypervisor
byte channel tty driver.
CONFIG_VIRT_DRIVERS and CONFIG_FSL_HV_MANAGER add support for the Freescale
hypervisor management driver.
Signed-off-by: Timur Tabi
---
arch/powerpc/configs/corenet32_smp_defconfig |3 +++
1
cenario works fine.
I still find it hard to believe that this is necessary.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Timur Tabi wrote:
> Hmmm I find that surprising. Memory allocated via ioremap() is supposed
> to
> be available in interrupt handlers, where TLB mappings can't be created
> on-the-fly. I'm not sure that your observation is correct.
Ok, it turns out I'm wrong. As
is enabled.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p3041_ds.c | 11 +++
arch/powerpc/platforms/85xx/p4080_ds.c | 11 +++
arch/powerpc/platforms/85xx/p5020_ds.c | 11 +++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/plat
Scott Wood wrote:
> FWIW, it's not supported under KVM either -- though we don't support an SMP
> guest under KVM yet, and KVM silently ignores it rather than logs errors as
> the FSL HV does.
Does KVM set the root compatible to "fsl,P4080DS-hv"?
--
Timur T
eady says, "and
probably other chips", and you're also just bloating the summary line. We can't
list every possible Dallas-compatible RTC chip here.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
rtc device: DS1307.
>
>
> Signed-off-by: Priyanka Jain
Acked-by: Timur Tabi
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ll
of them.
Removing the ioctl interface also allows us to clean up the header file and
remove other unusued stuff.
Signed-off-by: Timur Tabi
---
There's a warning about dummy_ad_addr that will be fixed in a future patch.
Documentation/ioctl/ioctl-number.txt |2 -
drivers/video/fs
s also a bit
that's specific to our hypervisor. And even then, we would need some way to
differentiate among different versions of our hypervisor, in case some future
version adds timebase support. We currently use the device tree for all this,
so I'm not sure what a FTR bit will gain u
Timur Tabi wrote:
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes. This driver provides Linux kernel support for byte
> channels via three distinct interf
Felix Radensky wrote:
> What am I doing wrong ?
Can you debug the PHY driver to see if it's getting called and trying to talk to
the PHY itself?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linu
code with the simpler routine that's currently used on the P1022DS.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 107 ---
1 files changed, 48 insertions(+), 59 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
b/ar
Enable framebuffer console support by default in the defconfig on the
Freescale MPC8610 HPCD reference board. This allows the boot messages to
be shown on the video display.
Signed-off-by: Timur Tabi
---
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |5 +
1 files changed, 5
are has done the sync, and kexec hasn't messed
> it up. Besides being a waste of boot time, the firmware's sync is
> probably tighter since it can use a platform-specific mechanism to start all
> the timebases at once.
I agree with th
Enable framebuffer console support by default in the defconfigs for the
Freescale 85xx-based reference board. This allows the boot messages to
be shown on the video display on the P1022DS.
Signed-off-by: Timur Tabi
---
arch/powerpc/configs/mpc85xx_defconfig |4
arch/powerpc
To ensure that the DIU pixel clock will not be set to an invalid value,
clamp the PXCLK divider to the allowed range (2-255). This also acts as
a limiter for the pixel clock.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/85xx/p1022_ds.c |7 ++-
1 files changed, 6 insertions
. p1022ds_set_pixel_clock)
to clamp the pixel clock to a supported value.
Signed-off-by: Timur Tabi
---
drivers/video/fsl-diu-fb.c | 16
include/linux/fsl-diu-fb.h |6 --
2 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu
Felix Radensky wrote:
> On P1022DS both ethernet controllers are connected to RGMII PHYs
> accessible via MDIO bus. Remove fixed-link property from ethernet
> nodes as they only required when fixed link PHYs without MDIO bus
> are used.
>
> Signed-off-by: Felix Radensky
Ac
ging the monitor port does not currently work on the P1022DS,
because the code that talks to the PIXIS FPGA is broken.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-
arch/powerpc/platforms/85xx/p1022_ds.c | 47 -
arch/powerp
but it's good to be
sure.
Signed-off-by: Timur Tabi
---
arch/powerpc/include/asm/mpic.h |2 --
arch/powerpc/sysdev/mpic.c | 24 +++-
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic
Greg KH wrote:
>> > 3) A tty driver, which is used to handle user-space input and output. The
>> > byte channel used for the console is designated as the default tty.
>> >
>> > Signed-off-by: Timur Tabi
> Doesn't apply at all to the tty-next tree, so
s, "junk tree, please ignore".
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
tty driver, which is used to handle user-space input and output. The
byte channel used for the console is designated as the default tty.
Signed-off-by: Timur Tabi
---
arch/powerpc/include/asm/udbg.h |1 +
arch/powerpc/kernel/udbg.c |2 +
drivers/tty/Kconfig | 34 ++
d
ging the monitor port does not currently work on the P1022DS,
because the code that talks to the PIXIS FPGA is broken.
Signed-off-by: Timur Tabi
Acked-by: Anatolij Gustschin
---
arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-
arch/powerpc/platforms/85xx/p1022_ds.c | 47 +
neric -hv extension to indicate that this is
> a virtual platform.
>
> "mpc85xx-hv"
> "corenet-32-hv"
> "corenet-64-hv"
That's an improvement, but I wonder if we should just keep doing what we do with
rtualization, but we already have this problem with Topaz today.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 03/16/2015 02:17 PM, Fabian Frederick wrote:
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
...
drivers/tty/serial/ucc_uart.c | 2 +-
For this driver:
Acked-by: Timur Tabi
On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan wrote:
> Have just sent out a patch considering the previous discussion.
> http://patchwork.ozlabs.org/patch/462249/
> [PATCH] powerpc/defconfig: new way of writing defconfig
The ability to merge defconfigs is a feature that's been requested by
many pe
On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote:
>
>
> The ability to merge configs is already there. We're just talking about
> using that functionality.
Why do you need a powerpc-specific way to use merge_config.sh? Other
architectures have the same problem with defconfigs.
Besides, wouldn
Scott Wood wrote:
>
>Why do you need a powerpc-specific way to use merge_config.sh? Other
>architectures have the same problem with defconfigs.
What are you perceiving as "powerpc-specific" about what we're
proposing?
Well, there's the subject of this thread, which is "new way of writing
d
Scott Wood wrote:
We want single-name config targets to still work from the user's
perspective, but we want to reduce the (often imperfect) duplication
under the hood.
Ok, then define a new Kconfig option that merge_config.sh will look for.
So in p1_defconfig, there will be this line:
CONFI
On 04/21/2015 12:55 PM, Scott Wood wrote:
>
>Ok, then define a new Kconfig option that merge_config.sh will look for.
> So in p1_defconfig, there will be this line:
>
>CONFIG_OTHER_DEFCONFIGS=fsl_basic_config
If you want to do that go ahead. In the meantime we'll use the
mechanism that alread
in Chen
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Maciej S. Szmigiero wrote:
+ if (newbinding && fsl_ssi_is_ac97(ssi_private)) {
Is the "newbinding" necessary? I thought only the original PowerPC
device trees were the only one that have the old binding, and they never
supported AC97.
___
Li
Maciej S. Szmigiero wrote:
If there isn't going to be new platforms added with old bindings then this
won't be needed - I'll remove it.
I would love it if someone would port those original device trees to the
new binding, so that we can get rid of the old one. But we should
definitely not a
Maciej S. Szmigiero wrote:
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
- ssi_private->cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private->cp
On Jul 6, 2015, at 4:49 AM, Zidan Wang wrote:
> The register SFCSR is volatile, but some bits in it need to be
> recovered after suspend/resume.
>
> Signed-off-by: Zidan Wang
Shouldn't this be part of patch #1?
___
Linuxppc-dev mailing list
Linuxppc-d
On Jul 6, 2015, at 4:49 AM, Zidan Wang wrote:
> +static bool fsl_ssi_readable_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case CCSR_SSI_STX0:
> + case CCSR_SSI_STX1:
> + case CCSR_SSI_SRX0:
> + case CCSR_SSI_SRX1:
> + case CCSR_SSI_SCR:
> + ca
Dongsheng Wang wrote:
For deep sleep, the diu module will power off, when wake up
from the deep sleep, the registers need to be reinitialized.
Signed-off-by: Jason Jin
Signed-off-by: Wang Dongsheng
Acked-by: Timur Tabi
___
Linuxppc-dev mailing
Wang Dongsheng wrote:
Thanks Timur.
@Scott,
Could you apply this patch?
You need to ask the fbdev maintainer to apply it, because it has to go
through his tree.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
Alexander Popov wrote:
Initialize Freescale MPC512x DMA driver with subsys_initcall()
to allow the depending drivers to call dma_request_slave_channel()
during their probe.
Signed-off-by: Alexander Popov
Is there any way we can use -EPROBEDEFER instead?
Alexander Popov wrote:
+- dma-names: should be "rx-tx";
Why bother, if it can only be one value?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Alexander Popov wrote:
+struct mpc512x_lpbfifo_request {
+ phys_addr_t bus_phys; /* physical address of some device on LPB */
Is this a phys_addr_t or a dma_addr_t? It can't be both a physical
address and a bus address.
+ void *ram_virt; /* virtual address of some reg
Alexander Popov wrote:
The only question I have: why calling dma_unmap_single() from within
a spinlock is a bad practice?
I don't know, but usually functions that allocate or free memory cannot
be called from within a spinlock. You need to check that. Since the
MPC5121 is a single-core CPU,
Alexander Popov wrote:
I've just followed devicetree/bindings/dma/dma.txt...
This "rx-tx" doesn't mean much but it could show that LocalPlus Bus FIFO
uses a single DMA read-write channel. Should I really drop it?
Hmmm, I'm not sure. Is there anything else (besides your driver) that
parses thi
On 09/30/2015 04:24 PM, Alexander Popov wrote:
Can you test for "!cs" here instead?
+e = -EFAULT;
+goto err_param;
+}
Unfortunately no: 0 is a valid value for Chip Select.
Is it OK to leave it like that?
Yes.
+lpbfifo.ram_bus_addr = sg_dma_address(&sg); /* For fre
Gerlando Falauto wrote:
Change-Id: If1e7d8931f440ea9259726c36d3df797dda016fb
You need to remove these from patches that are emailed, and fix the
pointer type comparison.
Otherwise,
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev
On 12/01/2014 10:49 AM, Lars-Peter Clausen wrote:
The driver creates the mapping by calling irq_of_parse_and_map(), so it
also has to dispose the mapping. But the easy way out is to simply use
platform_get_irq() instead of irq_of_parse_map(). In this case the
mapping is not managed by the device
On 12/01/2014 10:49 AM, Lars-Peter Clausen wrote:
The driver creates the mapping by calling irq_of_parse_and_map(), so it
also has to dispose the mapping.
I agree with Markus, this does seem weird. It sounds like you're saying
that irq_of_parse_and_map() and devm_request_irq() are incompatibl
On 12/01/2014 01:56 PM, Arnd Bergmann wrote:
All other drivers that call irq_of_parse_and_map and pass that into
devm_request_irq just never unmap, and their interrupts are already
mapped by the platform code, so I think it's not even a leak.
Does this mean that fsl_ssi.c should not be calling
On 12/01/2014 02:01 PM, Arnd Bergmann wrote:
>Does this mean that fsl_ssi.c should not be calling
>irq_of_parse_and_map? How else should it get the IRQ?
platform_get_irq()
Ok, but that function also calls irq_create_of_mapping(). So it still
appears that the only way to get the IRQ is to ma
On 12/01/2014 02:40 PM, Fabio Estevam wrote:
>Hm... that's new. But it's not really a driver issue anymore if it is done
>in the core. So I guess for now just use platform_get_irq() and ignore the
>other issue.
With the suggested changes below, the removal of the driver works fine on a mx6:
On Thu, Dec 3, 2015 at 6:08 AM, <> wrote:
> From: Madalin Bucur
>
> This patch series adds the Ethernet driver for the Freescale
> QorIQ Data Path Acceleration Architecture (DPAA).
Please fix your git-send-email configuration, so that your emails are
formatted properly. This is the From: header
On Sun, Dec 20, 2015 at 2:30 PM, Maciej S. Szmigiero
wrote:
> SACNT register should be marked volatile since
> its WR and RD bits are cleared by SSI after
> completing the relevant operation.
> This unbreaks AC'97 register access.
>
> Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and res
Maciej S. Szmigiero wrote:
+ regmap_write(regs, CCSR_SSI_SACNT,
+ ssi_private->regcache_sacnt);
So I'm not familiar with all of the regcache features, but I understand
this patch. I was wondering if it makes sense to write the same exact
value that was read previo
Maciej S. Szmigiero wrote:
Mark some registers precious since their
reads have side effects (like clearing flags).
Signed-off-by: Maciej S. Szmigiero
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
in AC'97 mode.
Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support MEGA
Fast")
Signed-off-by: Maciej S. Szmigiero
Acked-by: Timur Tabi
I'm surprised that we're actually encouraging drivers to contain
h
Mark Brown wrote:
That's possibly problematic because the flat cache will of necessity end
up with defaults (of 0 from the kzalloc()) for all the registers.
You'll still have default values in the cache, though some of the
behaviour around optimising syncs does change without them explicitly
give
Mark Brown wrote:
regcache handles this fine, it's perfectly happy to just go and allocate
the cache as registers get used (this is why the code that's doing the
allocation exists...). What is causing problems here is that the first
access to the register is happening in interrupt context so we
Mark Brown wrote:
Quite possibly (it'll be more efficient and it's intended for such use
cases) but as I said in my other reply that then has the issue that it
implicitly gives default values to all the registers so I'd expect we
still need to handle the cache initialisation explicitly (or
altern
Lothar Waßmann wrote:
- select SND_SOC_FSL_SSI
+ select SND_SOC_FSL_SAI if SOC_IMX6UL
+ select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX
I don't think this is compatible with a multiarch kernel.
___
Linuxppc-dev mailin
Lothar Waßmann wrote:
Why? If more than one of the IMX6 SoCs are selected, both interfaces
may be selected at the same time without any harm.
Oh, ok. I thought the point behind the patch was that you *souldn't*
enable the the SSI driver on an i.MX6UL.
Maciej S. Szmigiero wrote:
+static const struct regmap_config fsl_ssi_regconfig_imx21 = {
+ .max_register = CCSR_SSI_SRMSK,
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .val_format_endian = REGMAP_ENDIAN_NATIVE,
+ .num_reg_defaults_raw = CCSR_SSI_SR
Maciej S. Szmigiero wrote:
This is because (at least according to the datasheet) imx21-class SSI
registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so
reading them for cache initialization may not be safe.
Also, a "MXC 91221 only" comment before these regs in FSL tree
(drivers/mxc/ssi/re
Maciej S. Szmigiero wrote:
On 17.01.2016 15:16, Maciej S. Szmigiero wrote:
On 17.01.2016 06:16, Timur Tabi wrote:
Maciej S. Szmigiero wrote:
This is because (at least according to the datasheet) imx21-class SSI
registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so
reading them for
Alexander Stein wrote:
- schedule_timeout(2);
+ schedule_timeout(msecs_to_jiffies(2));
NACK.
So I don't remember why I wrote this code, but I don't think I was
expecting it to be 2ms. Instead, I think I just wanted it to be some
delay, but I believed that schedul
Alexander Stein wrote:
Okay, I was just wondering why the timeout is dependant on the timer tick.
That didn't seem obvious to me.
Rethinking about this, I would rather replace those lines with msleep instead.
What's wrong with leaving it as-is? The code is five years old, and
Freescale/NXP ba
Andreas Schwab wrote:
> + return !!(ssi_private->dai_fmt & SND_SOC_DAIFMT_AC97) ==
> + SND_SOC_DAIFMT_AC97;
This is never true.
I think the right parenthesis should be at the end of the expression.
Grant Likely wrote:
Okay, I've changed my mind. :-) I'll back off a bit from this extreme and
call it:
sound/soc/fsl/soc-of-simple.c
That works for me.
And please don't forget to CC: me on any discussion involving sound/soc/fsl.
--
Timur Tabi
Linux Kernel Develo
Jon Smirl wrote:
> I'm just going to ignore 2.6.27 and wait for 2.6.28.
2.6.28 might have ASoC V2, or at least portions of it. You might want to just
port your driver to ASoC V2 like I did and not worry about it.
--
Timur Tabi
Linux kernel developer at F
urious, if U-Boot already programs the speed, why does
the driver program it again?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Wolfgang Grandegger wrote:
> I know but we still need an algorithm for MPC52xx and MPC82xx as well.
That's true, but I still think hard-coding values of DFSR and FDR in the device
tree is not a good way to do this.
--
Timur Tabi
Linux kernel developer at F
#x27;m not going
to have time to update the CS4270 driver to a new-style interface before the
2.6.27 window closes.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wed, Jul 30, 2008 at 5:54 AM, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> Hi Timur,
>
>> So my conclusion is that specifying an I2C node in the device tree *requires*
>> that the driver be new-style. Is there any way we can fix this? I'm not
>> going
&
sible to combine 5200A and 5200B into one table/algorithm, but I
don't think you can combine it with the 8xxx table.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
.data =
> fsl_i2c_mpc8xxx_div2_set_freq, },
> {.compatible = "fsl,mpc8544-i2c", .data =
> fsl_i2c_mpc8xxx_div3_set_freq, },
So we need to update this table every time there's a new SOC? All 83xx, 85xx,
and 86xx SOCs use the same table. I'd prefer an implemen
Wolfgang Grandegger wrote:
> We could add a property "source-clock-divider = <2/3>" if it's needed!?
How about we just get U-Boot to put the core frequency in the device tree?
--
Timur Tabi
Linux kernel developer at Freescale
a good solution (assuming that it is a board or SoC
> characteristic, and not just a choice that the driver has the option
> of making on it's own).
I was going to suggest the actual clock frequency of the I2C device. It would
be value of gd->i2c1_clk or gd->i2c2_clk from U-Boot. The actual
401 - 500 of 1098 matches
Mail list logo
