Pending October patches

Pending October patches

[Dirk Behme]

Hi,

my list of pending OMAP patches for October 2006:

1. [PATCH] ARM: OMAP: Fix warning no IRQF_TRIGGER set_type 
function for IRQ 353
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008119.html

2. ARM: OMAP2: fix apollon gpmc initialization
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008132.html

3. Git tree updated to 2.6.19-rc2
(Fix BUG in omap1_mbox_enable_irq)
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008148.html

4. [PATCH] ARM: OMAP: Register tsc2102 on Palm Tungsten E
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008155.html

5. [patch 2.6.19-rc3-omap] gpio init section cleanups
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008175.html

6. [patch 2.6.19-rc3-omap] gpio object shrinkage, cleanup
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008176.html

7. [PATCH]: Fixing blksz_bits calling inside 
drivers/mmc/mmc.c and drivers/mmc/omap.c
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008183.html

8. [PATCH] ARM: OMAP: Fix warnings in plat-omap
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008184.html

9. [PATCH] ARM: OMAP: Fix warnings in plat-omap/dsp
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008185.html

10. [PATCH] ARM: OMAP: Fix warning in mach-omap1
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008187.html

11. [PATCH] ARM: OMAP: Fix warning in mach-omap2
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008188.html

12. [PATCH] ARM: OMAP: Fix warning in omap-keypad
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008190.html

13. [PATCH] ARM: OMAP: Fix warnings in ads7846
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008191.html

14. [PATCH] ARM: OMAP: Fix Amstrad Delta omap-keypad usage.
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008194.html

15. [PATCH] ARM: OMAP: Remove struct pt_regs from 
omap_irda_irq()
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008195.html

16. [PATCH] ARM: OMAP: Remove struct pt_regs from 
lcdc_irq_handler()
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008196.html

17. [PATCH] ARM: OMAP: Remove struct pt_regs from menelaus_irq()
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008197.html

18. [PATCH] ARM: OMAP1: Fix CONFIG_DEBUG_LL
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008201.html

19. [PATCH] PalmZ71 extra brace fix
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008204.html

20. [PATCH 1/3] Palm Tungsten|T support
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008206.html

21. [PATCH 2/3] Palm Tungsten|T LCD
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008207.html

22. [PATCH 3/3] Palm Tungsten|T defconfig
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008208.html

23. [PATCH] Palm Tungsten|T LEDs
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008219.html

24. [PATCH] ARM: OMAP: fix apollon USB device support
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008220.html

25. [PATCH] omap-hw: Fix build breakage
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008229.html

26. [PATCH] ARM: OMAP: Make AIC23 sound work again
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html

27. [PATCH] [USB/CORE/USB.C] Fixes autosuspend and auto_pm 
fields missing
http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008234.html

A lot of stuff this month, was somewhat tricky to track. So 
as usual, please correct if anything missing, if anything is 
wrong, outdated or already applied. Are there any older 
patches pending?

Cheers

Dirk

Re: Pending October patches

[tony]

Hi,

Thanks again for the list. I've pushed most of them, some patches
need minor fixes, see below. Again, please verify your patches got
applied OK.

I've also updated to -rc4. BTW, I probably won't have email access 
until Tuesday.

* Dirk Behme <dirk.behme@googlemail.com> [061101 18:34]:
> Hi,
> 
> my list of pending OMAP patches for October 2006:
> 
> 1. [PATCH] ARM: OMAP: Fix warning no IRQF_TRIGGER set_type 
> function for IRQ 353
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008119.html

Pushed.
 
> 2. ARM: OMAP2: fix apollon gpmc initialization
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008132.html

Pushed.
 
> 3. Git tree updated to 2.6.19-rc2
> (Fix BUG in omap1_mbox_enable_irq)
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008148.html

Pushed.
 
> 4. [PATCH] ARM: OMAP: Register tsc2102 on Palm Tungsten E
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008155.html

Pushed.
 
> 5. [patch 2.6.19-rc3-omap] gpio init section cleanups
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008175.html

