Rafael J. Wysocki wrote:
I would be interested in understanding what exactly the flow is in that
situation, so care to educate me? What does the driver do to trigger
this and what exactly does happen in response to that?
I only just learned some of this myself, so I'm no expert. My
unders
Westerberg, Mika wrote:
If you happen to have pin controller/mux driver that drives that hardware,
I'm sure your pinmux functions gets called.
Actually, I don't think they do. On a device-tree system, the functions
get called automatically by the pinctrl layer when it parses the device
tree.
On 04/24/2014 06:58 AM, Westerberg, Mika wrote:
>No, that's my point. I was expecting the pinmux functions of the
>pinctrl driver are used by ACPI, but apparently they aren't, and
>that's why I'm asking.
Which functions?
The functions in struct pinmux_ops, like get_function_groups. Will
t
Westerberg, Mika wrote:
Typically this is done by the boot firmware (BIOS in this case). So the OS
doesn't need to deal with that.
AFAICT ACPI doesn't know anything about pin muxing.
In that case, would it be correct to say that a Linux pinctrl driver for
an ACPI-only platform should not defi
Westerberg, Mika wrote:
>That is, when the kernel parses the ASL, and it seems a command to
>configure pin #3 to function #4, it calls the local pinctrl driver to do
>that?
I'm not aware of ASL code that allows you to do that. Do you have examples?
No, that's my point. I was expecting the p
Linus Walleij wrote:
> All of our GPIOs have a
>pinmux on them, and so if you want to use the pin for the non-default
>functionality, you need to configure the mux. Isn't that supposed to happen
>with the through the pinctrl driver? That is, when the kernel parses the
>ASL, and it seems a comm
Westerberg, Mika wrote:
It doesn't do any pin control nor muxing and I'm not sure if it is
required. Can you elaborate why you think pin muxing is required with
GpioIo/GpioInt resources?
How are the pin muxes normally configured in ACPI? All of our GPIOs
have a pinmux on them, and so if you w
Mathias Nyman wrote:
Helper functions to translate the ACPI GpioIO and GpioInt resources to
linux gpio numbers can be found in gpio/gpiolib-acpi.c together with
other ACPI and gpio related helper functions.
Does this also cover pin control and pin muxing? Sorry, but I sometimes
I get confuse
On 04/15/2014 05:01 AM, Mathias Nyman wrote:
This device will only be used on an ACPI system, right? And isn't ACPI
supposed to hide all the pinctrl programming from the OS? I thought
that was the whole point behind ACPI and the reason why ARM64 isn't
going to use device trees.
This was my
On 04/14/2014 02:52 AM, Mathias Nyman wrote:
This was the conclusion we reached after some discussion with Linus W.
Initially this was just a GPIO driver, but Linus correctly spotted that
Baytrail has many pinctrl-like features (like pin muxing, etc) that we
might need to address in the future
On Tue, Jun 18, 2013 at 6:33 AM, Mathias Nyman
wrote:
>
> Pins may be muxed to alternate function instead of gpio by firmware.
> This driver does not touch the pin muxing and expect firmare
> to set pin muxing and pullup/down properties properly.
>
> Signed-off-by: Mathias Nyman
> ---
> drivers/
On 04/08/2014 09:18 AM, Timur Tabi wrote:
Back in July, Qualcomm submitted a patch that added this information
into the device tree:
http://marc.info/?t=13718516613&r=1&w=2
However, this was rejected. Now it appears that this information is
again being added to the device tree,
On 04/08/2014 08:46 AM, Ivan T. Ivanov wrote:
>This patch adds that same exact information into the device tree. Why
>are we duplicating that information? Why add it to the device tree when
>it's already in the driver (and already working).
Probably. It was my natural way of thinking. Pin ha
Ivan T. Ivanov wrote:
>I'm confused by this. Isn't this information already defined in the
>pinctrl-msm8x74.c driver?
>
>static const char * const blsp_spi8_groups[] = {
> "gpio45", "gpio46", "gpio47", "gpio48"
>};
I am not sure that I understand the question. This is one of
possible ways t
On Thu, Feb 6, 2014 at 9:28 AM, Ivan T. Ivanov wrote:
> + msmgpio: pinctrl@fd51 {
> + compatible = "qcom,msm8974-pinctrl";
> + reg = <0xfd51 0x4000>;
> + gpio-controller;
> + #gpio-cells
On Thu, Feb 6, 2014 at 9:28 AM, Ivan T. Ivanov wrote:
> + spi8_default: spi8_default {
> + mosi {
> + pins = "gpio45";
> + function = "blsp_spi8";
> +
On Sun, Mar 2, 2014 at 8:42 PM, Xiubo Li wrote:
> For some CODEC drivers like who act as the MFDs children are ignored
> by this patch.
This makes no sense to me. Is there a comma missing, maybe?
Regardless, I think this patch description is too short.
--
To unsubscribe from this list: send the
;int' in declaration of
> 'console_initcall' [-Werror=implicit-int]
Acked-by: Timur Tabi
However, I wonder if it makes sense to have a console_initcall in a
module at all. Is it possible to load and use a console driver as a
module?
--
To unsubscribe from this list: send the line "unsubsc
Nicolin Chen wrote:
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
+ } else {
+
Chen Guangyu-B42378 wrote:
Without dual fifo support, handware underrun would occasionally
occur and then two audio channels would physically swap. This could
be easily reproduced in low bus frequency situation, while it would
be better if we enable dual fifo.
Ok.
ACK.
--
To unsubscribe from
Nicolin Chen wrote:
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
Have you measured any real performance gain with this patch? I
considered adding dual-FIFO support when I originally wrote this
Lars-Peter Clausen wrote:
>Maybe I've been out of the loop for too long, but why is that a particular
>problem with this driver?
It is usually something you'd want to check in general to make sure that you
don't have multiple device that access the same iomem region at the same time.
I under
Lars-Peter Clausen wrote:
>>+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>+sai->base = devm_ioremap_resource(&pdev->dev, res);
>
>Why not use of_iomap()?
Because it won't check for conflicting resource regions.
Maybe I've been out of the loop for too long, but why is that a
Xiubo Li wrote:
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ sai->base = devm_ioremap_resource(&pdev->dev, res);
Why not use of_iomap()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Wed, Oct 2, 2013 at 9:27 AM, Jan Kara wrote:
> CC: Timur Tabi
> Signed-off-by: Jan Kara
> ---
This seems okay, but I don't have access to hardware at the moment to test it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Tue, Sep 24, 2013 at 8:06 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, linux-next builds (powerpc allmodconfig)
> fail like this:
>
> drivers/tty/ehv_bytechan.c:362:1: error: type defaults to 'int' in
> declaration of 'console_initcall' [-Werror=implicit-int]
>
> C
On Wed, Aug 21, 2013 at 6:31 PM, Scott Wood wrote:
>
>> > Other than "this is how the existing binding works and we're not going
>> > to break compatibility", it allows the OS more flexibility to choose
>> > whether to bind to controllers or directly to the channels. Sometimes a
>> > channel will
might want to look at the code reviews for spin_event_timeout()
>> > on the linuxppc-dev mailing list, back in March 2009.
>> >
> Sure. Any pointers? Otherwise I'll go digging around the archives.
https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-March/thread.html
--
Timur Ta
n't know if it
applies. Apparently, udelay() includes its own call to cpu_relax(). Is
it possible that cpu_relax() is a "lightweight" yield, compared to sleeping?
FYI, you might want to look at the code reviews for spin_event_timeout()
on the linuxppc-dev mailing list, back in March 20
On Tue, Jul 30, 2013 at 7:38 AM, Arpit Goel wrote:
>
> +#ifndef spin_event_timeout
> +/**
Why don't you make PowerPC also use this generic version? It seems
silly to have two virtually identical implementations of this macro?
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Wed, Jul 31, 2013 at 2:16 AM, Stephen Boyd wrote:
>
> What do you do here if jiffies aren't incrementing (i.e
> interrupts are disabled). The time_before() check won't work
> there and it would be nice if we were able to use this in such
> situations. I think powerpc gets around this by reading
R("Alexander Popov ");
+MODULE_DESCRIPTION("MPC512x LocalPlus FIFO device driver");
+MODULE_LICENSE("GPL");
aren't these usually at the end of the source for quick lookup?
Yes, and it should be "GPL v2" also.
--
Timur Tabi
--
To unsubscribe from this
On Wed, Jun 12, 2013 at 1:31 PM, Scott Wood wrote:
>
> I'm not sure it's stable material if this is something that has never
> worked...
>
> The device tree binding will also need to be fixed to note the difference in
> "reg" between "fsl,gianfar-mdio" and "fsl-gianfar-tbi" -- and should give an
>
27;t had a chance to review the patch in detail, but I can tell you
that breaking compatibility with older device trees is unacceptable. You
need to add some code, even if it's an ugly hack, to support those trees.
--
Timur Tabi
--
To unsubscribe from this list: send the line "unsubscribe
, it
just masks the warnings!
--
Timur Tabi
--
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/
her times
you use real I/O memory for the framebuffer, then you should have two
different pointers.
--
Timur Tabi
--
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.
em *)
> +dma_alloc_coherent(dev, PAGE_ALIGN(fbsize),
> + &drvdata->fb_phys,
> + GFP_KERNEL);
I think this is wrong. At least, it would be on PowerPC.
dma_alloc_coherent() allocates regular RAM, not
&tft_access);
This is okay, but just FYI, you could instead have just used be32_to_cpup().
--
Timur Tabi
--
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.kern
On Thu, May 30, 2013 at 5:04 PM, Arnd Bergmann wrote:
>
> This is probably missing barriers, and is wrong on systems on which
> the endianess of the device is different from the CPU.
I suggest what was done in fsl_ssi.c:
#ifdef PPC
#define read_ssi(addr) in_be32(addr)
#define write_
and time if you also make this array "static",
>> > otherwise the compiler will build the array every time this function is
>> > called.
> No, *const* specifier is enough to not build this array every time.
> It will be put into the .const section.
Ok. Now that
r will build the array every time this function is
called.
--
Timur Tabi
Software Developer at Calxeda
--
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-
On Wed, May 29, 2013 at 10:51 AM, Mark Langsdorf
wrote:
>
> {
> - const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
> + unsigned long timing[] = { 5, 100, 500};
You didn't address my comments the last time you posted this. I'll
post them again:
Why are you dro
Libo Chen wrote:
when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen
Acked-by: Timur Tabi
Thanks for catching this.
--
Timur Tabi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Wed, May 1, 2013 at 4:34 PM, Mark Langsdorf
wrote:
>
> - const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
> + unsigned long timing[] = { 5, 100, 500};
Why are you dropping the 'const'?
Assuming it works, this should be more efficient:
static const unsigned l
On Wed, Apr 17, 2013 at 9:57 AM, Grant Likely wrote:
>
>> I really preciate if you can spend some times to review this patch.
>
> Applied, thanks.
Pff. Why do I bother?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
Tang Yuantian-B29983 wrote:
It was placed on ELSE statement originally, I moved it to IF statement.
Why is it so wrong?
Because the logic of the comment applies to the else-condition, not the
if-condtion.
--
Timur Tabi
--
To unsubscribe from this list: send the line "unsubscribe
Tang Yuantian-B29983 wrote:
>On Tue, Apr 9, 2013 at 10:36 PM, wrote:
> >
> >+ /* Found it! return success */
>
>I'm pretty sure this comment is in the wrong place.
It is not perfect, but acceptable.
Like I said, I'm pretty sure it&
On Tue, Apr 9, 2013 at 10:36 PM, wrote:
>
> + /* Found it! return success */
I'm pretty sure this comment is in the wrong place.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel wrote:
> > + panic("\n");
>
> A kernel panic seems like an over-reaction to an access violation.
We have no way to determining what code caused the violation, so we
can't just kill the process. I agree it seems like overkill, but what
else shoul
From: Timur Tabi
Timur Tabi no longer works for Freescale, so update the email address and
status for all of his maintained projects.
Also mark the QE library as orphaned, for lack of interest in maintaining
it.
The CS4270 driver is marked as "Odd Fixes" because appropriate hard
tree for the largest LIODN, and
make the array dynamically sized.
--
Timur Tabi
Linux kernel developer at Freescale
--
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/
t liodn, struct fsl_dma_domain *dma_domain,
> + u32 val)
> +{
> + int ret = 0, i;
> +
> + spin_lock(&iommu_lock);
> + if (!dma_domain->subwin_cnt) {
> + ret = pamu_update_paace_stash(liodn, 0, val);
> +
Koen Kooi wrote:
> And as Pantelis mentioned before, I really don't want my users to change the
> bootloader whenever they add a new LED.
Well, U-Boot does allow you to manipulate the device tree from the
command-line, but I understand that this feature doesn't work that well.
provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU
> API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c)
> has been derived from the work done by Ashish Kalra and Timur Tabi
> (ti...@freescale.com).
>
>
> Signed-off-by: Varun Sethi
A good chunk o
; /* cache to stash to: L1,L2,L3 */
> };
>
> struct iommu_domain {
> @@ -60,6 +88,14 @@ struct iommu_domain {
> enum iommu_attr {
> DOMAIN_ATTR_MAX,
> DOMAIN_ATTR_GEOMETRY,
> + /* Set the IOMMU hardware stashing
> + * parameters.
> + */
I don't see patch 2/4 posted anywhere.
--
Timur Tabi
Linux kernel developer at Freescale
--
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/
Scott Wood wrote:
> For hypercalls and other paravirt. That's the point -- they're not
> kernel headers. They're guest API headers.
Well, IMHO, guest API != user-space. Maybe we should have a parallel
mechanism to uapi to make the kvm guest header files available.
n't know much about KVM internals, so I
just don't understand why KVM guests need to have access to these kernel
header files as if they're user header files. The guests are still Linux
kernels (or other OSes that think they're running as privileged code).
--
Timur Tabi
Li
file, I think of a
user-space application that calls ioctls. I know that KVM guest kernels
run as user-space processes, but that does not seem like a reason to
combine all of the header files that the KVM guest kernel needs with
"real" user-space header files.
--
Timur Tabi
Linux kerne
function 'of_address_to_resource'
Reported-by: Randy Dunlap
Signed-off-by: Timur Tabi
---
drivers/net/phy/mdio-mux-mmioreg.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-mmioreg.c
b/drivers/net/phy/mdio-mux-mmioreg.c
index 098239a..
function 'of_address_to_resource'
Signed-off-by: Timur Tabi
---
drivers/net/phy/mdio-mux-mmioreg.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-mmioreg.c
b/drivers/net/phy/mdio-mux-mmioreg.c
index 098239a..9061ba6 100644
--- a/driv
ix. I'll post a
patch in a minute. Can you test it and let me know (e.g. via an ACK)
whether it works?
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
Timur Tabi wrote:
So when Kbuild creates vmlinux.bin, what does it do besides extract the PT_LOAD
segment?
Never mind, I was doing something stupid which was trashing my in-memory copy of
vmlinux.bin.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send
01 9c 7f e3 fb 78 4b d7 b0 75
32 bytes @ 4230:
1f 8b 08 08 b7 e7 7a 44 00 03 62 75 73 79 62 6f
78 2d 31 2e 31 2e 33 2e 69 6d 67 00 ec 5d 7d 74
So when Kbuild creates vmlinux.bin, what does it do besides extract the PT_LOAD
segment?
--
Timur Tabi
Linux kernel developer at Freescale
--
To u
study, I'll discuss them with you later.
Zhang and Dan,
What's the status on this patch? Will it make 2.6.25?
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
t;codec_clk_direction = SND_SOC_CLOCK_OUT;
machine_data->cpu_clk_direction = SND_SOC_CLOCK_IN;
} else if (strcasecmp(sprop, "rj-master") == 0) {
___
Alsa-devel mailing list
[EMAIL PROTECTED]
http://mailman.alsa-project.org/mai
ike this:
__asm__ ("call foo");
Oh and why are we preferring the use of __asm__ over asm? They both
seem valid. Should we be recommending one over the other?
It's a toss-up. Depending on the architecture, one version has about 60% usage
and the other about 40%. I thou
checkpatch.pl thinks that __asm__ is a function name, so it complains about
a space between the function name and a parenthesis when it sees
"__asm__ ("mov ax,bx")".
This change will also encourage developers to use '__asm__' instead of 'asm'.
Sig
e U-Boot can determine the settings of some board jumpers and
modify the device tree accordingly. The instructions on how to modify the
device tree would be embedded in the tree itself. I can't support this feature
if the kernel calls par_io_config_pin() regardless of what's in
d in the device tree. So it makes sense to
put the pin configurations in the device tree, too.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
Stephen Rothwell wrote:
+ tdm_ctrl[device_num]->ut_info->uf_info.tdm_tx_clk =
+ (char *) of_get_property(np, "fsl,tdm-tx-clk", NULL);
^
We don't normall put spaces here.
Since when?
--
Timur Tabi
Linux kernel d
void *private all over the place.
Any reason that won't work here?
Yes, that will work. Sorry, I should have thought of that myself, since I've
used that trick a number of times before.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line &q
A private data pointer in struct device_attribute allows the 'show' and 'store'
functions to access instance data. This handy in situations where the
driver_data and platform_data pointers of 'struct device' are already used
for other purposes.
Signed-off-by
Zach Brown wrote:
Timur Tabi wrote:
I'm running checkpatch.pl (dated 10/17), and it complains about this line:
crc = __be32_to_cpu(* ((__be32 *) ((void *) firmware + calc_size)));
Well, that is a bit of a stinker. Maybe it could be reworked a little
to make it easier for human
I'm running checkpatch.pl (dated 10/17), and it complains about this line:
crc = __be32_to_cpu(* ((__be32 *) ((void *) firmware + calc_size)));
the message I get is:
ERROR: need space before that '*' (ctx:BxW)
#721: FILE: arch/powerpc/sysdev/qe_lib/qe.c:527:
+ crc = __be32_to_cpu(* ((__be
Greg KH wrote:
I'd recommend using the non-blocking mode, that way, when userspace
finally gets running, it can handle the firmware events properly, and
your kernel code will have not timed out already.
Thanks Greg, that did the trick.
What the value of FW_ACTION_NOHOTPLUG? If I specify that
If my driver is compiled in-kernel (and I have module support turned
off), can I still use request_firmware()? If my driver is loaded before
the file system drivers are loaded, how can a user process copy the
firmware to the /sys/class/firwmare/.../data device?
-
To unsubscribe from this list
Krzysztof Halasa wrote:
Timur Tabi <[EMAIL PROTECTED]> writes:
There is no such thing as bit-order.
Yes, there is. You need to read the article at
http://www.linuxjournal.com/article/6788. Explains what it means for
bits to be in one order versus another. This is from the perspect
is always consistent with regards to bit order)
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
P
ing to have to assume that they do match.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andreas Schwab wrote:
Timur Tabi <[EMAIL PROTECTED]> writes:
The CPU shift operation, yes. I'm talking about shift operations on
external memory-mapped devices.
That is a property of how the device is wired to the bus. The cpu will
always put a value of 128 on the bus such that
le endian means and that is how shift operations can
work fine on the CPU.
The CPU shift operation, yes. I'm talking about shift operations on external
memory-mapped devices.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe
could be
used to test bit-endianness, but I guess it can't.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
f the
processor is BIG_ENDIAN?
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read t
; defined(LITTLE_ENDIAN_BITFIELD))
#error "This CPU architecture is not supported"
#endif
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jan Engelhardt wrote:
On Oct 5 2007 13:27, Timur Tabi wrote:
What's the difference between __LITTLE_ENDIAN and __LITTLE_ENDIAN_BITFIELD? Can
someone give me an example when __BIG_ENDIAN and __LITTLE_ENDIAN_BITFIELD would
both be defined simultaneously?
standard x86:
---LSB-- ---2SB-- -
What's the difference between __LITTLE_ENDIAN and __LITTLE_ENDIAN_BITFIELD?
Can someone give me an example when __BIG_ENDIAN and __LITTLE_ENDIAN_BITFIELD
would both be defined simultaneously?
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the
In the case of
85xx, the FDT contains entries for each DMA device (typically 2), and the
entries contain sub-entries for each DMA channel as well as the address of the
register sets for each channel.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line &
need?
I know a lot of people don't like 'select', but I prefer it over 'depends on'.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Russell King wrote:
You might also want to fix the other stupidity with this. See my message
on this very subject ("select is evil: another reason" from May 9th on lkml.)
I submitted a patch yesterday which includes both fixes. Apparently, it's
already in the -mm tree.
-
To unsubscribe from
Simon Horman wrote:
I agree. I had thought a little about a kconfig fix. Though I'm
wondering if removing the warning will lead to oodles of dangling
symbols and invalid checks over time.
I'm pretty sure it will. Perhaps we need to have a lint for Kconfig?
-
To unsubscribe from this list: se
The UCC_GETH Kconfig option in drivers/net/Kconfig had a line to select
the UCC_FAST option is arch/powerpc/sysdev/qe_lib/Kconfig, which is only used
on PowerPC builds. On other architectures, this would generated a warning.
The fix is to have UCC_FAST depend on UCC_GETH.
Signed-off-by: Timur
is out later today.
I chose the first method because I wanted each individual UCC device driver to select
UCC_FAST or UCC_SLOW as appropriate, so that I wouldn't have to update
arch/powerpc/sysdev/qe_lib/Kconfig every time we add a new UCC driver. Oh well.
--
Timur Tabi
Linux Kernel Develope
e this introduces the error:
commit 7d776cb596994219584257eb5956b87628e5deaf
Author: Timur Tabi <[EMAIL PROTECTED]>
Date: Mon Mar 12 15:40:27 2007 -0500
[POWERPC] QE: automatically select QE options
I have a dilemma, so I need help fixing this bug.
This particular patch is necessary because without it, select
ce ucc_geth is a standard Ethernet driver, it exists in drivers/net.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
If I were to write a non-USB audio device driver from scratch (for new hardware), what
interface would I use? Has ALSA become the official Linux kernel audio subsystem? Is
there a specific device driver I should use as a sample?
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To
Steve Wise wrote:
Aren't the older commits in another git tree? Like maybe
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git
git-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git works
for me, so that can't be it.
--
Timur
so it looks like something is wrong on
the server.
Isn't 2.6.11 around the time that Linus moved to git? Maybe the server can't find tag for
the initial check-in of the code.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscr
Kyle McMartin wrote:
git-clone \
http://ftp.kernel.org/pub/scm/linux/kernel/git/$user/$tree
Works fine.
Thanks! That works. git.kernel.org is still down, but this will do in the
meantime.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line
Timur Tabi wrote:
$ git-clone http://git.kernel.org/pub/scm/git.git
Actually, I meant http://git.kernel.org/pub/scm/git/git.git, but the problem
still exists.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
501 - 600 of 754 matches
Mail list logo
