[LinuxBIOS] [PATCH] Improve ITE IT8716F support.

[Uwe Hermann]

Improve ITE IT8716F support.

Signed-off-by: Yinghai Lu 
Signed-off-by: Uwe Hermann

---

This is yet another part of Yinghai's huge patch. I merged and adapted
the code, some minor, mostly cosmetic, changes here and there.

Some more things are still missing from the huge patch...

Uwe.

[Uwe Hermann]

Hi,

On Sat, Feb 10, 2007 at 01:39:37AM +0100, Uwe Hermann wrote:
> Improve ITE IT8716F support.
>
> Signed-off-by: Yinghai Lu 
> Signed-off-by: Uwe Hermann

Can somebody please review/test/ack this? It's one of the last remaining
parts of Yinghai's huge patch.

Thanks, Uwe.

[Ed Swierk]

On 2/16/07, Uwe Hermann  wrote:
> Can somebody please review/test/ack this? It's one of the last remaining
> parts of Yinghai's huge patch.

I tried it out on my DFI board and it seems to work fine, although I'm
exercising only the serial port.

I had to add #include <arch/io.h> to superio.c to get it to compile.
The modified patch is attached.

Signed-off-by: Ed Swierk

--Ed

[Uwe Hermann]

Hi,

On Fri, Feb 16, 2007 at 11:07:17AM -0800, Ed Swierk wrote:
> I tried it out on my DFI board and it seems to work fine, although I'm
> exercising only the serial port.
>
> I had to add #include <arch/io.h> to superio.c to get it to compile.
> The modified patch is attached.
>
> Signed-off-by: Ed Swierk

Thanks a lot!

The patch is ready to be committed, IHMO, so:

Acked-by: Uwe Hermann

I'm waiting for one more ack before committing.

Uwe.

[ron minnich]

On 2/16/07, Uwe Hermann  wrote:
> Hi,
>
> On Sat, Feb 10, 2007 at 01:39:37AM +0100, Uwe Hermann wrote:
> > Improve ITE IT8716F support.
> >
> > Signed-off-by: Yinghai Lu 
> > Signed-off-by: Uwe Hermann

acked-by: Ronald G. Minnich

Somebody can commit now.

ron

[Uwe Hermann]

On Sat, Feb 24, 2007 at 09:29:42AM -0700, ron minnich wrote:
> On 2/16/07, Uwe Hermann  wrote:
> > Hi,
> >
> > On Sat, Feb 10, 2007 at 01:39:37AM +0100, Uwe Hermann wrote:
> > > Improve ITE IT8716F support.
> > >
> > > Signed-off-by: Yinghai Lu 
> > > Signed-off-by: Uwe Hermann
>
> acked-by: Ronald G. Minnich

Thanks, committed in r2559.

Uwe.

[Peter Stuge]

On Sat, Feb 10, 2007 at 01:39:37AM +0100, Uwe Hermann wrote:
> Improve ITE IT8716F support.

@@ -35,55 +38,34 @@

#define IT8716F_CONFIGURATION_PORT   0x2e /* Write-only. */