Pushed.
 
> 6. [patch 2.6.19-rc3-omap] gpio object shrinkage, cleanup
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008176.html

Pushed. We should split this to omap1- and omap2-specific gpio.c that
uses common gpio.c to get rid of the ifdefs.
 
> 7. [PATCH]: Fixing blksz_bits calling inside 
> drivers/mmc/mmc.c and drivers/mmc/omap.c
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008183.html

Pushed Dirk's version that also fixes the warning.
 
> 8. [PATCH] ARM: OMAP: Fix warnings in plat-omap
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008184.html

Pushed.
 
> 9. [PATCH] ARM: OMAP: Fix warnings in plat-omap/dsp
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008185.html

I think the unlikely() is unlikely necessary for init and sysfs?
 
> 10. [PATCH] ARM: OMAP: Fix warning in mach-omap1
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008187.html

Same here, also missing space after if.
 
> 11. [PATCH] ARM: OMAP: Fix warning in mach-omap2
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008188.html

Pushed.
 
> 12. [PATCH] ARM: OMAP: Fix warning in omap-keypad
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008190.html

Pushed.
 
> 13. [PATCH] ARM: OMAP: Fix warnings in ads7846
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008191.html

Is the unlikely() needed here?
 
> 14. [PATCH] ARM: OMAP: Fix Amstrad Delta omap-keypad usage.
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008194.html

Pushed.
 
> 15. [PATCH] ARM: OMAP: Remove struct pt_regs from 
> omap_irda_irq()
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008195.html

Pushed.
 
> 16. [PATCH] ARM: OMAP: Remove struct pt_regs from 
> lcdc_irq_handler()
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008196.html

Pushed.
 
> 17. [PATCH] ARM: OMAP: Remove struct pt_regs from menelaus_irq()
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008197.html

Pushed.
 
> 18. [PATCH] ARM: OMAP1: Fix CONFIG_DEBUG_LL
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008201.html

Pushed.
 
> 19. [PATCH] PalmZ71 extra brace fix
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008204.html

Pushed.
 
> 20. [PATCH 1/3] Palm Tungsten|T support
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008206.html

Please replace spaces with tabs according to Documentation/CodingStyle.
 
> 21. [PATCH 2/3] Palm Tungsten|T LCD
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008207.html

Please replace spaces with tabs according to Documentation/CodingStyle.
 
> 22. [PATCH 3/3] Palm Tungsten|T defconfig
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008208.html

Depends on previous patches.
 
> 23. [PATCH] Palm Tungsten|T LEDs
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008219.html

This too.
 
> 24. [PATCH] ARM: OMAP: fix apollon USB device support
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008220.html

Pushed.
 
> 25. [PATCH] omap-hw: Fix build breakage
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008229.html

Pushed.
 
> 26. [PATCH] ARM: OMAP: Make AIC23 sound work again
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html

Hmmm, I think there were some comments on this hack on LKML when we
merged the driver?
 
> 27. [PATCH] [USB/CORE/USB.C] Fixes autosuspend and auto_pm 
> fields missing
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008234.html

Sounds like this is getting fixed in the mainline tree.
 
> A lot of stuff this month, was somewhat tricky to track. So 
> as usual, please correct if anything missing, if anything is 
> wrong, outdated or already applied. Are there any older 
> patches pending?

Yes it's been a busy patch month :) I cannot think of any patches we've
missed.

Regards,

Tony

Re: Pending October patches

[Dirk Behme]

tony@atomide.com wrote:
>>9. [PATCH] ARM: OMAP: Fix warnings in plat-omap/dsp
>>http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008185.html
> 
> I think the unlikely() is unlikely necessary for init and sysfs?

Thanks for review! It was just a mechanical search & replace 
without any look to the functions itself. Will update this 
and the others soon.

>>26. [PATCH] ARM: OMAP: Make AIC23 sound work again
>>http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html
> 
> Hmmm, I think there were some comments on this hack on LKML when we
> merged the driver?

Komal, what do you think here?

Anybody aware of someone working on a better solution? Any 
link to the LKML discussion about this?

Best regards

dirk

Re: Pending October patches

[Komal Shah]

--- Dirk Behme <dirk.behme@googlemail.com> wrote:

> tony@atomide.com wrote:
> >>9. [PATCH] ARM: OMAP: Fix warnings in plat-omap/dsp
>
>>http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008185.html
> > 
> > I think the unlikely() is unlikely necessary for init and sysfs?
> 
> Thanks for review! It was just a mechanical search & replace 
> without any look to the functions itself. Will update this 
> and the others soon.


Also, these patches doesn't put proper error return path, as we don't
know, if some userspace tool can't work if those sysfs files are not
created at probe.

> 
> >>26. [PATCH] ARM: OMAP: Make AIC23 sound work again
>
>>http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html
> > 
> > Hmmm, I think there were some comments on this hack on LKML when we
> > merged the driver?
> 
> Komal, what do you think here?
> 
> Anybody aware of someone working on a better solution? Any 
> link to the LKML discussion about this?
> 

Few links:

http://lkml.org/lkml/2006/8/2/138
http://lkml.org/lkml/2006/8/5/23
http://lkml.org/lkml/2006/7/31/366
http://linux.omap.com/pipermail/davinci-linux-open-source/2006-October/001332.html

on google following keywords can help

site:lkml.org/lkml Komal Shah OMAP I2C

---Komal Shah
http://komalshah.blogspot.com/


 
____________________________________________________________________________________
Get your email and see which of your friends are online - Right on the New Yahoo.com 
(http://www.yahoo.com/preview) 

I2C zero length transfers and SMBUS_QUICK, was: Pending October patches

[Dirk Behme]

 >Komal Shah wrote:
 >> --- Dirk Behme <dirk.behme@googlemail.com> wrote:
 >>>tony@atomide.com wrote:
>>>>26. [PATCH] ARM: OMAP: Make AIC23 sound work again
>>
>>>http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html
>>>
>>>Hmmm, I think there were some comments on this hack on LKML when we
>>>merged the driver?
>>
>>Komal, what do you think here?
>>
>>Anybody aware of someone working on a better solution? Any 
>>link to the LKML discussion about this?
>>
> Few links:
...
> http://linux.omap.com/pipermail/davinci-linux-open-source/2006-October/001332.html

Sounds to me a clean fix (new I2C stack?) will need some 
decades, if it comes at all. So, how to go one here?

Our hack to make things work on OMAP will not be accepted 
upstream. But staying with broken OMAP features only because 
(available) hack isn't acceptable in mainline doesn't sound 
like an option as well.

I personally vote for working OMAP ;)

Cheers

Dirk

Re: I2C zero length transfers and SMBUS_QUICK, was: Pending October patches

[Komal Shah]

--- Dirk Behme <dirk.behme@googlemail.com> wrote:


> >>Komal, what do you think here?
> >>
> >>Anybody aware of someone working on a better solution? Any 
> >>link to the LKML discussion about this?
> >>
> > Few links:
> ...
> >
>
http://linux.omap.com/pipermail/davinci-linux-open-source/2006-October/001332.html
> 
> Sounds to me a clean fix (new I2C stack?) will need some 
> decades, if it comes at all. So, how to go one here?
> 
> Our hack to make things work on OMAP will not be accepted 
> upstream. But staying with broken OMAP features only because 
> (available) hack isn't acceptable in mainline doesn't sound 
> like an option as well.
> 
> I personally vote for working OMAP ;)
> 

Yes, we need working OMAPs and I don't know if it already broke n770
too. Let's see what Tony thinks about maintaining this fix in OMAP tree.