-/* The content of IT8716F_CONFIG_REG_LDN (index 0x07) must be set to the
-   LDN the register belongs to, before you can access the register. */
-static void it8716f_sio_write(uint8_t ldn, uint8_t index, uint8_t value)
+/* Perform MB PnP setup to put the SIO chip at 0x2e. */
+/* Base address 0x2e: 0x87 0x01 0x55 0x55. */
+/* Base address 0x4e: 0x87 0x01 0x55 0xaa. */
+static inline void pnp_enter_ext_func_mode(device_t dev) 
 {
-	outb(IT8716F_CONFIG_REG_LDN, SIO_BASE);
-	outb(ldn, SIO_DATA);
-	outb(index, SIO_BASE);
-	outb(value, SIO_DATA);
+	unsigned port = dev >> 8;

How does this work? device_t is a pointer to a struct elsewhere:

+		outb(0x55, dev->path.u.pnp.port);

I'll ack once I get this. :)

//Peter

[ron minnich]

On 2/24/07, Peter Stuge  wrote:
> On Sat, Feb 10, 2007 at 01:39:37AM +0100, Uwe Hermann wrote:
> > Improve ITE IT8716F support.
>
> @@ -35,55 +38,34 @@
>
> #define IT8716F_CONFIGURATION_PORT   0x2e /* Write-only. */
>
> -/* The content of IT8716F_CONFIG_REG_LDN (index 0x07) must be set to the
> LDN the register belongs to, before you can access the register. */
>
> -static void it8716f_sio_write(uint8_t ldn, uint8_t index, uint8_t value)
> +/* Perform MB PnP setup to put the SIO chip at 0x2e. */
> +/* Base address 0x2e: 0x87 0x01 0x55 0x55. */
> +/* Base address 0x4e: 0x87 0x01 0x55 0xaa. */
> +static inline void pnp_enter_ext_func_mode(device_t dev)
>  {
>   outb(IT8716F_CONFIG_REG_LDN, SIO_BASE);
>   outb(ldn, SIO_DATA);
>   outb(index, SIO_BASE);
>   outb(value, SIO_DATA);
>   unsigned port = dev >> 8;
>
> How does this work? device_t is a pointer to a struct elsewhere:

early stuff that is compiled with  romcc has this device_t typedef'ed
to a scalar.

gcc-compiled has it typedef'ed to a struct *.

This usage will not continue in V3, since all code will be gcc-compiled.

thanks

ron

[Segher Boessenkool]

> gcc-compiled has it typedef'ed to a struct *.
>
> This usage will not continue in V3, since all code will be 
> gcc-compiled.

And typedef for struct pointers is a no-no with the v3
coding style (adopted from Linux); you could make an
exception for an often-used thing like this, but this
mail thread exemplifies why that is not such a good
idea: you really want to know the underlying type, so
why not write it out.

Segher

[ron minnich]

On 2/24/07, Segher Boessenkool  wrote:
> And typedef for struct pointers is a no-no with the v3
> coding style (adopted from Linux); you could make an
> exception for an often-used thing like this, but this
> mail thread exemplifies why that is not such a good
> idea: you really want to know the underlying type, so
> why not write it out.

Don't worry, there will be *NO* exceptions.

:-)

ron

[Segher Boessenkool]

> > And typedef for struct pointers is a no-no with the v3
> > coding style (adopted from Linux); you could make an
> > exception for an often-used thing like this, but this
> > mail thread exemplifies why that is not such a good
> > idea: you really want to know the underlying type, so
> > why not write it out.
>
> Don't worry, there will be *NO* exceptions.

Good good, *NO* typedefs to pointer to struct.  Hopefully
you don't mean you won't have typedefs at all (atomic_t,
u32, etc.) :-)

Segher

[Peter Stuge]

On Sat, Feb 24, 2007 at 09:37:16AM -0700, ron minnich wrote:
> >   unsigned port = dev >> 8;
> >
> > How does this work? device_t is a pointer to a struct elsewhere:
>
> early stuff that is compiled with  romcc has this device_t
> typedef'ed to a scalar.
>
> gcc-compiled has it typedef'ed to a struct *.

Thanks, I should have figured that out.
> This usage will not continue in V3, since all code will be
> gcc-compiled.

That's really good.

//Peter

"ron minnich"  writes:
> early stuff that is compiled with  romcc has this device_t typedef'ed
> to a scalar.
>
> gcc-compiled has it typedef'ed to a struct *.
>
> This usage will not continue in V3, since all code will be gcc-compiled.

Howe are you going to handle small embedded targets?

Has a way been found to get cache as ram working on those or do we
have to go back to writing ram initialization on those ports in
assembly.

Eric

[ron minnich]

On 2/28/07, Eric W. Biederman  wrote:
> Howe are you going to handle small embedded targets?

one at a time ... I have not seen any recent ones that don't do CAR.
> Has a way been found to get cache as ram working on those or do we
> have to go back to writing ram initialization on those ports in
> assembly.

I don't know which parts you mean. But romcc is, at this point, a
large, complex piece of software that no one has stepped up to
maintain. It's quite an incredible piece of software, but we can't
afford to keep it going.

ron

[Stefan Reinauer]

* Peter Stuge  [070224 17:32]:
> unsigned port = dev >> 8;
>
> How does this work? device_t is a pointer to a struct elsewhere:
> outb(0x55, dev->path.u.pnp.port);

In v2 we have this little magic trick that allows you to use device_t
both in romcc and gcc code. For romcc, it is an int, for gcc it is a
struct.

In v3 we don't have this problem anymore ;-)