---Komal Shah
http://komalshah.blogspot.com/


 
____________________________________________________________________________________
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates 
(http://voice.yahoo.com)

Re: I2C zero length transfers and SMBUS_QUICK, was: Pending October patches

[Arnaud Patard]

Hi,

Komal Shah <komal_shah802003@yahoo.com> writes:

> --- Dirk Behme <dirk.behme@googlemail.com> wrote:
>
>
>> >>Komal, what do you think here?
>> >>
>> >>Anybody aware of someone working on a better solution? Any 
>> >>link to the LKML discussion about this?
>> >>
>> > Few links:
>> ...
>> >
>>
> http://linux.omap.com/pipermail/davinci-linux-open-source/2006-October/001332.html
>> 
>> Sounds to me a clean fix (new I2C stack?) will need some 
>> decades, if it comes at all. So, how to go one here?
>> 
>> Our hack to make things work on OMAP will not be accepted 
>> upstream. But staying with broken OMAP features only because 
>> (available) hack isn't acceptable in mainline doesn't sound 
>> like an option as well.
>> 
>> I personally vote for working OMAP ;)
>> 
>
> Yes, we need working OMAPs and I don't know if it already broke n770
> too. Let's see what Tony thinks about maintaining this fix in OMAP tree.
>
hmm... well... while taking care of the n770 is nice, I'm not sure that
you should take it into account. 

Brief explanation : 
the current kernel is broken on the n770. It won't even build.

Long explanation :
There are some obvious breakages that are not fixed. For instance, look
at the omap-hw patch I sent. I have some other patches for the build but
the kernel is oopsing later in the boot stage when udev plays with the
uevents in the spi layer... And there are probably more breakages :(


Regards,
Arnaud

Broken N770, was: I2C zero length transfers and SMBUS_QUICK

[Dirk Behme]

Seems that this is the month of mail subject change ;)

Arnaud Patard (Rtp) wrote:
> Komal Shah <komal_shah802003@yahoo.com> writes:
>>Yes, we need working OMAPs and I don't know if it already broke n770
>>too. ...
>>
...
> the current kernel is broken on the n770. It won't even build.

Thanks for the hint! With patch previously sent
n770_defconfig should compile again.

However, still some warnings in omap-hw.c (unused
omap_nand_write_byte), retu-user.c, tahvo-user.c,
tahvo-usb.c (all my new friend "ignoring return value") and
sti-console.c ("value computed is not used").

> Long explanation :
> There are some obvious breakages that are not fixed. For instance, look
> at the omap-hw patch I sent. 

It is already applied.

> I have some other patches for the build but
> the kernel is oopsing later in the boot stage when udev plays with the
> uevents in the spi layer... And there are probably more breakages :(

Is there any way to test self compiled kernel on N770
without breaking flashed SW/image? Anything like download to
RAM, e.g. used by uboots TFTP download on OSK?

Regards

Dirk

Re: Broken N770, was: I2C zero length transfers and SMBUS_QUICK

[Arnaud Patard]

Dirk Behme <dirk.behme@googlemail.com> writes:

> Seems that this is the month of mail subject change ;)

hehe :)

>
> Arnaud Patard (Rtp) wrote:
>> Komal Shah <komal_shah802003@yahoo.com> writes:
>>>Yes, we need working OMAPs and I don't know if it already broke n770
>>>too. ...
>>>
> ...
>> the current kernel is broken on the n770. It won't even build.
>
> Thanks for the hint! With patch previously sent
> n770_defconfig should compile again.

Sorry, that's wrong. I'm using an up2date git tree with origin
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git/
and I still need patches.

For instance : 
- there are still some users of pt_regs (patch sent some time ago)
- drivers/cbus/tahvo-usb.c is still using usb_otg.h. Patch not sent but
trivial to write.


>
> However, still some warnings in omap-hw.c (unused
> omap_nand_write_byte),

hmm.. yeah. My fault :(

>  retu-user.c, tahvo-user.c,
> tahvo-usb.c (all my new friend "ignoring return value") and
> sti-console.c ("value computed is not used").
>
>> Long explanation :
>> There are some obvious breakages that are not fixed. For instance, look
>> at the omap-hw patch I sent.
>
> It is already applied.
>
>> I have some other patches for the build but
>> the kernel is oopsing later in the boot stage when udev plays with the
>> uevents in the spi layer... And there are probably more breakages :(
>
> Is there any way to test self compiled kernel on N770
> without breaking flashed SW/image? Anything like download to
> RAM, e.g. used by uboots TFTP download on OSK?

yes, there is. That's what I'm using ^^

./flasher-2.0 -l -b -k <my_kernel>

But if you want to go a little bit further than the first lines of the
linuxrc file, you have to reintroduce the ioctl MEMSETOOBSEL in
mtdchar.c because the dsme/bme/cal-tools/libcal and friends from nokia
are using it. Unfortunately, when they're failing, they reboot your
device.
[ Playing with the r&d flags from the flasher won't help as the tools are
 failing before reading them. ]

>
> Regards
>
> Dirk

Regards,
Arnaud

Re: Broken N770

[Dirk Behme]

Arnaud Patard (Rtp) wrote:
>>Thanks for the hint! With patch previously sent
>>n770_defconfig should compile again.
> 
> Sorry, that's wrong. I'm using an up2date git tree with origin
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git/
> and I still need patches.
> 
> For instance : 
> - there are still some users of pt_regs (patch sent some time ago)

Yes, but these are only warnings and they are already fixed 
by patch sent.

For drivers/usb/core/hub.c I had to use

http://linux.omap.com/pipermail/linux-omap-open-source/2006-November/008254.html

> - drivers/cbus/tahvo-usb.c is still using usb_otg.h. Patch not sent but
> trivial to write.

Mmh. For drivers/cbus/tahvo-usb.c my patch contains

--- linux-osk.orig/drivers/cbus/tahvo-usb.c
+++ linux-osk/drivers/cbus/tahvo-usb.c
@@ -36,7 +36,7 @@
  #include <linux/usb_ch9.h>
  #include <linux/usb_gadget.h>
  #include <linux/usb.h>
-#include <linux/usb_otg.h>
+#include <linux/usb/otg.h>
  #include <linux/i2c.h>
  #include <linux/workqueue.h>
  #include <linux/kobject.h>

What's wrong with this? For me using recent git it compiles. 
I have no usb_otg.h.

>>Is there any way to test self compiled kernel on N770
>>without breaking flashed SW/image? Anything like download to
>>RAM, e.g. used by uboots TFTP download on OSK?
> 
> yes, there is. That's what I'm using ^^
> 
> ./flasher-2.0 -l -b -k <my_kernel>

Thanks, will try it.

Cheers

Dirk

Re: Broken N770

[Arnaud Patard]

Dirk Behme <dirk.behme@googlemail.com> writes:

> Arnaud Patard (Rtp) wrote:
>>>Thanks for the hint! With patch previously sent
>>>n770_defconfig should compile again.
>>
>> Sorry, that's wrong. I'm using an up2date git tree with origin
>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git/
>> and I still need patches.
>>
>> For instance : - there are still some users of pt_regs (patch sent
>> some time ago)
>
> Yes, but these are only warnings and they are already fixed by patch
> sent.
>
> For drivers/usb/core/hub.c I had to use
>
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-November/008254.html

If you look at the full thread, you'll see that I'm using the same patch :)

>
>> - drivers/cbus/tahvo-usb.c is still using usb_otg.h. Patch not sent but
>> trivial to write.
>
> Mmh. For drivers/cbus/tahvo-usb.c my patch contains
>
> --- linux-osk.orig/drivers/cbus/tahvo-usb.c
> +++ linux-osk/drivers/cbus/tahvo-usb.c
> @@ -36,7 +36,7 @@
>  #include <linux/usb_ch9.h>
>  #include <linux/usb_gadget.h>
>  #include <linux/usb.h>
> -#include <linux/usb_otg.h>
> +#include <linux/usb/otg.h>
>  #include <linux/i2c.h>
>  #include <linux/workqueue.h>
>  #include <linux/kobject.h>
>
> What's wrong with this? For me using recent git it compiles. I have no
> usb_otg.h.

No, that's fine. I was talking about that change. As it's not in the current
git tree, I wanted to say that you need such a patch :)

>
>>>Is there any way to test self compiled kernel on N770
>>>without breaking flashed SW/image? Anything like download to
>>>RAM, e.g. used by uboots TFTP download on OSK?
>>
>> yes, there is. That's what I'm using ^^
>>
>> ./flasher-2.0 -l -b -k <my_kernel>
>
> Thanks, will try it.
>
> Cheers
>
> Dirk

Regards,
Arnaud

Re: I2C zero length transfers and SMBUS_QUICK, was: Pending October patches

[David Brownell]

On Sunday 05 November 2006 2:32 am, Dirk Behme wrote:
>
> Our hack to make things work on OMAP will not be accepted 
> upstream. But staying with broken OMAP features only because 
> (available) hack isn't acceptable in mainline doesn't sound 
> like an option as well.
> 
> I personally vote for working OMAP ;)

Me too ... the sad part is that this is basicallly a design bug
in the upstream I2C stack, and over the past couple years there
have been no evident signs of it ever getting fixed.

- Dave

Re: I2C zero length transfers and SMBUS_QUICK, was: Pending October patches

[tony]

* David Brownell <david-b@pacbell.net> [061106 03:44]:
> On Sunday 05 November 2006 2:32 am, Dirk Behme wrote:
> >
> > Our hack to make things work on OMAP will not be accepted 
> > upstream. But staying with broken OMAP features only because 
> > (available) hack isn't acceptable in mainline doesn't sound 
> > like an option as well.
> > 
> > I personally vote for working OMAP ;)
> 
> Me too ... the sad part is that this is basicallly a design bug
> in the upstream I2C stack, and over the past couple years there
> have been no evident signs of it ever getting fixed.

I wonder if we could help somehow by doing "embedded i2c stack"
by modifying your SPI framework to support i2c?

Tony

Re: I2C zero length transfers and SMBUS_QUICK

[David Brownell]

> > > Our hack to make things work on OMAP will not be accepted 
> > > upstream. But staying with broken OMAP features only because 
> > > (available) hack isn't acceptable in mainline doesn't sound 
> > > like an option as well.
> > > 
> > > I personally vote for working OMAP ;)
> > 
> > Me too ... the sad part is that this is basically a design bug
> > in the upstream I2C stack, and over the past couple years there
> > have been no evident signs of it ever getting fixed.
>
> I wonder if we could help somehow by doing "embedded i2c stack"
> by modifying your SPI framework to support i2c?

Well, "clone-and-modify" vs "modify-in-place" ... could be.  I sure
did that SPI framework with a strong goal of not repeating most design
mistakes made in the the I2C stack!!  And folk tell me I succeeded...

An "embedded i2c" stack could be done easily:  clone-and-modify SPI,
removing assumptions like "full duplex", "names start with spi_",
and "addressing works like this"; add synchronous SMBUS-ish utilities
on top; add drivers; share or stir, mixing to taste.  :)


The politics of that would be more awkward than the technical side
of things ... as you imply, the flaws in the current I2C stack are
most glaringly evident to folk doing work in embedded systems (and
not just OMAP).  So "embedded i2c" would be a useful starting meme.

After all, one point is the need for real I2C support ... and a stack
designed around an assumption that everything supports SMBUS_QUICK
should probably not be called an "i2c" stack!!

I think Jean Delvare has the notion that some people _are_ working on
incremental tweaks to fix such issues in the upstream "I2C" stack.
Anyone serious about fixing these issues should start some discussion
on that I2C list.

- Dave

Re: I2C zero length transfers and SMBUS_QUICK

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [061107 22:24]:
> > > > Our hack to make things work on OMAP will not be accepted 
> > > > upstream. But staying with broken OMAP features only because 
> > > > (available) hack isn't acceptable in mainline doesn't sound 
> > > > like an option as well.
> > > > 
> > > > I personally vote for working OMAP ;)
> > > 
> > > Me too ... the sad part is that this is basically a design bug
> > > in the upstream I2C stack, and over the past couple years there
> > > have been no evident signs of it ever getting fixed.

The thing is that at some point when more and more people will be using
the mainline kernel with omap, we end up with mysterious problem reports
like "sound does not work" and then we don't know where the problem is.

So we really should figure out how to have the same version in
mainline and linux-omap tree.

> > I wonder if we could help somehow by doing "embedded i2c stack"
> > by modifying your SPI framework to support i2c?
> 
> Well, "clone-and-modify" vs "modify-in-place" ... could be.  I sure
> did that SPI framework with a strong goal of not repeating most design
> mistakes made in the the I2C stack!!  And folk tell me I succeeded...
> 
> An "embedded i2c" stack could be done easily:  clone-and-modify SPI,
> removing assumptions like "full duplex", "names start with spi_",
> and "addressing works like this"; add synchronous SMBUS-ish utilities
> on top; add drivers; share or stir, mixing to taste.  :)
> 
> 
> The politics of that would be more awkward than the technical side
> of things ... as you imply, the flaws in the current I2C stack are
> most glaringly evident to folk doing work in embedded systems (and
> not just OMAP).  So "embedded i2c" would be a useful starting meme.
> 
> After all, one point is the need for real I2C support ... and a stack
> designed around an assumption that everything supports SMBUS_QUICK
> should probably not be called an "i2c" stack!!
> 
> I think Jean Delvare has the notion that some people _are_ working on
> incremental tweaks to fix such issues in the upstream "I2C" stack.
> Anyone serious about fixing these issues should start some discussion
> on that I2C list.

Let's hope somebody picks it up at some point after getting tired of
working around the same issues over and over again :)

Tony

Re: Pending October patches

[David Brownell]

On Wednesday 01 November 2006 1:28 pm, tony@atomide.com wrote:

> > 27. [PATCH] [USB/CORE/USB.C] Fixes autosuspend and auto_pm 
> > fields missing
> > http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008234.html
> 
> Sounds like this is getting fixed in the mainline tree.

No, the root cause of the problem is a borked h2 defconfig; but I'm
not clear how it got past the build step that's supposed to make sure
the current config matches all the Kconfig constraints.

(That is, USB_SUSPEND depends on PM, but only one of them was set in
the defconfig yet the build was proceeding ...)

Re: Pending October patches

[Dirk Behme]

David Brownell wrote:
> On Wednesday 01 November 2006 1:28 pm, tony@atomide.com wrote:
>>>27. [PATCH] [USB/CORE/USB.C] Fixes autosuspend and auto_pm 
>>>fields missing
>>>http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008234.html
>>
>>Sounds like this is getting fixed in the mainline tree.
> 
> No, the root cause of the problem is a borked h2 defconfig; but I'm
> not clear how it got past the build step that's supposed to make sure
> the current config matches all the Kconfig constraints.
> 
> (That is, USB_SUSPEND depends on PM, but only one of them was set in
> the defconfig yet the build was proceeding ...)

Just tried it, it really fails and isn't resolved by Kconfig 
processing.

Looking at h2 defconfig we have

# CONFIG_PM is not set
CONFIG_USB_SUSPEND=y
CONFIG_USB_OTG=y

Looking at drivers/usb/core/Kconfig we have

config USB_SUSPEND
	bool "USB selective suspend/resume and wakeup (EXPERIMENTAL)"
	depends on USB && PM && EXPERIMENTAL

config USB_OTG
	bool
	depends on USB && EXPERIMENTAL
	select USB_SUSPEND
	default n

So USB_SUSPEND isn't activated (processed?) because PM isn't 
set. But USB_OTG selects USB_SUSPEND without selecting PM as 
well.

Maybe anything like

--- linux-osk.orig/drivers/usb/core/Kconfig
+++ linux-osk/drivers/usb/core/Kconfig
@@ -77,6 +77,7 @@ config USB_OTG
         bool
         depends on USB && EXPERIMENTAL
         select USB_SUSPEND
+       select PM
         default n

can help here?

Cheers

Dirk